On 2017-01-25 9:54 AM, Jonas Ådahl wrote: > Hi, > > By the looks of it, this is a protocol extension that aims to enable > desktop environments to be built of interoperable components (i.e. a > "background" process to draw a (live?) wallpaper, an "overlay" thing > could be used to create a panel, popup launcher or alt-tab view or > something). Is this correct? > > ... > > If I misunderstood the intention of the protocol, do let me know. I > didn't see any use cases spelled out, so I am just assuming.
You're correct. There are numerous other use-cases this enables that you're missing, though. Here's a few that come to mind: - dmenu/rofi style applications - slop style applications - an android-like notification drawer As well as basic desktop components like: - screen locks and screensavers - on screen keyboards - panels - wallpapers (live or otherwise) - desktop icons I put forth some use-cases in my initial proposal, but I've repeated them here. > If so, I believe this type of protocols, and probably many others > similar to this one (there have been others passing by wayland-devel as > well), would be best suited "wayland-wall"[0] or something similar, > where modular compositor developers who want to choose what type of > modularity they want to support can pick at their discretion. > > Thus, I don't think it is suitable for wayland-protocols, as I think the > focus of it should rather be an extension of Wayland proper > (wayland.xml) where client and compositor developers can look for > protocols that can be considered relatively portable. "Modular > compositor" protocols mostly cannot be portable in the same sense. I have a few arguments to pose in response to this. Not all of this is in response to your specific concerns, but I'll extrapolate this discussion a bit based on what I expect to hear based on previous discussions. 1. surface-layers learns from previous proposals Similar protocols have been discussed here before, and have been largely rejected. I designed this protocol with the benefit of hindsight. The motivation behind rejecting many of these, I believe, is that they're too specific. Weston's desktop-shell.xml isn't suitable for wayland-protocols because it explicitly outlines the supported use-cases as things like panels and wallpapers and such, that specifically accommodate a likely Weston-specific desktop shell. This protocol (and the ones that will follow) support the same uses-cases, but are much more generic and applicable to a wide variety of compositors. As a consequence they also support a much wider range of use-cases than i.e. desktop-shell.xml. I'm sure you'll agree that this protocol can support many use cases we haven't though of, whereas desktop-shell.xml's wallpaper interfaces are tied quite closely to the specific use-case of wallpapers. 2. wayland-protocols and wayland.xml already make similar and more egregious assumptions I summarize this aspect of your viewpoint as a desire to avoid desktop-specific paradigms leaking into core Wayland bits, and a desire for Wayland to support more novel compositor designs than the desktop. However, I think that (1) the damage is already done, and (2) surface-layers is conservative in this regard anyway. Design choices have already landed in wayland-protocols and wayland.xml that are closely associated with a desktop UX. xdg-shell has interfaces which have clearly been designed to accommodate a traditional desktop UX and traditional UI toolkit designs. It includes features like the positioner, which only really exists to support context menus; minimizing and maximising; the implication that xdg surfaces are floating windows that are user-resizable with a mouse. wayland.xml itself has several similar assumptions, including features like drag-and-drop and clipboard support. Both of these are arguably outside of the scope of wayland.xml, have clear origins in the desktop UX, and have questionable re-applicability for novel compositor designs. surface-layers is comparatively much more conservative. The only assumption it makes about the compositor is that the wl_outputs have edges. wayland.xml implies this and more about outputs, including things like the idea that outputs may be rotated along one axis, that they have a two-dimensional position in global compositor space, a width and height (thus are rectangular), modes (and with them resolutions and refresh rates - specifically vertical refresh rates). None of this is relevant to a compositor that uses 3D space, for example, which there is already a functional PoC of in the wild. We can assume, as surface-layers does, that outputs have edges or at least that a novel compositor has implemented some workaround to support wayland.xml anyway. 3. The desktop players stand to benefit from surface-layers, or at least don't have anything to lose from it I believe the desktop shells components of the major players can be implemented based on surface-layers.xml - and if that's not true, point out where it's lacking and let's try to shore it up. Basing your desktop shell on surface-layers is likely to simplify your design, if nothing else. The major players on Wayland have done a poor job at cooperating to produce reusable components. The walled garden of each compositor is incredibly harmful to Wayland's adoption. There's not much use to making a more secure and maintainable Linux desktop if no one will switch to it because you can only use GNOME software on it and it doesn't support their favorite application. So far the major players have been very hostile to the idea of designing their software to be usable across platforms, GNOME even going so far as to not care about GTK software running sanely on anything but GNOME. This attitude is very disappointing. Even if the major players don't care about reusability, protocols like surface-layers are a better design than what's in place now. Implementing protocols like this will improve your compositor. As a free (or cheap) side effect, it would be nice if some of your components ran on other compositors, and it would be nice if third parties could expand the desktop experience in ways you haven't thought of. -- Drew DeVault _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
