Hi,
In Tizen we are about to release the ICO HomeScreen + Murphy based
sysem-controller. One of the idea was to demonstrate how
different toolkits can work together.
In the upcoming release the HomeScreen is able to manage
- GENIVI applications, that use the GENIVI Layer Manager
interfaces directly,
- WRT, ie crosswalk, applications and
- native applications that use some of the toolkits
available in Tizen (eg. EFL).
The EFL apps, like the HomeScreen itself and the SoundSample app,
using the wl-shell protocol, what is the toolkit's fallback shell.
Crosswalks also falls back to wl-shell. The Mock Navigator, that comes
with the genivi-shell package, uses GLM interfaces directly. The
ivi-version of the weston applications (eg. weston-terminal,
weston-flower, etc) are modified such way that in case the xdg interface
is not present they fall back to wl-shell protocol, just like the other
toolkits. In the release the weston-terminal is an exemple that can be
used.
However, I see few issues we would need to clear. The most important
is that in IVI the user interaction paradigm is quite different from
the desktop. In the desktop many things left for the user to deal with,
most notably the layout management. In IVI this supposed to happen
more or less automatically. Automatic means that either some 'manager'
controls the screen layout (centralised model) or each and every
application must have some understanding what is going on in the vehicle
(distributed model).
ICO uses the centralised management approach and the HomeScreen + system
controller decides what and where to show considering many things, eg.
whether the vehicle is on the move, navigation, phone call is active
etc. In the ICO paradigm applications should not be able to show
themselves, get on the top, or go full-size unconditionally, without the
approval of the managing authority, ie. the HomeScreen /
system-controller.
>From this respect executing those request unconditionally in IVI shell
does not appear to be very wise. Those request should be forwarded
to the managing authority for consideration rather than execute them
unconditionally. The ivi-controller interface is quite suitable for
this.
One of the idea with the upcoming Tizen release was to demonstrate that
indeed there is no need to add direct GLM support for each and every
toolkit; they can be used as they are. However, GENIVI folks are not
seem to be enthusiastic about supporting traditional shell protocols in
the GENIVI stack.
So, here are my conclusions/preferences:
- Support one or more shell protocols (eg. wl-shell and/or xdg-shell)
beside the ivi-shell (kind'a modified 2nd way in Manuel's
original mail)
- do not require ivi-shell support from each and every toolkit, browser,
WRT etc.
- do not implement any hardwired policies for the wl- and xdg-shell
calls, eg. map the
xdg_surface_set_minimized => ivi_layout_surfaceSetVisibility
deliver the requests to the managing authority over ivi-controller
interface.
- extend the ivi-controller interface if we missed some events to
support all the shell requests;
we can easily add stuff to the ivi-controller interface as GENIVI uses
the ilm stuff top on that and ignoring the new events in ilm is
trivial change and nobody else, except ICO, is using the
ivi-controller interface so far.
- convince upstream folks about the multiple shell support (once it
has been already there but it was removed). If GENIVI folks do not
want it we could make the wl- and/or xdg-shell support as
compile-time option.
br
-janos-
On Fri, 2014-09-12 at 11:03 +0200, Manuel Bachmann wrote:
> Hello fellow developers,
>
>
> I am coming with an IVI-specific topic, hoping to have some feedback.
>
> As you may know, Tizen IVI intends to have a specific UI based on the
> GENIVI specification.
> It is ICO (1), and is based upon IVI-Shell (2) for its GENIVI API
> layer support.
>
> Currently, it is not possible to run a "standard" Wayland client on
> IVI-Shell, because it has its own protocol, which differs from the
> Wl_shell / XDG-Shell protocols implemented in Weston. (*)
>
> It raises the issue of adaptation cost in the client frameworks (EFL,
> Crosswalk...)
>
> We have 2 ways to fix this :
>
> - directly implement the iVI-Shell protocol in clients ;
>
> - having a XDG-Shell -> IVI-Shell wrapper directly in IVI-Shell
> itself.
>
>
> I just tested the 2nd solution (wrapper). It works pretty well :
>
> - here is the demo code :
> https://github.com/Tarnyko/weston-ivi-shell/commit/42c2c257b636b333f4945b49ab5f7ef94accb432
>
> - here is a screenshot :
> http://www.tarnyko.net/repo/ivi-shell_xdg-shell_compat.png
>
>
> Here, the clients are pure xdg-shell. They do not "know" they are
> running on ivi-shell. Clicking on their "minimize" button works,
> because I remapped "xdg_surface_set_minimized()" to
> "ivi_layout_surface_setVisibility(false)".
>
>
> What is your opinion on this issue ?
>
>
> Regards,
>
>
>
> (1) : https://wiki.tizen.org/wiki/ICO
> (2) : https://wiki.tizen.org/wiki/IVI-Shell
> (*) ICO works around this by using a private API in IVI-Shell, which
> is not upstream.
> --
>
>
> Manuel BACHMANN
> Tizen Project
> VANNES-FR
>
> _______________________________________________
> IVI mailing list
> [email protected]
> https://lists.tizen.org/listinfo/ivi
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
