wayland-protocols scope and governance

[Daniel Stone]

Hi,

On Wed, 13 Mar 2019 at 01:03, Drew DeVault <sir at cmpwn.com> wrote:
> On 2019-03-08 11:28 AM, Daniel Stone wrote:
> > Under what he's describing, xdg_shell isn't miscategorised, because it
> > _is_ the thing that everyone agrees on and uses. If we reserve xdg_*
> > for uncontroversial/unvetoed things, then xdg_shell would presumably
> > be a part of that. I think xdg_shell's primary focus is definitely the
> > desktop, and it's pretty unapologetic about that, but there is enough
> > wiggle room that it's usable way beyond the desktop. Same thing with
> > the XDG specs, where the ICCCM is useful for kiosks, .desktop files
> > are useful for phones, xdg-basedir is useful for display walls, etc.
>
> I still maintain that xdg-shell is somewhat shoehorned in for cases
> which are not the desktop. But that's kind of what I'm getting at:
>
> > I think xdg_shell's primary focus is definitely the desktop
>
> and
>
> > [xdg-shell] is the thing that everyone agrees on and uses. If we
> > reserve xdg_* for uncontroversial/unvetoed things
>
> These are in conflict. There are protocols which are unsuitable to the
> desktop, like IVI shell, which may nevertheless have unanimous support
> among the compositors which use it. I could see more shells being made
> in the future, particularly for mobile, as I don't think xdg-shell is
> designed with mobile well enough in mind. In other words: xdg cannot at
> once be the unanimous view of all of Wayland and a desktop-centric
> namespace.

ivi-shell is two things: the window-management side
(hmi-controller/ivi-layout libraries, ivi_wm protocol), which is just
an API and protocol to do normal window management things; also the
application-shell side (ivi_application protocol as a counterpart to
wl_shell/xdg_*). The former does have users and implementations based
on it, but no-one likes the latter.

In fact, Weston's server-side ivi-shell now supports xdg_* clients,
and the long-term direction of travel is to remove ivi_application
support everywhere. There are a couple of reasons for this. One is
that recompiling Chromium to change surface ID 5000 to surface ID 5010
sucks. The other is that having to keep a Chromium fork to add
ivi_application support (because no-one ever merged it) or fix
ivi_application support (because no-one ever tests it) really bites -
especially when multiplied for every client you might want to run.

There's a little more detail in this FOSDEM presentation:
https://fosdem.org/2019/schedule/event/wayland_ivi/attachments/slides/3064/export/events/attachments/wayland_ivi/slides/3064/fosdem2019_wayland_in_ivi_jeka.pdf

and this Weston MR:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/86

> > Mm, but then shell is agreed on by everyone? Even IVI moved over to
> > xdg_shell for clients. Who do you have in mind who feels very strongly
> > about not using it?
>
> Me :)
>
> I were to make a mobile compositor (and I very well might) and I was
> willing to patch clients with support for a new protocol (doubtful), I
> think I would do that before I'd use xdg-shell. The main issues that
> come to mind are:
>
> - Interactive move/resize probably doesn't make sense on mobile.
>   xdg-shell was influenced by parties who are strongly in favor of
>   client autonomy, but on mobile there's really no reason for me to let
>   you move or resize yourself on a tiny screen. You get 100% of the
>   screen whether you like it or not, and this protocol doesn't
>   acknowledge that possibility.

Sure, it doesn't make sense to have to handle these - the protocol
does already give you latitude though, stating that 'the server may
ignore' both types of requests. xdg-shell clients on ivi-shell Weston
have their move/resize requests ignored, and that's totally OK. Same
as if you were tiled by a WM which refused to let you untile, or
fullscreen, etc. (From what I understand, the Purism phone does the
same thing? Or did, at least.)

> - set_parent doesn't generally make sense on mobile

I think it makes just as much sense. Mobile still needs to present
dialogs - pick a photo, share through another app, select a contact,
etc - and when you go to your window list, you don't want to see those
dialogs separately, they're a modal part of the app window. So
set_parent is still useful there.

I don't see xdg-shell being _primarily_ aimed at desktop usage, and
xdg-shell being totally usable by clients in more constrained
environments, as being in conflict. Supporting tiling window managers
already gives you most of what you need to support constrained
environments like IVI, kiosks, etc. If you were writing your own
environment completely from scratch then another shell might be
viable, but for almost everyone it seems to be better to add a couple
of empty vfuncs to ignore interactive move/resize, than maintaining a
patchset for every toolkit and bit of client middleware you use to
support your own shell.

The initial idea was indeed that clients should support divergent
client-facing shell protocols for each type of environment they were
used in, but ultimately it just doesn't seem to have worked out.

Cheers,
Daniel