wayland-protocols scope and governance

[Jonas Ådahl]

On Fri, Jun 21, 2019 at 02:26:02PM -0400, Drew DeVault wrote:

...

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

Both from a use case perspective, technical perspective and
philosophical perspective, xdg-foreign and
wlr-foreign-toplevel-management are fundamentally different.

xdg-foreign allows two tightly coupled clients to act as a single
application. For example lets say a GTK application has a Qt plugin and
want to let the Qt plugin provide its own settings dialog, xdg-foreign
is the glue that makes this possible.

Or for example KDE applications wanting to use GTK file dialogs or vice
versa. The GTK file dialog cannot easily use the same Wayland
connection, so while technically they are two different clients, it's
still the same application.

The in-use application of this (that I'm aware of) is out-of-process
file dialogs via portals; not that different from how native file
dialogs would work.

The important part here is that it's meant for an arbitrary application
to have the tools available to implement it's user interface. It doesn't
break general client isolation; it doesn't try to become a managing part
of the desktop environment.

wlr-foreign-toplevel-manager, on the other hand, is a protocol that

1) breaks client isolation - it exposes toplevel surfaces of all other
clients, and

2) enables a client to act as a window manager - it lets the client
maximize/move/close/.. any other toplevel surface.

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

I find this very irrelevant, as this is not what is generally useful to
whom, but more about portability and setting expectations. Either way,
one potential protocol that has come up is the input method protocol,
and maybe others too.

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

I really don't see it having anything in common with it other than it
has the concept of toplevels. xdg-shell is a protocol allowing
applications to configure its own windows, wlr-foreign-toplevel-manager
is a protocol for creating window management like desktop components.

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

I'm only arguing for keeping the xdg namespace something that will
contain portable protocols, where portable here means usable for
applications that want to function on "all" compositors. An application
relying on wlr-foreign-toplevel-manamegement will never be portable.


Jonas