Ubuntu's X.Org Session Support Now Split Into Separate Package

[Britoid]

Actually it would still be a problem, because it would require every app to handle correctly every possible corner case, and that is just not feasible.
I agree that a mechanism to open windows at last known position is needed, but it is not for every app to handle, and still is a feature of the compositor.
Also that is why CSD is just plain stupid: if a compositor were to implement a feature like "lock window to this location", the place where to logically interact with it is in the title bar... Or theoretically a menubar item that is provided by the compositor via some IPC (as is the "Window" item on MacOS).


This is my opinion, mostly based on seeing parts of apps getting rendered on wrong screens and other weird places, precisely because they use their own rendering toolkit/logic which thought "it knew better". In my job we're guilty of it too, the bugs are really funny, and hard to fix.

macOS uses client side decoration, it's just provided for you by default when you use the system toolkit, which is the only documented way to create windows, so client side decoration does not prevent both features.

the issue with GTKs implementation is that GTK sucks as a windowing toolkit (why libdecor exists), whereas on MacOS Cocoa not so much and lets applications request empty windows to efficiently draw on and hook into the event loops, which you use instead of talking to the compositor.

[duby229]

I feel that way about CSD. What moron decided that apps should draw title bars?

Apps don't draw title bars, window managers do. Which is the reason why SSD requires all UI elements be drawn there!

[Serafean]

macOS uses client side decoration, it's just provided for you by default when you use the system toolkit, which is the only documented way to create windows, so client side decoration does not prevent both features.

I know, but items in the "window" menu interact with the compositor. And that is my contention point: interaction with compositor features.
I mentioned it as a possible and functional alternative to putting all interaction with the compositor into the title bar. An alternative that is even harder to enforce/make work... Just try running GTK applications (firefox, libreoffice) with a dbus menubar somewhere in the system...

[Serafean]

EDIT: Don't you think it should be the applications choice of how it looks and what it does and how it does it?

Definitely not how it looks. Colors and themes (eg. rounded/square buttons) should be set by the end user. Only item placement is done by UX of the application.
And this is for various reasons, accessibility being first and foremost. Changing font sizes, colors etc are a great help for people with poor vision.

[Britoid]

I know, but items in the "window" menu interact with the compositor. And that is my contention point: interaction with compositor features.
I mentioned it as a possible and functional alternative to putting all interaction with the compositor into the title bar. An alternative that is even harder to enforce/make work... Just try running GTK applications (firefox, libreoffice) with a dbus menubar somewhere in the system...

There's nothing stopping such menu bar system from working under Wayland, Wayland has nothing to do with IPC between applications and the desktop environment, it's only concerned with surfaces and input. The only thing that won't work is any implementation that uses XEmbeds or X hooks, which is a good thing in the grand scheme of things, even on Xorg.

I don't think shared menu bars on Linux are feasible, there's too many toolkits and you'll need to them to all agree on a system which even if they do, application authors need to opt into them, and that isn't happening.

[duby229]

Apps should have no power to decide where they draw. It's the job of the DE to remember the window positions.

Might be hard to understand under gnome, but under KDE you can set the window settings for all apps individually. And i think when using wayland, they are set automatically to where you left them last time the app was closed.

Actually no, apps currently have no way of knowing where they are and compositors currently have no way to restore a sessions state. Because Wayland doesn't have a protocol for that and many times apps will just open totally off screen, even on Plasma.

[varikonniemi]

Actually no, apps currently have no way of knowing where they are and compositors currently have no way to restore a sessions state because Wayland doesn't have a protocol for that. Many times apps will just open totally off screen. Even on Plasma.

Don't speak when you have no idea.

Only issue on KDE might be if you have many monitors, and then use computer without one that was supposed to be the placement of the app. Then it might open off screen.

Of course this is a trivial fix once someone is able to reproduce it. In the general case it obviously does not happen. I have only seen it on long uptime with several suspend /resume /sleep cycles with 1 or 2 monitors randomly active.

99% of cases KDE is perfectly able to remember the window configuration, and it can be manually configured to override the default behavior of remembering it.

So the question is: why should there even be a protocol, when it should be the user that decides where the window is rendered?

[billyswong]

Definitely not how it looks. Colors and themes (eg. rounded/square buttons) should be set by the end user. Only item placement is done by UX of the application.
And this is for various reasons, accessibility being first and foremost. Changing font sizes, colors etc are a great help for people with poor vision.

Those anti-UI-theming people complain UI themes are breaking the custom widgets in their application. They are ignorant that the problem source is not in the themes, but in the lack of a proper way to instruct their custom widgets to inherit or compute styling from that of existing pre-defined widgets in current GTK.

[Serafean]

There's nothing stopping such menu bar system from working under Wayland, Wayland has nothing to do with IPC between applications and the desktop environment, it's only concerned with surfaces and input.

Correct. My point is that the reverse (Global menubar) doesn't work well (anymore) between toolkits, and has problems in snaps/flatpacks. So I'm not holding my breath for consensus on such an IPC protocol.

[duby229]

Don't speak when you have no idea.

Only issue on KDE might be if you have many monitors, and then use computer without one that was supposed to be the placement of the app. Then it might open off screen.

Of course this is a trivial fix once someone is able to reproduce it. In the general case it obviously does not happen. I have only seen it on long uptime with several suspend /resume /sleep cycles with 1 or 2 monitors randomly active.

99% of cases KDE is perfectly able to remember the window configuration, and it can be manually configured to override the default behavior of remembering it.

So the question is: why should there even be a protocol, when it should be the user that decides where the window is rendered?

See what you just did there is you basically, but not in so many words, said, "it works for me, even though I recognize the scenarios it could happen in, so fuck all you"...

I guess projectors don't exist, or docks, or headsets, or second monitors....

EDIT: Your so called 99% is actually more like 30%...