Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't let application read or write windows positions."
This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.
Imagine a program that utilizes several separate windows for palettes. If the program has no way to specify where to place those palettes, the user is going to be presented with a ton of palettes piled on top of their document window and that they’ll have to sort that out themselves, rather than a neatly organized immediately usable workspace. That’s not really an acceptable user experience no matter how you slice it.
Multi-screen situations is another place where this comes up, which includes not just multi-monitor desktop setups but things like foldable devices, and it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) and have it available regardless of the compositor the user is using.
>Imagine a program that utilizes several separate windows for palettes.
One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window. Then as the user decides to undock them one by one, they are removed from the main program window and a new window is drawn containing that palette. So the user isn't presented with "a ton of palettes"; they get them one at a time and can move them as they wish.
The rest of that (maintaining their position next to the main window, restoring them when the application is restarted) would be solved by a protocol that allowed relative positioning, which was already suggested in the wayland-protocols MR discussion.
>it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen)
This can already work today if the compositor provides a way to do it, as long as the application tags such a window with some unique `app_id` or `title`. For example in sway the user can write config rules to match windows based on such criteria and run position etc commands on them. I assume KDE also has something like this because I remember it having a way to match windows using X properties in the KDE 4 days.
> One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window.
What if the program doesn't want a single-window mode?
Or what if the work to support a single-window mode isn't considered to be worth it when the only people who care are the 0.01% of users who are on Linux and care that the program isn't Wayland-native?
Of course the order of operations here was to break everything first and then start addressing the issues they feel like addressing when and if they get around to it.
Kind of a real FU way of trying to move things forward...
Yes, normally when you make a new thing you start with a small base and then gradually make changes to it, instead of adding the whole kitchen sink from the start and defeating the purpose of making the new thing in the first place.
Well, that's how you go about relearning old lessons. It reminds one of Chesterton's fence, where the ignorant tear down the fence and after much suffering end up building the fence back up.
> That’s not really an acceptable user experience no matter how you slice it.
What you're describing is what happens in most desktop environments any time you open multiple document windows at once. Why is it so much more unacceptable for this to happen to tool palette windows? Yeah, it's obviously not good behavior, but it's prevalent enough that it's clearly a manageable problem for end users and generally preferable to refusing to support multiple windows at all.
macOS will actually cascade multiple document windows opened at once so long as the dev has taken a moment to flag the windows as document windows, which still isn’t amazing but at least ensures that all opened windows are visible.
How is the window manager going to handle the positioning in a scenario like multi-viewport? The user already conveyed their intent by dragging a window out of the application's viewport to create a new viewport, and Wayland is prohibiting the application from obeying the user.
I'm just trying to understand why ImGui needs to read and write window positions, because it's not immediately obvious from that paltry description. It sounds like you're describing a use case where it needs to be able to set the position of a new window relative to an existing window. So APIs to read the position of the current window and write the position of the new window are probably what they're looking for—though I can readily imagine narrower APIs to handle that use case. Does that sound to you like an accurate explanation of their complaint?
(None of the above explains why ImGui cannot in the interim accept a janky experience where newly created child windows pop up wherever the window manager puts them, as commonly happens for transient dialog boxes. This seems like a nice to have feature, but not a complete showstopper.)
AFAICT from looking at the imgui wiki page and the examples in the OP of the wayland-protocols MR, it seems to be entirely that either these libraries have existing API that allowed setting the window coordinates and thus they want to be able to continue providing them, or these applications (like gimp) want to be able to recreate those windows at their previous positions after the application is closed and restarted.
It's also worth noting that that imgui wiki link says the feature doesn't work well in X11 either, though I didn't read the linked issue for what exactly is broken there.
The position being wrong isn't the only issue - if you can't programmatically reposition a window, you have to break the user's drag gesture into two drag gestures, one to 'pop out' the window and then the user has to find it and grab it again to move it.
https://github.com/ocornut/imgui/wiki/Multi-Viewports
This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.