[PATCH weston 00/14] Desktop Protocol Support for IVI-Shell

[Matt Hoosier]

On Wed, Oct 25, 2017 at 2:09 AM, Pekka Paalanen <ppaalanen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171025/171b0303/attachment.html>