This is a great plan, Daniel, thank you for taking the time to write it up and help push this problem towards a solution.
On 2019-02-19 4:50 PM, Daniel Stone wrote: > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots Sway & wlroots probably shouldn't be separate, but it might be useful to link to the list of wlroots-based projects from the compatability page: https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots These projects rarely, if ever, implement protocols themselves, opting instead to implement them in wlroots and share the functionality with everyone else. > - toolkits: EFL, GTK, Qt GLFW, SDL > - media: GStreamer, Kodi, VLC, XBMC mpv > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) This might start getting out of hand, I think. Here's an incomplete list of clients which use wlr protocols: - mako - slurp - grim - wl-stream - xdg-desktop-portal-wlr - swaylock - swayidle - swaybg (soon) - waybar - jaybar - phosh - virtboard - bemenu This is just the clients I can think of off the top of my head. Consider also demo clients, like weston and wlroots clients. There's going to be a lot of clients! Something I want to avoid is making the criteria for inclusion in the list subjective, and if we have to decide what makes GLFW worth including and weston-simple-egl worth excluding, I fear politics will ensue. > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. What is the criteria for having a voice in this xdg namespace "consensus"? This seems a bit opinionated and subjective. > Or Weston hasn't implemented xdg_foreign and probably won't, but I'm > fine with it existing and being a common extension. On the other hand, > Weston/Mutter/etc would have very strong opposition to a 'wp_randr' > extension, and last I saw wlroots would have very strong opposition to > wp_pointer_gestures. So those wouldn't be wp. This makes me wonder: what's the role of Weston in this? As a reference compositor which isn't designed for end-users, I don't think Weston has ever been well-positioned to be an influencer on Wayland, but should rather be a reflection of what Wayland is without its influence. Do you have any thougths on this? In other words, if Weston doesn't want to implement $protocol: so what? How do/should the gatekeepers of Weston make these decisions? > Bikeshedding the prefix to use [for vetoed but still relevant > protocols] would be welcome, as I don't have any good suggestions > right now. xdg? I think gatekeeping the xdg namespace is going to allow a lot of the frustrating politics to thrive even with these changes, and it is a nice namespace for defining these standards. > Once we've established and codified these ground rules - with a > document along the lines of Wayland's CONTRIBUTING.md - we can open up > commit access to wayland-protocols, so we're not so reliant on a > couple of arbitrary gatekeepers. Obviously this would be done with the > expectation that those ground rules are followed - don't post a wp_ > extension on a Sunday morning and then commit it in the evening with a > couple of +1s because no-one objected - but we're all reasonable > adults, and can treat each other reasonably without having to enforce > ACLs. > > Does anyone have any thoughts or suggestions here? Is this a good > aspiration? Is it the best way of achieving that aspiration? +1 I don't see commit access as a magic equalizer, fwiw. I don't mind sending a patch along and letting someone else integrate it so long as they're following well-defined policies and not operating under their own agenda. Another thing I'd like to clarify is the process of agreeing on the appropriate prefix for a protocol. Perhaps there's an experimental_ or draft_ namespace which has a near-zero barrier to entry (just add your implementation to the list), and then you can separately make your case for adopting it into another namespace. During the draft step you can pitch your protocol to interested parties, write implementations, and so on, which strengthens the case for including it in some namespace. Under this process, the xdg and wp and whatever else namespaces reflect reality, and each protocol there is known to have the support of at least a few implementations - rather than reflecting that at some point some number of people agreed it would be a good idea, and then maybe or maybe didn't write implementations. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
