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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel