wayland-protocols scope and governance

[Drew DeVault]

Followed-up off-list while fixing issues with my mail client, copying
summary here for posterity:

On Wed Jun 19, 2019 at 5:08 PM Jonas Ådahl wrote:
> Lets not be childish; noone is trying to weasel anything here, and I
> don't understand what you're trying to accomplish by implying that.

I didn't mean weasel wording in a pejorative way, just as a metaphor for
trying to nail down a precise definition which includes the protocols
the speaker wants and excludes those they don't (myself included).

> On Wed, Jun 19, 2019 at 10:52:32AM -0400, Drew DeVault wrote:
> > How does xdg-foreign fit into this definition?
> 
> xdg-foreign is an edge case but IMHO it fits in the definition.
> xdg-shell deals with stacking order of the dialogs of an application.
> xdg-foreign extends this behaviour by allowing two clients to "act as
> one". The current users are the xdg-desktop-portal backend, but it's
> something that's needed for e.g. modal dialogs for out-of-process
> plugins and similar things.
> 
> It's far from task bar like functionality, if that's what you are trying
> to compare it to.

I don't think xdg-foreign is especially different from
xdg-toplevel-management so far as the applicability of this definition
is concerned. It comes across as seeing XDG as suitable for anything
GNOME et al needs it for, and unsuitable for things wlroots et al needs
it for (though perhaps unconsciously). I think this is derived from the
fundamental philosophical differences between our design approaches, but
not necessarily from the definition of "XDG".

Put another way, what are some protocols GNOME would implement which are
(1) useful for other compositors and (2) more suited to the ext
namespace than the xdg namespace?

> Again, I believe the definition should make it clear that it's for
> applications, not desktop components. I'm not trying to weasel anything
> here, I'm trying to avoid making anyone believe writing a task bar is
> the same thing as writing an application that is expected to work
> everywhere.

Again referring to the xdg-foreign protocol, an argument could be made
that the sandboxing tooling it was designed for is a feature of the
compositor. After all, the sandboxing mechanism holds a privileged
position on the desktop model, and xdg-foreign is a mechanism it uses
for plumbing its way around self-imposed constraints, rather than an
inherent property of application windows.

I'm not arguing that xdg-foreign isn't suitable for the XDG namespace,
but rather showing that a similar argument against
xdg-toplevel-management's inclusion can be applied to xdg-foreign.

I guess, in short, I feel that xdg-toplevel-management is a fit for the
XDG namespace because:

- It's more or less a direct extension of the xdg-shell protocol
- It deals entirely with the management of application windows

The argument against comes across as:

- It's not something fully integrated desktops would use

Which to me feels like gatekeeping the xdg namespace. I want to
establish namespaces based on consistent rationale that we can all
incorporate our work into, and that's probably going to mean being
somewhat more lenient than we have been in the past. That's a necessary
concession for this governance overhaul's success as a whole.