On 2018-05-08 4:17 PM, Daniel Stone wrote: > Fair enough. I brought it up only because of the introductory text: I > think having some more context/disclaimers/etc would help.
Yeah there'll be a PATCHv2 in the future elaborating on that. > > These ideas are still somewhat nebulous but I'm confident enough that > > it'll work that I think we can proceed with the discussion on protocols > > like layer-shell. Compositors which are interested in implementing these > > protocols and securing them today can do something simple like > > weston_client_launch as a temporary solution and make it more accessible > > to third parties later. > > I think they sound like a fine idea; is anyone working on implementing them? No, not yet. It's something we intend to push for before sway 1.0, though. > There are three parts in play here: > * running generic applications (a browser, mail client, image > viewer) under some kind of environment (let's call these 'apps') > * running desktop component clients (background, home screen, panel) > under a specific environment (let's call these 'non-app clients') > * running an external client which controls stacking, focus, other > window management, of both apps and non-app clients (let's call these > 'external WM') > > 'ivi-shell' is all three of those. > > --%<-- I see, and I think I better understand how these protocols are supposed to work now. > layer-shell obviously doesn't duplicate the app interface, and it's > not designed (I don't think? I only read the wlr-protocols pull > though, not the external ones) to support external WMs. But maybe > coming up with a common expression of layers (and their relationship > to surfaces) would be helpful, non-app clients for both IVI and > building-block compositors could then use the same. Obviously IVI > external WMs would need a separate interface, and maybe both > building-block systems and IVI systems would need to extend on top of > the common layer protocol for their own needs. But that's cool, I > think xdg-surface has shown that actually works better than everyone > completely going their own way. A unified layer abstraction could be interesting, but the ivi shell protocol is too generic for me to understand the use-cases they're trying to fulfill with their layers. Also, some layer-shell concepts like anchors and exclusive zones are foreign to ivi-shell. Inversely, some ivi-shell concepts are undesirable in layer-shell, particularly allowing clients to arrange themselves directly with x/y/width/height. Overall I don't think integrating ivi-shell and layer-shell with each other would be good. I might be convinced with more discussion. > > In short, we think that embracing the differences between shells is a > > better design than attempting to fit a square peg in a variety of holes. > > Given the above, I'm not sure whether I violently agree or totally > disagree with you here: which components are you talking about? :) I think your 3 categories of client is not a long enough list. In particular I would split this one up: > * running generic applications (a browser, mail client, image > viewer) under some kind of environment (let's call these 'apps') I strongly disagree with the decision to have xdg-toplevels handle their own movement, resizing, and so on. But at this point, we have to live with it, and this causes me to characterize xdg-toplevel applications as being suitable _only_ to the desktop. IVI and phones and so on have different requirements that aren't served by xdg-toplevel. So I'd change your category to "desktop" applications and add another: * "phone-style" (for lack of a better term) applications (a browser, mail client, image viewer) which can expect to not manage its own size or position on screen. This necessitates a separate shell. Maybe this shell uses xdg-surface... but I see very little advantage in doing so. Using xdg-toplevel would be totally nuts. -- Drew DeVault _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
