Do we need WindowHandle::set_level?

[jneem]

Is it ever necessary to change the window level after it's already created? For windows that aren't yet created, we have WindowBuilder::set_level. There was some concern in #1785 whether WindowHandle::set_level will work on x11, but I don't know about any other platforms...

[maan2003]

WindowHandle::set_level will be useful for WindowLevel::AlwaysOnTop

[psychon]

Sounds like "always on top should not be a window level", but rather another property that can be controlled separately. And in window builder it has three states, "on", "off", "default", where "default" depends on the window level and implements the current behaviour.
(Does anyone/anything really need this flexibility? Am I over-engineering?)

[jneem]

That sounds reasonable. But in addition, I think that always-on-top is a property that potentially makes sense to change after a window is displayed. Whereas (at least on windows and gtk/x11) the tooltip/dialog/whatever hints are things that can only be set once when the window is created.

[JAicewizard]

In order to work well with GTK4/wayland the window level needs to be known at creation time.

I dont see a use of changing it after the fact anyways, why would you repurpose a window instead of creating a new one?
Or when do you want to repurpose an existing window, without changing the child widgets? sounds very useless to me.

[JAicewizard]

Whereas (at least on windows and gtk/x11) the tooltip/dialog/whatever

Yes but that is diferent from always on top. Any window can be always on top in GTK(3/4), and this can be changed at any time using gtk_window_set_transient_for and gtk_window_set_modal.

[psychon]

Any window can be always on top in GTK(3/4), and this can be changed at any time using gtk_window_set_transient_for and gtk_window_set_modal.

Uhm. Correct me if I am wrong, but neither of these functions is "always on top". The first one is for "window window is a dialog for window parent" (and you need to provide a parent window). The second one marks a window as, well, modal, which means that this dialog must be closed before the user can continue working on the main window.

From the docs of gtk_window_set_modal (emphasis mine):

most window managers will then disallow lowering the dialog below the parent.

This does not even talk about "always on top", at least not in the way I understood it.

I'd recommend gtk_window_set_keep_above() instead, but I also want to quote the docs on that one in the hope that something like this also ends up in druid's docs:

Note that, according to the Extended Window Manager Hints Specification, the above state is mainly meant for user preferences and should not be used by applications e.g. for drawing attention to their dialogs.

[JAicewizard]

From the docs of gtk_window_set_modal (emphasis mine):

most window managers will then disallow lowering the dialog below the parent.

Yes, but you cannot ever force a window manager to do anything. Not all follow the exact spec, and some provide more than the exact spec.

This does not even talk about "always on top", at least not in the way I understood it.

It does:

disallow lowering the dialog below the parent

That sounds like always on top to me, assuming the WM allows for that.

I'd recommend gtk_window_set_keep_above() instead, but I also want to quote the docs on that one in the hope that something like this also ends up in druid's docs:

I would do the opposite, going this path would probably work with GTK3/X11 but as documented in GDK3 (https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/gdkwindow.c#L11001) this only works under X11, not Wayland.

[JAicewizard]

I just scrolled through the source code for the platforms.

There are 2 platforms for which this is actually implemented: GTK and macos.
Then looking at the GTK3 documentation, this seems to indicate that it shouldn't work after window creation:
This function should be called before the window becomes visible.

This does seem to work on macos, going off reading online people discussing setLevel on macos.

However, how much is it worth keeping this just for macos?

[cmyr]

If something is only used for a single platform, I think it's probably best to put it behind some platform-specific trait.

[JAicewizard]

Maybe we could remove this for now, then use this as an example for platform specific extensions and put that on the pile of things to think about with dynamic platform switching. I feel like they are very much related.

EDIT:
Or do you want to keep this for now untill we solve that issue first.

[cmyr]

I could imagine eventually wanting to have the ability to move a window to the front or to the back, or to move one of an application's windows behind another one of that application's windows. Is set_level the API we would expect to use, for that? Is that actually not possible on all platforms?

[jneem]

On x11 (and this is reflected in the gtk3 API, not sure about gtk4), there is a concept of "window type hint" that's independent of the stacking order. I think you're expected to set the window type hint -- which includes things like "tooltip", "menu", "splash", "dialog", "popup menu" -- before showing the window, but you can change the stacking order at any time.

[ratmice]

IIRC i've never seen success in bringing a window behind another on X11 (as opposed to moving a window in front of another).
But perhaps that issue is intertwined with mapping a window below another -- IIRC it wasn't an API surface issue which had all the necessary enum variants to describe the desired action, but the particular combination of behind not working...

Anyhow i've definitely had issues with this sort of thing on (plain old x11).

[JAicewizard]

in GTK4 you can set the window to be transient to another window or modal at any time, but you cannot change something from a popup to a window without rebuilding the entire window. Maybe something similar like set_level could exist that would just bring it in front of another window and change modal status.

[psychon]

IIRC i've never seen success in bringing a window behind another on X11

No idea how well this is implemented in WMs, but at least ICCCM specifies how to stack a window relative to a sibling:

§4.1.5. Configuring the Window

[...]
Clients that change their position in the stack must be aware that they may have been reparented, which means that windows that used to be siblings no longer are. Using a nonsibling as the sibling parameter on a ConfigureWindow request will cause an error.
[...]
Clients that must position themselves in the stack relative to some window that was originally a sibling must do the ConfigureWindow request (in case they are running under a nonreparenting window manager), be prepared to deal with a resulting error, and then follow with a synthetic ConfigureRequest event by invoking a SendEvent request with the following arguments:
[...]
Window managers are in any case free to position windows in the stack as they see fit, and so clients should not rely on receiving the stacking order they have requested.

[JAicewizard]

I think its clear for linux platforms already. We can use specify things like modal and transient bring windows in front of another window (which is what we want from the API). The internals of this may differ on X11/GTK/wayland, but it seems to be possible on all of them. On mac all things are possible, so thats not an issue either.

How does the windows platform handle changing the order after window creation? If it is not possible on windows than this will have to be a platform specific API anyways.

[ratmice]

No idea how well this is implemented in WMs, but at least ICCCM specifies how to stack a window relative to a sibling:

Yeah, I've never seen one which does implement it (or at the very least none of the common ones at the time),

IIRC the GNUstep code (implementing the Mac OS model on X11) which implements this uses an O(n) operation of placing a window, then placing the windows above it with heigher level above, rather than an O(1) operation of placing a window below relative-to a window with higher level. Which as you would expect caused all kinds of window flickering as it went through the window list.

I guess all I'm saying is trying to mirror the Mac model with its full generality on X11 leads to a pretty sub-par experience.

[jneem]

Closed by #1919