On Wed, Oct 25, 2017 at 2:09 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> 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? > To me, this doesn't seem like an all-or-nothing proposition. Surely an IVI-capable shell can provide implementations for the basic desktop operations: * The shell is already allowed to ignore move requests * The shell is already allowed to ignore resize requests * Very little is guaranteed about a shell surface in toplevel state, so it seems reasonable for the IVI shell to apply domain-specific defaults * It seems just fine to allow transients and popups to be sorted all within the same Z level of their corresponding shell surface, just as libweston-desktop does * Fullscreen and maximized are pretty straightforward, provided that the IVI shell gives heuristics about default stacking policies relative to native IVI surfaces > 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. > Wouldn't that argument just as well apply to the existing ivi-shell implementation that has its controller process? > > 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?). > I agree that there are probably some internal questions about the mechanics of assignment of surface IDs from desktop surfaces needs specified. But that doesn't seem like a wholesale refutation of the idea that generic desktop programs can be displayed sanely in a shell which happens to support IVI concepts. > > 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. > It seems like this might be driven by some past negative experience. Is there anything you could share? As an integrator of Wayland/Weston onto embedded systems, I'm not off-put by the idea that I need to thoroughly test the applications I'm deploying. The use-cases are typically very well understood and constrained though, so I've not had the experience that some wild desktop-centric action is requested when the app runs in the wild, that I never saw during development. BTW, I'm trying to be careful to draw the distinction between saying that I have the responsibility to thoroughly test my applications, from the conclusion that this justifies re-writing the applications in terms of some or other ivi-shell API. That's very difficult to arrange when independently suppliers are delivering applications. > > 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
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
