Wayland Gtk4 Window Management/Positioing via App Policy

[pyzahl (Percy Zahl)]

I am curious about the developments related to Wayland/Window manager and Gtk4 related to the “policy or future plans” of managing larger applications having multiple windows of various “kinds” and a need to help the user managing and eventually restoring a organization of those on a large desktop space when “primitive” window manager action do not cut it. I really do not care today about oddest “excuses” of a “2d” desktop not been future proof or what so ever if some one comes up with a 3d desktop what is kinda odd anyways. Windows are flat by nature even contents may be 3d.
And if some one chooses to use an “non 2d” desktop layout, so it be and the window management system simply overrides with it’s own defaults if the request if not possible.

Example on X11:

[CodedOre]

I’m not sure I quite follow.

I assume your point is about the fact that apps under GTK4 and Wayland can’t position themselves freely anymore.
However, that is not related to 3D.

That desktops and UI toolkits are using 3D instead of 2D is simply due to the way graphics cards developed. Since modern graphics cards are designed and optimized for 3D graphic acceleration, you need to use 3D graphics if you want the graphics card to render the UI.

Instead, this has to do with security. On X11, there aren’t many safeguards to an app, allowing malicious apps to potentially do harm. Wayland on the other hand was designed to be more secure by restricting an app more and giving more control to the desktop.

One such restriction is that an app can no longer freely position itself.
Now, this does limit the capabilities of an app. I see two reasons why an app wants to move windows around, each with its own alternative.

First, you might want to restore the window position after a restart. For this, there is a protocol, xdg-session-management, in work. When this is implemented, an app can tell the desktop to save a state with windows, which the desktop will then restore it after a reboot. By the looks of it, it’s already implemented in Mutter, and you can see the current MR for GTK here.

That being said, I believe from your image you’re more concerned about the second point, which is an application which has a lot of windows. I don’t know that Wayland offers a solution for this though.
And in my view, it isn’t that great of an UI pattern anywhere to have multiple windows scattered around for the same task.
I personally would recommend to make the UI use a single-window, with additional windows only when the user requests it (like for multi-monitor purposes). In that case you may want to take a look at libpanel. It was developed for GNOME Builder and provides the functionality to arrange widgets inside a single-window.

[pyzahl (Percy Zahl)]

It’s great to know that at least the store/ restore seams now possible, I need to figure that out.
But also after a restart of the app.

With 3d I meant some earlier ‘excuses’ of potentially having app windows mapped onto a weird possibly 3d desktop topology.

Can you point out a potential security thread example? I don’t see that. I don’t want to excess other app’s windows info.
I am ok with window position and size setup relative to my own “main-app” window (or any own reference window or point some where).

And as a note, my application has a many windows with totally different functions for various control tasks. Also not all are open or required at all times, depends on the current task and machine setup.

Only some are of same kind to display image data of different sources belonging to same “scan” (like images of the same scene with various sensors (visible, IR, xray, …) you like to see side by side life while data is coming in. I was tempted to place that into a huge window, but it is much better to have the user have control over that and make use of part overlapping, etc. to save desktop estate space, or even minimize some.
I for example have a assistant function to automatic neatly rearrange those with respect to the “first scan view” on a press of a hot key on the main control window. And functions to store/restore the whole window layout+window sizes as many have dynamic scaled contents.

And on a side note: I may boldly claim this is one of the “largest” Gtk4 applications build for science Not the default app style with one window and copies of that same functionality with different contents.

If curious: GitHub - pyzahl/Gxsm4: Gnome X Scanning Microscopy -- see also https://gxsm.sf.net

This said, myself and the “Gxsm” community would be very happy to see some future here to make more practical use of the more efficient Wayland system.

[ebassi (Emmanuele Bassi)]

@pyzahl

Can you point out a potential security thread example? I don’t see that. I don’t want to excess other app’s windows info.

Under X11, you can:

• discover the location of an entry on the screen
• position a transparent window to cover those coordinates
• grab all input to your window, and log all keys
• re-inject the input events into the global even queue

Thus creating a perfectly disguised key logger. This is not theoretical: it’s literally how things work in X11. There is no mitigation, because any would break things like input methods, or accessibility tooling.

@pyzahl

I am ok with window position and size setup relative to my own “main-app” window (or any own reference window or point some where).

In Wayland, you can position popup surfaces relative to your main surface. GTK has API for that, as it’s how menus and tooltips are implemented. There are limitations to that, so you can’t just put a whole top level window content in there; there is also a protocol involved to allow the Wayland compositor to allow repositioning/resizing when the surface could go off-screen, without necessarily knowing the monitors layout in the application itself.

@pyzahl

I for example have a assistant function to automatic neatly rearrange those with respect to the “first scan view” on a press of a hot key on the main control window. And functions to store/restore the whole window layout+window sizes as many have dynamic scaled contents.

Applications cannot store or restore the coordinates of a top level surface because they don’t have access to those; only the Wayland compositor does, as it’s a privileged component. Session storing and restoring is implemented at the compositor level, with some help from the toolkits to label surfaces so that they can be matched and restored—but it’s still the compositor’s job.

From a higher level perspective: your application’s visual model is, in practice, eminently outdated; it comes from a time where screen real estate was smaller, and it’s a comparatively small technological niche—and it’s not helped by the fact that scientific tools are typically used by one of the most conservative audiences ever. The graphic stack, toolkits, and even design have all moved away from the kind of UI you could create in the '90s, but some niches are still firmly entrenched in those design paradigms. My two suggestions, as one of the GTK developers, would be:

1. re-design your application to work as a full screen UI, with embedded views, following design patterns that are more commonplace in 2025
2. ignore Wayland entirely, and keep using X11 through XWayland; there are some affordances still there for this kind of applications. After all: if you won’t change the design, then there’s no reason whatsoever to move to Wayland

Option number two puts a hard limit on the support window for your toolkit: GTK4, which is the last version of GTK that still supports X11 natively, will be EOL when GTK6 is released. Since we haven’t even started development of GTK5, I’d say you have a fair amount of time left, there; probably around 10-15 years.

[pyzahl (Percy Zahl)]

Many thanks for the great explanations and future perspectives. Even I have to google what EOL means.

I understand now what was meant by security issues. Still this is non of what I am asking or wishing for.

I only ask for my own app’s window’s position and size and coordinates even can be relative between windows. Say xy position of Wn relative to W1.
And to request to move Wn to xy relative to W1. May not be granted if not possible, I am OK with that also. And this from within gtk4 would be appreciated!
This is by no means any security issue. if so, explain this please.
Nor do I need or ask for any inputs from anything outside by app.

OK this discussion is great in a way and yes I have already considered and still at times think about putting all into one big gtk window.

Status quo:

But honestly I do not see why I wanted to do so as I basically would reinvent my own window manger inside a window – seams silly to me.

Plus my “windows” may not ideally make use of my “big own workspace” and I obstruct otherwise usable desktop space for other apps/views I need at the same time! Simply I like my freedom to move things where I want them. Sloppy focus mode rules.

It seams the “new desktop world view” is mainly thinking trivial and there is only one app (and one window per app/app instance) at a time on the desktop visible or on top or even full screen?
I see this been neat and clean but not all real world problems are like that.

And yes I also agree this works well for any “document editors” and also the new “Inkscape” I like a lot, making use of panes and bars all around it for tools. I just try to imagine or project some thing alike to my app and but having issues.

Future options?? Staying with X11 – what we do so far. But I like to look into the future as I am the key designer and developer. And I hope Wayland and future gtk may still stay usable for non-standard apps (scientific or not) with more complex / flexible layout needs?

OK thinking beyond and towards a potential new work flow to eliminate “automatically” windows (or may be call them “views” now) which are may be not always needed. Yes there are some aspects this would work. Still won’t solve my app’s “problem” all over.

To be specific of my key needs, may be some one has some bight ideas:
This is not a document editor, but a instrument control with various real time visualizations and tasks.

I am trying to sort / combine options of only the key components:
a) the “main” imaging setup (geometry and a like)
b) a data channel selector and manager
(windows a+b may be merged) ** but what if this dose not fit on a smaller screen or some one likes a different arrangement better?

