Some flag such as ImGuiWindowFlags_ViewportDisable to disable some windows from being external viewports

[zzzyap]

Regarding viewports (using v1.69 docking), is there a flag to disable some windows from becoming viewports.
In our use case, we have notifications (that generate a lot of windows) and was wondering if we could flag these as non-viewports. Such that notifications can be animated and rendered within the main viewport and not create windows/swap chains.

[ocornut]

As we are aiming to generalize the concept of owned/hosting viewports to allow zero or more than one of them, I think what we are looking for isn't so much of a _NoViewport flag but rather to make this works:

ImGui::SetNextWindowViewport(ImGui::GetMainViewport()->ID);
ImGui::Begin("Hello, world!");

Right now I noticed this doesn't work but it is an easy fix.
Would that work for you if I pushed a fix?

(PS: Some of the viewport/platform windows api are a little bit of a mess, here consider the use of viewport pointers vs viewport id. Will have a general small-breaking pass at them once the feature dust has settled)

[ocornut]

Addenum: I am also curious if you are using io.ConfigViewportsNoAutoMerge=true or not. It is false by default, and any notification window covering the main viewport would therefore not use a new swap chain.

EDIT However mixing io.ConfigViewportsNoAutoMerge=true and SetNextWindowViewport is likely to create z-ordering issue.

[zzzyap]

We use the default for ConfigViewportsNoAutoMerge = false.
The issue derived from the fact that we animate in (reposition) the notifications. They basically start offscreen and move onscreen, then upwards as other notifications pop out.

Personally I do see ImGui::Begin("Hello, world!", nullptr, ImGuiWindowFlags_ViewportDisable); being more useful beyond this case. The flag would be easier to check later on like other window flags. Then the user could (if needed) add behaviors for these type windows.
Side side note: I do believe there is already a flag for no docking, so a no viewport would be familiar for users.

ImGui::SetNextWindowViewport(...); does sound like it would achieve the same effect.
Edit: trying ^ this out right now.

[ocornut]

But what I am trying to say is an hypothetical "ViewportDisable" flag is ambiguous:

• windows are always associated to a viewport.
• it will be possible to have multiple user-owned host viewports: which one should the window pick?
• what if you decide to have notifications on the side of some content which is not on your "main" viewport?

Edit: trying ^ this out right now.

It doesn't work now because of a bug (I have a local fix).

[zzzyap]

Ok got it, these would be a deal breaker.
Constrain to viewport via SetNextWindowViewport would make more sense.

[ocornut]

I pushed a fix for SetNextWindowViewport for now.

I think we'll somehow have to come back to this from another angle at some point, maybe after we've done #2471.

[zzzyap]

Tested it out locally SetNextWindowViewport works great :)
#2471 looks awesome, will keep my eye on it.
Closing this issue.

[smilediver]

I've also spent half an hour trying to figure out how to disable log overlay from popping out to a separate window. A flag like ImGuiWindowFlags_ViewportDisable was the first thing I've looked for. Something like that, or maybe ImGuiWindowFlags_AlwaysInMainViewport would be awesome.

[ocornut]

I understand the problem and need here, but as stated here this would be misleading when it comes to supporting multiple main viewport?

[smilediver]

Unless I don't understand something, or there are plans to change it, there is a single main viewport for imgui context. So I would expect that a flag like ImGuiWindowFlags_AlwaysInMainViewport would work in that context, and it doesn't seem misleading to me. However I do see that a meaning of ImGuiWindowFlags_ViewportDisable flag may be misleading.

[ocornut]

The post above state that there is an attention for the user to have zero or more than one host viewport.
Even the "main viewport" terminology is misleading.

I however understand this would be convenient mid-term and going to come up with an idea for a flag, maybe there will be a concept of a "default" viewport which can be modified during the frame.

(Please all remember multi-viewport are in beta and some of those flags/api are going to change before it all gets merged in master.)

[zzzyap]

The case of multiple main viewports (which could be multiple contexts etc... depending on impl.).
Flags such as ImGuiWindowFlags_AlwaysInMainViewport and ImGuiWindowFlags_ViewportDisable conflicts when dealing with multiple main viewports.
ImGui::Begin(...) etc... does not have user specification for which main viewport or context it is created or exists within (and it shouldn't).
SetNextWindowViewport(...) is an approach that would scale better, context and "main" viewport does not matter for this generalized approach.