Wayland Protocol Extensions Are Being Talked About A Lot This Week

[phoronix]

Phoronix: Wayland Protocol Extensions Are Being Talked About A Lot This Week

If you are looking for some Wayland drama, check out the most commented on mailing list thread this week: collaboration on standard Wayland protocol extensions...

http://www.phoronix.com/scan.php?page=news_item&px=Wayland-Protocols-March-2016

[rabcor]

What I think is needed the most is a cross-shell context menu extension. One major thing that Windows has over Linux regardless of which DE you use (as far as I'm aware) is that applications over at windows can create context menu entries (like winrar can create extraction menu entries in the file manager, graphics drivers can create a context menu shortcut to their control panel only when the desktop itself is right clicked)

E.g. a context menu extension that will take input from some file and filter to desktop, file manager/file, window borders and taskbar (just in case), so that applications could have a single target for implementing context menu entries regardless of which desktop environment a user may be on, if said environment chooses to support it (or even has context menus)

This could at least create a sort of illusion that linux distributions are slightly more unified than they are, and a predictable behavior across environments for the end users.

Environments could invidiually include alignments for each entry (e.g. all shell context menu entries come in on bottom, all file manager entries come in on top or second from top, etc, etc)

[ssokolow]

What I think is needed the most is a cross-shell context menu extension. One major thing that Windows has over Linux regardless of which DE you use (as far as I'm aware) is that applications over at windows can create context menu entries (like winrar can create extraction menu entries in the file manager, graphics drivers can create a context menu shortcut to their control panel only when the desktop itself is right clicked)

E.g. a context menu extension that will take input from some file and filter to desktop, file manager/file, window borders and taskbar (just in case), so that applications could have a single target for implementing context menu entries regardless of which desktop environment a user may be on, if said environment chooses to support it (or even has context menus)

This could at least create a sort of illusion that linux distributions are slightly more unified than they are, and a predictable behavior across environments for the end users.

Environments could invidiually include alignments for each entry (e.g. all shell context menu entries come in on bottom, all file manager entries come in on top or second from top, etc, etc)

While it's limited to filesystem objects filtered by lists of mimetypes, I think I remember hearing that Nautilus, Thunar, and PCManFM have unified around the DES-EMA spec for custom actions.

(I'm not sure whether KDE has updated to match or whether they still use only their own .desktop-based solution which predates DES-EMA.)

[KellyClowers]

Wow, Rasterman kinda has his head up his ass. Protip dude: People are trying to switch over to Wayland *now*, and they are going to want things to work. And yes the things he mentioned also need work, but like the other guy said, it is possible to work on more than one thing at a time.

I don't know much about things like tablets and drawing programs and other things mentioned, but I do know people want/need to do both still and video capture (recording and live - ever hear of twitch? ustream? picardo? youtube streaming? not to mention things like IM based streaming to specific people. These are real things people do, all the time), and not all use cases will be covered by whatever solution the compositor implements.

P.S. CSD can DIAF

[Delgarde]

And yes the things he mentioned also need work, but like the other guy said, it is possible to work on more than one thing at a time.

Well, no... it's not. The number of people available to work on it is actually very small. And while features like screen capture do need to work, developing the protocols to implement those features in a standardised way across all compositors is a a very difficult problem to solve well, and isn't actually *necessary*. Doing things in a standardised manner is definitely nice to have, but if the features can be more quickly implemented without it, standardisation can come later, once everyone has their basic features working, and more importantly, has acquired some experience of implementing these things for themselves.

And I'm not belittling the requirement to have features like desktop video streaming over IM... it's a very useful thing. But it's a long way from being the most important thing for the Wayland projects to be working on right now... especially if they can at least make it (in the short term) that the Gnome IM can work with Gnome compositor, the KDE IM with KDE, and so forth. Standardisation and compatibility can evolve over time.

[Delgarde]

Oh, and my view on this? Most of what's being discussed does not need to be built into the Wayland protocols, as such - any more than the window-manager protocols needed to be an integral part of X11. It will probably be necessary to develop some standardised means for processes to interact with the compositor, for functions like screen capture and streaming, and to provide metadata about windows to cover presentation functions, etc. But not all of that needs to be part of Wayland itself, and for the most part, that standardisation is not a prerequisite for Wayland adoption - it's important in the long run, but not critical in the short term.


From my reading of the upstream threads, I think a lot of the contention is because Drew represents the 'classic' UNIX/X11 model - lots of small pieces doing a single job, a window manager that only manages windows, separate from the program launcher, which is in turn separate from the taskbar and pager. But most of the effort behind Wayland is coming from the DE model - GNOME, KDE, Enlightenment - and the DEs have very little interest in doing things the old way. It doesn't fit their world-view, of having a tightly integrated system.

To Drew, a screen-capture tool is a standalone application, pick one, any one. But to GNOME, a screen capture tool is a compositor plugin - or at least, a plugin that talks to a standalone application. To Enlightenment, it's not even a plugin - it's something that just gets built into the compositor. It's the same with screen configuration tools - Drew favours generic tools like xrandr that work with any desktop. But GNOME has that in their control panel, communicating with the compositor via GNOME's own configuration frameworks. And again, Enlightenment has that built into the compositor - from Rasterman's point of view, it's the same as an app having a preferences window...

(I'm not mentioning KDE here, because they've not expressed much opinion. My impression is that they're open to the idea, but not overly convinced of the value.)

[BwackNinja]

X is friendly to building your desktop in pieces.

Wayland, fundamentally through it's protocols, is looking like it's not going to be (for some good reasons, like security, but still unfortunate).

We'll end up with lots of DE-specific tools, and anything trying to be "minimal" won't have any, or will have to make their own. This is again, unfortunate, but it's hard to say that the DEs should do the work of creating tools for the simpler compositors. It's looking more and more like applications will only seem "right" or even work at all in one or only a select number of environments and not others.

Fewer Wayland Compositors will likely be written, though it's interesting to see that all of the tiling compositors so far are centering around libraries wrapping a lot of the wayland stuff rather than implementing it directly.

Maybe X, despite all of it's faults, demonstrates the only (notice how I didn't say "sane") way to cater all of the different ways everyone wants their desktop to work?

[swoorup]

I think those stuff Drew mentioned shouldn't belong in the core wayland protocol, but that doesn't mean it should be left at the current state. It should be discussed under desktop's only? Not much I can add

[Delgarde]

X is friendly to building your desktop in pieces.

Wayland, fundamentally through it's protocols, is looking like it's not going to be (for some good reasons, like security, but still unfortunate).

I don't think that Wayland is inherently *unfriendly* to that way of thinking. But by very deliberate design, there are some things that are intentionally impossible for applications to do without cooperation with the compositor... looking at the contents of other application windows, monitoring keyboard presses in other windows, etc. Things which are dodgy in general, but may have some legitimate cases. And for those things to be possible at all under Wayland, there's a need for some kind of interface that simply didn't need to exist on the inherently insecure X11. That could be some kind of universal permissions-requesting protocol, as suggested in the upstream thread - or it could be as simple as DE-specific compositor plugins, as Gnome seems to favour.

We'll end up with lots of DE-specific tools, and anything trying to be "minimal" won't have any, or will have to make their own. This is again, unfortunate, but it's hard to say that the DEs should do the work of creating tools for the simpler compositors. It's looking more and more like applications will only seem "right" or even work at all in one or only a select number of environments and not others.

I don't think it has to be that way, for any technical reason. But I think that's certainly how it *will* be, at least in the short term - getting to Wayland is easier for the DEs if they focus on their own needs and problems, instead of engaging in the exhaustive process of trying to come up with standardised solutions that work for everyone. The latter can come later, if there's a real desire to make such things possible...

[Tomin]

X is friendly to building your desktop in pieces.

Wayland, fundamentally through it's protocols, is looking like it's not going to be (for some good reasons, like security, but still unfortunate).

I think that a compositor could be written with X-like capabilities to be extendable but not secure (I say not secure because it's just easier). Maybe even such way that it requires another program to actually manage windows and that is similar to current window managers (that might not make too much sense though, it's just a thought). The Wayland developers think that a lot of the capabilities discussed don't belong to Wayland, but if compositor wants to implement something they won't tell them not to. I think Kwin (KDE) and Mutter (GNOME) will not add things that lessen security (at least not without a good reason), but that doesn't mean others can't.

There are already Wayland extensions made for Kwin that allow changing display resolution and some other things that might be useful for those "hobby" compositors.
https://lists.freedesktop.org/archiv...ch/027695.html