Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

[Artim]

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.

That would destroy the whole extension ecosystem, so it hopefully will never happen.

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.

I'd guess Theseus' Ship has much bigger chances to do that. Already exists, it is continuing the working he has already done with his previous KWin alternative and is probably modular enough that everyone could agree on it. Only thing it would probably need would be some bindings to e.g. Rust to better integrate with stuff like Cosmic.

[Artim]

Yes, that sounds like a likely equivalent.



I've installed it as a Flatpak to have it update like every other piece of software but this should still be applicable in some form.
Thanks a lot!

Yes, that can be done inside Flatpak too, just have find tell you where exactly that file is located (should be ~/.var/app/us.zoom.Zoom/config/zoomus.conf)

[curfew]

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

Yeah, those aren't bugs.

You can bring up the WM's window context menu usually via Alt-Space or maybe Alt-F10, I don't remember what the standard shortcut was. It should offer enough options for basic users.

It's pretty pointless to expect that all widget-related hacks would be implemented on all apps, but even Gnome (Mutter) supports binding keyboard shorcuts for actions similar to what you described. (I use them too.)

Power users should be comfortable with keyboard shortcuts. Everything else is nitpicking.

[curfew]

That would destroy the whole extension ecosystem, so it hopefully will never happen.

And how exactly? It should be easy to isolate extensions into a simple JS VM process that does nothing else, and preserves the old programming API, which then dispatches Wayland calls using the internal protocols.

[anda_skoa]

Yes, that can be done inside Flatpak too, just have find tell you where exactly that file is located (should be ~/.var/app/us.zoom.Zoom/config/zoomus.conf)

Indeed.
I did that right after your previous hint and it worked nicely

Looks a bit weird but I have reliable behavior back

[fitzie]

That would destroy the whole extension ecosystem, so it hopefully will never happen.

how so? exensions like dash-to-dock (a mac like dock) or openweather (little weather applet) should be perfectly capable of being in a separate process, and to be cross compositor quite frankly. i would think there'd be more "extensions" if they were allowed to be coding in whatever language you want, using a standardized interface to register with the taskbar/query window information.

[Artim]

And how exactly? It should be easy to isolate extensions into a simple JS VM process that does nothing else, and preserves the old programming API, which then dispatches Wayland calls using the internal protocols.

Then I don't really understand what you want to use Wayland protocols for...

[Artim]

how so? exensions like dash-to-dock (a mac like dock) or openweather (little weather applet) should be perfectly capable of being in a separate process, and to be cross compositor quite frankly. i would think there'd be more "extensions" if they were allowed to be coding in whatever language you want, using a standardized interface to register with the taskbar/query window information.

To my knowledge the whole shell is done with JS (at least the visual parts, other parts are done in C), thus the extensions are using JS, as they are pretty much just injecting code into the shell's JS code in order to modify it. So no, extensions can't just be written in any language. The question if extensions should - or even can - run in a dedicated process is something very different. And honestly I doubt that that is a smart idea, as that could easily break the extensions as you'd have to make sure that the extensions code is injected at the right time.

Making such huge changes would inevitably break every single extension, making it much more difficult to port them all to the new model, and it would be questionable if every single extension could still be supported.

[qarium]

Are you alright bro?

no he is right they sell us DRM/Copy-protection as security in the meaning of benefit to the user.

[fitzie]

To my knowledge the whole shell is done with JS (at least the visual parts, other parts are done in C), thus the extensions are using JS, as they are pretty much just injecting code into the shell's JS code in order to modify it. So no, extensions can't just be written in any language. The question if extensions should - or even can - run in a dedicated process is something very different. And honestly I doubt that that is a smart idea, as that could easily break the extensions as you'd have to make sure that the extensions code is injected at the right time.

Making such huge changes would inevitably break every single extension, making it much more difficult to port them all to the new model, and it would be questionable if every single extension could still be supported.

creating a way for external programs to do things to the shell externally doesn't mean everything has to go that route. for example, I use blur my shell extension. that absolutely should remain in javascript as it's playing around with some internal details of how gnome runs.

But i've given two examples of extensions that could just as well be written in any programming language, and aren't modifying the shell in any way, other then declaring their existence.

i would suggest that you start looking glass for yourself, look at the extension you have running.. I suspect a bunch of them are just adding menu entries to the topbar. The reason why those exist because gnome say we're not going to create a standard protocol (a la tray protocol) because we don't want them to exist. well they exist now, and they're inside the gnome shell process slowing things down where they should just be an external process.

if you look at the history behind these decisions you'll see the abuse that caused gnome to get rid of the tray was misguided, and they have been adding it back in the most painful, awkward, and incompatible with other compositors fashion.

and if you aren't rocking any extensions, then you're a happy content gnome user, and that's good for you. I'm not one of those.