On 2017-01-25 11:37 AM, Jonas Ådahl wrote: > No. desktop-shell.xml is not suitable because it an implementation > detail of the sample desktop shell of weston. It's just one piece of > code, standing next to a bunch of C files. It has never had any > intention of being an exposed API, just as weston/desktop-shell/shell.h > is not. Being generic or not, is irrelevant.
desktop-shell is just an adequate example that doesn't rely on anyone's memory of rejected proposals in times past. > You are misunderstanding. I'm not saying desktop-centered concepts > should not be in wayland-protocols; it's perfectly suitable, and > desirable to have certain things related to the desktop paradigm there. > What I'm talking about is the modular construction of desktop > environments. Writing a "panel" in a way that can be expected to be > portable everywhere will simply not be possible. It only partly is on > X11; having a custom panel on e.g. gnome-shell on X11 isn't really. You're using failings in X11 to justify failings in Wayland. And I don't really expect Gnome to try and support third party desktop shell components on Gnome, nor vice versa. However, Gnome would likely benefit from this approach to their own desktop shell and would gain the advantage of compatibility with a broader set of software. Switching to Wayland doesn't have to demand sacrifices to the end user's workflow - IF compositors participate in these sorts of efforts. > I'm not saying there is anything wrong with the layer approach, but > it'll most likely not be something that can be relied upon by > non-desktop-component type clients, as for example weston (sample > desktop shell) and gnome-shell with little doubt will not add support > for it, as it is simply out of scope. You may be surprised by how many clients will rely on it. Something of this sort is certainly going to land in Sway. Many useful programs will be developed to take advantage of it; I personally have spoken with several authors intending to make such projects. I wouldn't be surprised if something to this effect could land in KDE and many of the smaller compositors as well. Gnome would be the exception, and would support a smaller set of useful software. Gnome should not so coyly prepared to ask users give up tools like OBS, slop, and so on. Gnome will never be able to fully support the gap left in their wake, and shouldn't try, really. The target audience for these sorts of customizations are hackers and tinkerers. This audience has a significant intersection with the sorts of people who might contribute to Gnome in the future. Should they really be alienated? I'm prepared to write the patches for the major compositors to implement this protocol, perhaps with help from some other Sway contributors who share this common goal. > If GTK+ software doesn't run sanely on non-GNOME platforms, do open a > bug, so it can be tracked and fixed, as I'm not aware of the issues you > are referring to. Sorry, I couldn't find the discussion I got this impression from. Consider it retracted. > Regarding reusable components, that might be true, which is why the DEs > that want to go for the modular approach should gather around common > ground and come up with the interfaces they want to share. This is as > far as I know the exact intention of wayland-wall. Resistance to these sorts of protocols leads to fragmentation that is harmful to Wayland, Linux, and software as a whole. If not curbed, I shudder to imagine the state of the Linux desktop in 10 years. I intend to argue for these protocols until they land in the major compositors. However, I'm not so hopelessly optimistic to have any illusions about Gnome or other major players getting on board with wayland-wall. I don't even intend to get on board with wayland-wall. Even if the compositors were on board with it, however, I still don't agree that this protocol belongs there. It's well suited to wayland-protocols. -- Drew DeVault _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
