wayland-protocols scope and governance

[Pekka Paalanen]

On Tue, 19 Feb 2019 13:36:51 -0500
Drew DeVault <sir at cmpwn.com> wrote:

> 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.

Hi,

the list seems purely informative. Is it actually bad if it ends up
containing hundreds of entries? If someone actually wants their
individual apps listed, why not?

A big list may be hard to search, so we could categorize it into e.g.
toolkits vs. individual clients when generating the web pages, so that
people can get a good overview by just looking at the toolkit list.

If people don't keep the software vs. extensions status updated, it only
means there will be lots of "unknown" as to what the attitude of a
given piece of software is towards a given Wayland extension. When we
generate various indices for the web site, "unknown" entries could be
skipped.

To me the main point of such list would be to list a bunch of software
that already supports certain Wayland extensions, but also importantly
list which software projects have refused to support some other
extensions. Both aspects are very important when a developer of an
application or a compositor is contemplating on using specific
extensions.

By no means should the list be exhaustive, just the most used software
plus any that wants in on the list, IMO.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190221/0204f337/attachment.sig>