Hi, On Wed, 13 Mar 2019 at 01:03, Drew DeVault <s...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel