Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

[fitzie]

As long as it's working, they won't see any need to change that. Especially not when they have by far the most mature and bug-free DE, especially when it comes to Wayland. Plasma just caught up in terms of maturity, but as long as every other release is that buggy, Gnome devs probably don't feel too threatened.

totally agree with you both that they won't see any need, and they have the most robust DE. I used to reread this every now and then:

https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4

and hoped that gnome-shell wouldn't rest on their laurels and address some of the legacy structure of gnome-shell. i wish they would fully embrace systemd and purge xorg code from gnome-shell (not x11/xwayland, just running on xorg), I wish they would create wayland protocols for all the internal stuff they are doing so that you don't need to run as javascript inside the shell pid to program your desktop. I used to hope that gnome would start to leverage wlroots, but it's clear that wlroots really is a toy, and I'm convinced a dominant rust library is the only way forward for wayland compositors. until then my current dream is that you'll be able to run full window managers under xwayland and I'll go back to fvwm2.

[Artim]

In the menu it is in a sub menu "Move to desktop" where it is one of the options.
But I was talking about a button to get this quicker.

I use this not just for Zoom but all video conference windows to follow me when I switch virtual desktops.

At least I never noticed something like that. But then, since Covid isn't keeping everyone home anymore, I haven't used Zoom that much in quite a while.

Not, this is for using more than one monitor, so orthogonal to virtual desktops.

Ah. So I only know the options "Always on visible workspace" and "Move to Workspace right". The first one seems to do what you are looking for. And if it is, I know how you can fix you situation.

If you installed Zoom as a normal package (i.e. as a .deb or .rpm package), it keeps its settings in ~/.config/zoomus.conf. To bring back the title bar, you need

showSystemTitlebar=true

in there.

[anda_skoa]

Never saw any "on all desktops" button in an app's header bar context menu.

In the menu it is in a sub menu "Move to desktop" where it is one of the options.
But I was talking about a button to get this quicker.

I use this not just for Zoom but all video conference windows to follow me when I switch virtual desktops.

But yes, current Zoom doesn't seem to have any typical header bar and thus doesn't allow access to such menus.

Yeah, it is broken in more than one way.

But in settings you have a "use dual displays" mode, maybe that does what you are looking for.

Not, this is for using more than one monitor, so orthogonal to virtual desktops.

[Artim]

Zoom, which seem to have switched to exclusively CSD, lost the "on all desktops" button in the process.
Sadly it does not offer an easy way to switch its broken title bar off, so I can only wait, hope and pray that they will eventually fix their bug

Never saw any "on all desktops" button in an app's header bar context menu. But yes, current Zoom doesn't seem to have any typical header bar and thus doesn't allow access to such menus. At least not in the default mode. But in settings you have a "use dual displays" mode, maybe that does what you are looking for.

[anda_skoa]

The second popular argument is that with server-side decorations all windows can / will have identical titlebars. That doesn't make any slightest sense. This was back when Gnome and KDE apps could have pretty much the same look and feel through theming, because the paradigms of their underlying toolkits were really close to each other. Nothing would prevent the same theming from decorating titlebars as well.

Visual consistency is a nice to have thing, people can be annoyed about difference but are usually able to cope.

The important thing is behavioral consistency because differences in behavior breaks workflows.

Since there is no single implementation for CSDs it is easy to encounter one that is broken in one way or another.

Chrome defaults to CSD and has a quite nicely looking title bar.
However, last time I tried it, it had a bug that makes its "maximize" buttons expand the window in both dimensions regardless of which mouse button clicks it.
I.e. system configuration is to maximize vertically if the right mouse button is used but Chrome ignores that and fill the whole screen.

Fortunately Chrome provides an easy way to fix this by having a "use system title bar" (or similar phrasing) option in its title bar's context menu.

Zoom, which seem to have switched to exclusively CSD, lost the "on all desktops" button in the process.
Sadly it does not offer an easy way to switch its broken title bar off, so I can only wait, hope and pray that they will eventually fix their bug

[Artim]

the protocol isn't the hard part it's getting gnome-shell to support it. it's a monolith that needs to be separate into many separate processes, but they have been avoiding dealing with their technical debt except for minor cleanups like the input thread. sad.

As long as it's working, they won't see any need to change that. Especially not when they have by far the most mature and bug-free DE, especially when it comes to Wayland. Plasma just caught up in terms of maturity, but as long as every other release is that buggy, Gnome devs probably don't feel too threatened.

[fitzie]

Question is if it needs to be its dedicated protocol. GTK-devs are working on it, but no idea if they even use any special protocol for it.

the protocol isn't the hard part it's getting gnome-shell to support it. it's a monolith that needs to be separate into many separate processes, but they have been avoiding dealing with their technical debt except for minor cleanups like the input thread. sad.

[anda_skoa]

Will DE compositors implement such idea?

That is what they already do.
They combine the output of content processes (applications) into the screen content and adding UI to switch between them
The only difference is that they are usually not using tabs but putting each content process output into a window.

Technologies like the GTK Wayland Compositor Widget or Qt's Wayland Compositor module enable application other than web browser to use the same approach as well.

[Artim]

The GNOME always on top action is provided via the shell and its right click window menu so not something the app can activate by itself, AIUI:

https://gitlab.gnome.org/GNOME/gnome...type=heads#L98

It seems that while apps don't provide it, they can opt out of it. I have several Qt5 apps that have that button greyed out, like Kate and Dolphin, while Notepadqq doesn't. Kdenlive and OBS as Qt6 apps also has that button greyed out, while Qt6 settings and a few other Qt6 apps I have show it.

[access]

It is a joke that all your praises of Wayland security disappear conveniently for whenever functionalities that happen to be not used by you. Moving a window is supposed to be a job of the window compositor. It should be functional no matter the user application is hanging or not. A program hangs and looks like the user needs to wait it a while until it finishes its job. So the user moves it to a convenient spot outside the center of focus. This is a simple workflow. Nothing fancy.



In an SSD application, the "Always on Top" button is provided by the compositor. No security sandbox breaking. In a CSD application, the "Always on Top" button is provided by the application itself. What magic does Gnome know, such that Mutter can differentiate between user clicking on that button within the CSD application, and the application pretending such button has been pressed by user? Sorry, if such magic is possible, all the rationale of restricting Wayland protocol functionality will be moot.

Please, just admit that allowing CSD applications to contain an "Always on Top" button is sandbox breaking. Stop act as if Gnome is always right and "think before you write".



Painting any inconvenient truth that you refuse to face as "bs rants", wow.

p.s. I agree with Gnome standpoint of not giving applications a mean to place their windows in arbitrary absolute coordinate without sanitization. A broken clock is correct twice a day.

The GNOME always on top action is provided via the shell and its right click window menu so not something the app can activate by itself, AIUI:

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowMenu.js?ref_type=heads#L98

I can't recall seeing any "on top" button in any GNOME/GTK apps, at least not Wayland based ones. I guess apps running via xwayland might try but I suspect the on top hints are just ignored.