On 2019-03-08 11:28 AM, Daniel Stone wrote: > > If we're establishing a table, it may make sense to give wlroots as a > > whole a seat at that table. wlroots is where the implementation lives, > > after all, for all of the compositors who use it. We already kind of do > > this with wlr-protocols. > > If they're happy for you (or wlroots as a project) to speak for them > all, then I have no problem with it.
I spoke with everyone and we're in agreement on this point. We can always split into more entities later. However, based on this we ought to be careful with anything like voting where a majority or percentage of members is required. We wouldn't appreciate exchanging voting power for convenience. > J> I think formalizing a set of categories, including wp_ and xdg_ and at > J> least a third one is a good idea. I think that with a "free for all" > J> method suggested by Pekka, where we put all the responsibility on > J> everyone else to figure out what protocol fits under what category > J> (because there will still, in practice, be categories, we just avoid > J> spelling them out), we loose too much in terms of discoverability and > J> perceived scope. It'll be harder to know what to expect. > J> > J> What I mean here is that it should be clear what protocols are > J> "plumbing" (e.g. wp_viewporter), what protocols are for window > J> management related tasks where the application aim to be portable in a > J> sense that they will work on both fully integrated and non-integrated > J> compositors (e.g. xdg-shell and xdg-decoration), as well what protocols > J> are for applications that want to be a building block of a > J> non-integrated compositor (e.g. the layer shell protocol). I don't think > J> it's possible to avoid politics completely here, no matter how > J> "annoying" it is, because protocol development is partly about that. > J> There are most likely good reasons Khronos have chosen to work like > J> this as well. > J> > J> A protocol support matrix will still be very useful here either way, and > J> I expect all categories will include protocols with varying support, as > J> so is the situation already, but it wouldn't be the only source of > J> clarity of scope and potential adoption. > J> > J> We could also keep the door open for other groups of protocols, such as > J> IVI and maybe even those for fully coupled systems like the content > J> protection protocols that has been floating around, assuming those who > J> write protocols agree to act as maintainers and use our versioning > J> system. > > Under what he's describing, xdg_shell isn't miscategorised, because it > _is_ the thing that everyone agrees on and uses. If we reserve xdg_* > for uncontroversial/unvetoed things, then xdg_shell would presumably > be a part of that. I think xdg_shell's primary focus is definitely the > desktop, and it's pretty unapologetic about that, but there is enough > wiggle room that it's usable way beyond the desktop. Same thing with > the XDG specs, where the ICCCM is useful for kiosks, .desktop files > are useful for phones, xdg-basedir is useful for display walls, etc. I still maintain that xdg-shell is somewhat shoehorned in for cases which are not the desktop. But that's kind of what I'm getting at: > I think xdg_shell's primary focus is definitely the desktop and > [xdg-shell] is the thing that everyone agrees on and uses. If we > reserve xdg_* for uncontroversial/unvetoed things These are in conflict. There are protocols which are unsuitable to the desktop, like IVI shell, which may nevertheless have unanimous support among the compositors which use it. I could see more shells being made in the future, particularly for mobile, as I don't think xdg-shell is designed with mobile well enough in mind. In other words: xdg cannot at once be the unanimous view of all of Wayland and a desktop-centric namespace. > > > XDG is already overloaded enough that I'd like not to add 'stuff some > > > people use but others feel very strongly about not using' to it. Some > > > people also interpret XDG to mean 'freedesktop.org Certified Seal of > > > Approval™', which is ... sort of the opposite of that. > > > > The frustrating problem is that xdg-shell exists and is stable and is > > called xdg-shell. We should probably rename xdg-output, by the way, > > before it becomes stable. > > Mm, but then shell is agreed on by everyone? Even IVI moved over to > xdg_shell for clients. Who do you have in mind who feels very strongly > about not using it? Me :) I were to make a mobile compositor (and I very well might) and I was willing to patch clients with support for a new protocol (doubtful), I think I would do that before I'd use xdg-shell. The main issues that come to mind are: - Interactive move/resize probably doesn't make sense on mobile. xdg-shell was influenced by parties who are strongly in favor of client autonomy, but on mobile there's really no reason for me to let you move or resize yourself on a tiny screen. You get 100% of the screen whether you like it or not, and this protocol doesn't acknowledge that possibility. - set_parent doesn't generally make sense on mobile "Strong" is the wrong word to describe these opinions. In practice I would probably end up using xdg-shell on a mobile compositor because it's definitely Good Enough. I just want to take xdg-shell off of this pedistal and make an example of it for illustrative purposes. > > Fair point. Once we establish a role for each prefix, then it might be > > good to establish a group of stakeholders with commit access and a > > gentleman's agreement between them to follow the rules we set forth. > > As for membership in this group: I propose inviting a diverse group of > > existing stakeholders, including at least the people we've already > > talked about (let's add Smithay to that, too). Then new members can be > > added by invitation from an existing member. If we have a large and > > diverse enough membership, I'm less concerned about gatekeeping. If you > > just have to convince at least one member to sponsor your membership, > > then that's should be easy enough. > > Sounds good, or maybe for consistency we could just treat members like > the 'uncontroversial' protocol prefix space: proposed by an existing > member with no vetos from the others. I don't like the idea of giving out veto power. Perhaps rejecting inclusion given some minimum number of NACKs would be better. > That sounds fine, but I'm not sure when I'll have time/bandwidth to > write up what I've put forward in this thread. I'd happily participate > in review of write-ups from anyone else though. ack Aside: what if we deal with namespace inclusion by using NACKs to express disagreement on categorization? A protocol could be added to any prefix given it meets these criteria: 1. It has an implementation 2. The authors deem it worthy of inclusion In practice I hope these criteria wouldn't have to be appealed to, and a discussion among members on why the protocol should or should not be added to a namespace would be fruitful. However, if consensus cannot be reached then the protocol database would be updated to reflect the protocol author's wishes nevertheless, and the dissentees would be allowed to express their dissent through NACKs, which appear on the website (and perhaps can include a small blurb explaining the rationale). In this way, the website reflects reality moreso than politics: the authors of the contentious protocol are going to use it and implementations are going to proliferate even if consenses is not reached, and therefore the website faithfully documents that protocol's real-world usage; and those who raise an objection to it have a place to make their case to anyone interested in that protocol. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
