> > I understand that it would probably be bad to take a bunch of protocols > > that no one has any stake in, this is why I disagree with wayland-wall. > > However, layer-shell has the backing of 5 compositor implementations > > (likely to be 6 soon) and has many client implementations. Is the role > > of wayland-protocols to be a small few who judge the worthiness of > > protocols for inclusion, or an instrument of the community? Because the > > community supports this protocol. > > I think you are again misunderstanding my intentions here; this is not > about "worthiness", but about what kind of use cases that are in scope > where.
My question is: who defines the scope? > > I disagree. I think that the scope should be functionality several > > compositors and/or clients implement. wayland.xml is for functionality a > > client can expect from any compositor. > > This is not the original intention of wayland-protocols. It should be > thought of as a continuation of wayland.xml, rather than a bag of > arbitrary protocols that happen to have multiple compositor > implementations. The original intention and what it's now become are two different things, a fact we seem to agree on. I think we should embrace what it has become. > Missing pointer gestures support is also fine; that's part of the point; > it's an optional extension and a client will most likely work good > enough without it, but it's still mostly a continuation of what > wl_pointer provides. I disagree that the idea that pointer gestures is a continuation of wl_pointer is a valid characterization of that protocol. I also think that any client which can work equally well without it is a client which has no reason to use it. > Again, think of wayland-protocols as the continuation of wayland.xml, > not as some arbitrary collection. Today, a client can most likely not > just use what's in wayland.xml but will explicitly rely on something > outside of it, for example xdg-shell. xdg-shell is already not appropriate for every Wayland compositor. That's why IVI shell exists, for instance. If wayland-protocols is taking a desktop stance, then layer-shell belongs. If it's taking a more general stance, then layer-shell belongs. > I think you put too much value in providing a single entry point for all > protocols, when there are no practical reasons for requiring it. > Separation here is good, as it creates a clear distinction of what a > client can expect. Maybe what we need is another repository under > wayland/, explicitly for desktop components. This is assuming it is made > very clear that the APIs provided there is not something a regular > third party application can rely on and expect to be portable in any > way. The new version of the input-method protocol would be a good > contestant to adding there as well maybe. I think I put an appropriate amount of value in having a single entry point. This is a place where every compositor has a stake and a reason to collaborate. I also think it would be very folly to remove input-method from this repository. If we were to start down this road, the first thing I'd put forth for removal is xdg-shell. > Anyway, that's not something we can do anything about now except adding > some disclaimer in the documentation about not using it (i.e. wl_shell), > or maybe adding "deprecated" attributes to the XML format. Aside: I'm in favor of a deprecated attribute in the XML format, and we're working on sunsetting wl_shell for good over in wlroots. There may soon be a patch from one of us adding deprecation support to wayland-scanner. -- Drew DeVault _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
