On Tue, 24 Oct 2017 09:08:19 -0500 Matt Hoosier <[email protected]> wrote:
> I'm not at all familiar with the internal implementation of ivi-shell, so I > can't give much meaningful review. But I am very much in favor of this > patch series. Without wl_shell and xdg_shell support, I've never been able > to really give ivi-shell serious consideration on my products. The ability > to use generic client Wayland programs is very important. Hi, the very reason why ivi-shell ever came to be was that the operating environment of graphical applications in IVI was so different from a normal desktop, that it was simply impossible to have desktop applications work in a meaningful way there. I would like to hear why and how this has now changed. The premise of supporting desktop shell protocols in an IVI-shell environment is that all desktop applications using the full extent of the desktop shell protocols will always work correctly and meaningfully, without modification. How will that be possible without specifically writing the applications to behave in IVI-specific ways? Assuming the above is possible, I also see the risk that lego-block desktop environments will start using ivi-shell to push window management into an external process, undoing a lot of the benefits of a Wayland architecture simply because that is how X11 worked. When I glanced through the proposal, I didn't find an example implementation of the most important new component introduced: the ivi-surface id agent. Hence I do not think it is possible to fully evaluate this work as is. I don't even understand how it can show desktop shell protocol using windows at all without an id agent - I believe it should not, because if it does, then it is bypassing the IVI controller which I cannot imagine to be a wanted feature. Simply the fact that it is using libweston-desktop means that the IVI controller cannot manage all the surfaces (libweston-desktop exposes only top-level windows and handles everything else internally - how could the internal handling be always correct in an IVI environment?). IMO, an id agent should be mandatory. Otherwise it is too easy to just forget about it and trust your luck that the desktop apps and libweston-desktop will keep on behaving as you happened to test and that the behaviour would be appropriate in an IVI environment to begin with. If you proposed that e.g. some outputs were dedicated for desktop apps and some outputs for IVI apps, then I could see it working without complete IVI controller integration, as the two categories would be kept separate. It would be like running a desktop compositor on some outputs and an IVI compositor on the other outputs (which is actually implementable real soon now thanks to DRM leases, or already with fullscreen-shell protocol). But as I understand, this proposal is aiming to mix both kinds of apps on the same outputs, is it not? I am confused how this proposal is a proper solution, as I'm not sure what the problem to be solved is. Why do you want to run desktop apps on an IVI system instead of apps that are designed for work right in an IVI system? Thanks, pq > On Tue, Oct 17, 2017 at 5:51 AM, Ucan, Emre (ADITG/ESB) < > [email protected]> wrote: > > > Hi, > > > > I already reviewed the patches before Michael sent: > > Reviewed-by: Emre Ucan <[email protected]> > > > > Best regards > > > > Emre Ucan > > Engineering Software Base (ADITG/ESB) > > > > Tel. +49 5121 49 6937 > > > > > -----Original Message----- > > > From: wayland-devel [mailto:wayland-devel- > > > [email protected]] On Behalf Of Michael Teyfel > > > Sent: Dienstag, 17. Oktober 2017 12:02 > > > To: [email protected] > > > Subject: [PATCH weston 00/14] Desktop Protocol Support for IVI-Shell > > > > > > Hello all, > > > > > > since some time I’m working on ivi-shell to add xdg-protocol support by > > > means of libweston-desktop. Due to my changes both xdg-protocol > > > applications and ivi-shell / ivi-application-protocol applications are > > supported > > > within ivi-shell now. The known functionality is preserved and just > > extended > > > by a further protocol. The advantage is that client applications do not > > need to > > > be edited to generate an id and are also not limited to use the custom > > ivi- > > > application protocol anymore, since the ids are handled by an id agent > > inside > > > of weston now.
pgpxaXjKPULwL.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
