<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 25, 2017 at 2:09 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
the very reason why ivi-shell ever came to be was that the operating<br>
environment of graphical applications in IVI was so different from a<br>
normal desktop, that it was simply impossible to have desktop<br>
applications work in a meaningful way there.<br>
<br>
I would like to hear why and how this has now changed.<br>
<br>
The premise of supporting desktop shell protocols in an IVI-shell<br>
environment is that all desktop applications using the full extent of<br>
the desktop shell protocols will always work correctly and<br>
meaningfully, without modification.<br>
<br>
How will that be possible without specifically writing the applications<br>
to behave in IVI-specific ways?<br></blockquote><div><br></div><div> 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:<br></div><div><br></div><div>* The shell is already allowed to ignore move requests</div><div>* The shell is already allowed to ignore resize requests<br></div><div>* Very little is guaranteed about a shell surface in toplevel state, so it seems reasonable for the IVI shell to apply domain-specific defaults</div><div>* 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</div><div>* Fullscreen and maximized are pretty straightforward, provided that the IVI shell gives heuristics about default stacking policies relative to native IVI surfaces</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Assuming the above is possible, I also see the risk that lego-block<br>
desktop environments will start using ivi-shell to push window<br>
management into an external process, undoing a lot of the benefits of a<br>
Wayland architecture simply because that is how X11 worked.<br></blockquote><div><br></div><div>Wouldn't that argument just as well apply to the existing ivi-shell implementation that has its controller process?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
When I glanced through the proposal, I didn't find an example<br>
implementation of the most important new component introduced: the<br>
ivi-surface id agent. Hence I do not think it is possible to fully<br>
evaluate this work as is.<br>
<br>
I don't even understand how it can show desktop shell protocol using<br>
windows at all without an id agent - I believe it should not, because<br>
if it does, then it is bypassing the IVI controller which I cannot<br>
imagine to be a wanted feature. Simply the fact that it is using<br>
libweston-desktop means that the IVI controller cannot manage all the<br>
surfaces (libweston-desktop exposes only top-level windows and handles<br>
everything else internally - how could the internal handling be always<br>
correct in an IVI environment?).<br></blockquote><div><br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
IMO, an id agent should be mandatory. Otherwise it is too easy to just<br>
forget about it and trust your luck that the desktop apps and<br>
libweston-desktop will keep on behaving as you happened to test and<br>
that the behaviour would be appropriate in an IVI environment to begin<br>
with.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you proposed that e.g. some outputs were dedicated for desktop apps<br>
and some outputs for IVI apps, then I could see it working without<br>
complete IVI controller integration, as the two categories would be<br>
kept separate. It would be like running a desktop compositor on some<br>
outputs and an IVI compositor on the other outputs (which is actually<br>
implementable real soon now thanks to DRM leases, or already with<br>
fullscreen-shell protocol). But as I understand, this proposal is<br>
aiming to mix both kinds of apps on the same outputs, is it not?<br>
<br>
I am confused how this proposal is a proper solution, as I'm not sure<br>
what the problem to be solved is. Why do you want to run desktop apps<br>
on an IVI system instead of apps that are designed for work right in an<br>
IVI system?<br>
<br>
<br>
Thanks,<br>
pq</blockquote><div><br></div><div><br></div></div></div></div>