Re: Proposal for better collaboration on xdg-shell
Yeah. I think some people were assuming xdg-shell was final, and I was its gatekeeper, and it's what GNOME wants and you have to fight to get other things in. That wasn't my intention at all! My goal was to build a solid base for the rest of the DEs to eventually work more like how Bryce wants, but I was imagining it would work a lot more informally, sort of like how wm-spec-list works. If there are *any* controversial features in xdg-shell that you don't like, please let me know! The goal here is to make sure that it's a good base for everybody, so by the time you roll around to implementing it, xdg-shell is exactly what you want, and you can start with custom extensions to implement stuff that's specific to your DE. Even GTK+ has plenty of features in a custom gtk-shell that other DEs probably don't care about. On Mon, May 11, 2015 at 12:38 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Mon, 20 Apr 2015 17:10:08 -0700 Bryce Harrington br...@osg.samsung.com wrote: A while back Pekka asked if I'd help look at xdg-shell and how we can ensure it really does become a cross-desktop standard. I promised to engage with the EFL folks and get their feedback, which I posted recently. snip http://lists.freedesktop.org/archives/wayland-devel/2015-April/021465.html Hi all, Bryce wrote a good and essentially simple proposal for getting things rolling again. However, it turns out that my and his underlying assumptions were not exactly true. We assumed that desktop projects want to go forward all the time, on their own schedule. To support that, Bryce wrote this proposal. Since then in IRC, GNOME (with Jasper's voice) has said they can actually wait for other DEs, especially KDE, to get on board. So it seems the current plan is to keep xdg-shell in limbo at least until KDE people can focus on it properly. And other DE projects, too. In other words, not to hurry, but think things through with all major players. Just letting you all know and collecting a hopefully good selection of CCs to get the teams covered. Thanks, pq -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Proposal for better collaboration on xdg-shell
A while back Pekka asked if I'd help look at xdg-shell and how we can ensure it really does become a cross-desktop standard. I promised to engage with the EFL folks and get their feedback, which I posted recently. I also promised to look at the Plasma team's comments on xdg-shell.xml from some months back, and to suggest changes to xdg-shell.xml that might make it more inclusive to their needs too. However, in looking at the prior discussions around KDE's feedback, and especially seeing the tenor of discussions regarding this recent EFL feedback, I'm seeing some really bad anti-patterns at work: 1. There is really no substitute for getting the DIRECT feedback from the compositor implementers. 2. It is proving impossible to get all the D-E stakeholders to deliberate in real-time. Everyone's implementing Wayland on widely dispersed schedules. 3. Developers seem to not want to pin down their needs specifically until they're in the midst of their own Wayland development. But then they need their protocol fully fleshed out ASAP so they can get the work completed. Development can't wait on committees. 4. Once a D-E has finished compositor implementation, there is little incentive to entertain changes, esp. if they got their work into the standard already. The first implementor thus gains a game-breakingly strong first-mover advantage in our protocol development process. 5. The early adopters will then be on defensive to *prevent* further changes. Their motivation will thus be to lock down the protocol as unchangeable (probably earlier than it should) and suggest everyone else make their changes in their own private protocols. 6. If you're not the first D-E contributor, getting your changes in will be an adversarial process. As this can be frustrating, you are motivated to take the alternative and just do your own thing as a private protocol, and just modify the subset of clients you care about to support that protocol. You decide to let cross-desktop be Someone Else's problem (goto 1). 7. Ultimately our collective goal and reason we're bothering with all of this to begin with, is to establish a lowest-common-denominator protocol(s), that an arbitrary third-party client can rely on when ensuring their software will be portable across a plethora of desktop environments. a. Otherwise: Fragmentation b. Also, declaring a desktop standard which no one in Linux actually follows makes us look dysfunctional. We deserve all the laughs that we get. Given that steps 1-6 seem unlikely at producing #7, I don't think that just more poking at the API is going to get us across the threshold. What we need is a better process for developing the protocols in the first place, which respects late-comer feedback and rewards collaboration rather than just being first. I.Desktop environments are expected to maintain their own private protocol(s) in their own repositories. These can correspond to what they actually use, and what they expect clients to use. II. Weston's current protocol/desktop-shell.xml is renamed to protocol/weston-desktop.xml[1] as it is considered a Weston private protocol. III. A new repository is established on freedesktop.org. 0. This repository exists under the purview of the Wayland project: http://cgit.freedesktop.org/wayland/desktop-protocols/ 1. Alternatively, we establish a subdir within the xdg-specs repository under the purview of the Freedesktop Specifications project, such as: http://cgit.freedesktop.org/xdg/xdg-specs/wayland-desktop/ IV. A 'proposed' subdirectory is added to the wayland/desktop-protocols git repository. Per-desktop environment subdirectories are created in this repository named proposed/desktop-environment/, containing proposed protocol standards they wish to suggest other desktop environments follow. For example, these could be protocols the D-E considers stable for itself. 0. These protocol files should scope their globals and interfaces with identifiers unique to that D-E. It's also recommended that the generated C symbol names also be scoped to avoid clashes with the other D-E's. 1. Lesser-known D-E's are welcome. In particular, any D-E mentioned on Wikipedia's D-E page will be gladly received. https://en.wikipedia.org/wiki/Desktop_environment 2. D-E's should first obtain push access from FDO to the repository for their principal compositor developers, then add a subdirectory for their D-E. These individuals are welcome to push directly to their subdirectory; no gatekeeper review required. Do not push to other D-E subdirs or to the common standard spec directory without their review and Okay.