c1) Instrument Control – already makes use of tabs for many different tasks/operation and so on. This window is generated by a Hardware-Plugin and is not present at all for image analysis, etc.
c2) Scan Control. Optional or advances controls for imaging. Not always open or needed. Mostly so.
c3) not even shown in my screen short, more Instrument Specimen Motion Controls
d) Live Instrument Status panels/indicator – important to be in view at all times
d*) N Scan View Windows + Profile Views (if enabled), may be open or not, may be at any scale and size, etc. etc. often overlapping to simply safe space. Hard to do myself in one window?!?

And another issue: I use accelerator keys for various actions and they are tied and should be act only on one window been in active in focus.

x) Those HV5 gauges are from a different app
y,z…) there may be more related 3rd part control apps/windows open at times with need to be seen at all times!

Just compare to a busy real office desktop with more than one book or paper on top of it, it may be messy at busy times with papers overlapping and having the most important areas of current focus exposed, may be a bunch of world clocks or stock meters ticking to watch…, yes. Nothing is perfect all the time.

so eventually creating this kind of scenario, a desktop within a desktop (with limited functionality)?
Honestly not sure about this.

[CodedOre]

@pyzahl

I understand now what was meant by security issues. Still this is non of what I am asking or wishing for.

[…]

This is by no means any security issue. if so, explain this please.
Nor do I need or ask for any inputs from anything outside by app.

The issue is mostly that under X11 an malicious app can do this without any barrier. And because such malicious apps can exist, Wayland was designed to better safeguard against such an potential app.

So when Wayland was designed, it intentionally was made to restrict some information and actions to an app and leave it up to the compositor. This includes window positions.
And, it is also logical that window placement is ultimately responsibility of the compositor, rather than an application.

@pyzahl

It seams the “new desktop world view” is mainly thinking trivial and there is only one app (and one window per app/app instance) at a time on the desktop visible or on top or even full screen?
I see this been neat and clean but not all real world problems are like that.

The idea is less on having only one window visible at any time. Its more that all relevant information and controls of one app is found in one window.
It also makes it more handable for the user. Instead of having a dozen windows you would need to hide/move, its just one window.

@pyzahl

so eventually creating this kind of scenario, a desktop within a desktop (with limited functionality)?
Honestly not sure about this.

I mean, that would basically be similar to what libpanel would provide. Maybe not with fully resizable windows and such, but you could freely arrange the widgets inside the grid…
Something similar to what your image here shows.

As a very basic idea I could imaging the current windows to be widgets you can arrange in the window. Maybe with an added option to save an arrangement as a view and switch between them quickly.

@pyzahl

And another issue: I use accelerator keys for various actions and they are tied and should be act only on one window been in active in focus.

If the keys are tied to an widget, not an window, it will only be activated when the widget is focused, so this should still be possible.

[pyzahl (Percy Zahl)]

Libpanel looks interesting, thanks for the hint – I am seeing this the first time now! is it mature? This is some idea to look into for some of my control windows to merge.

Still resizing data view windows manually and temporary to very big as needed at times is a functionality I do not like to have limitations on.
Particular this is powerful for my own plotting tools (all svg rendering and fully scalable + svg/pdf export capable). Same for large images and annotations.

Another real world work zone view example: