[PATCH weston-ivi-shell v4 5/9] A reference implementation how to use weston-layout library.

[Pekka Paalanen]

On Mon, 17 Mar 2014 15:28:22 +0900
Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp> wrote:

> The library is used to manage layout of surfaces/layers. Layout change is
> triggered by ivi-hmi-controller protocol, ivi-hmi-controller.xml. A reference
> how to use the protocol, see hmi-controller-homescreen.
> 
> In-Vehicle Infotainment system usually manage properties of surfaces/layers
> by only a central component which decide where surfaces/layers shall be. This
> reference show examples to implement the central component as a module of
> weston.
> 
> Default Scene graph of UI is defined in hmi_controller_create. It consists of
> - In the bottom, a base layer to group surfaces of background, panel,
>   and buttons
> - Next, a application layer to show application surfaces.
> - Workspace background layer to show a surface of background image.
> - Workspace layer to show launcher to launch application with icons. Paths to
>   binary and icon are defined in weston.ini. The width of this layer is longer
>   than the size of screen because a workspace has several pages and is
>   controlled by motion of input.
> 
> Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp>
> ---
> 
> Changes for v2:
>  - squash Makefile to this patch
> 
> Changes for v3 and v4
>  - nothing. Version number aligned to the first patch
> 
>  ivi-shell/.gitignore       |    7 +
>  ivi-shell/Makefile.am      |   19 +-
>  ivi-shell/hmi-controller.c | 1775 ++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 1799 insertions(+), 2 deletions(-)
>  create mode 100644 ivi-shell/.gitignore
>  create mode 100644 ivi-shell/hmi-controller.c

Hi,

so this is the hmi-controller. This is the part that IVI vendors will
be customizing, is it? Or replacing, actually?

The picture in your PDF has both ivi-controller.so and
hmi-controller.so, where the ivi-controller.so is exposing the
ivi-controller Wayland extension. These will be exclusive, right? Never
used at the same time.

hmi-controller.so exposes the ivi_hmi_controller private Wayland
protocol extension, right? So this patch series does not yet have the
ivi-controller part at all, and ivi_hmi_controller is just a part of
the demo that is hmi-controller et al.? And all that would be replaced
by a "real" IVI thing?

Oh yeah, you said the ivi-controller stuff is at
http://git.projects.genivi.org/?p=wayland-ivi-extension.git;a=summary

Okay, I'm actually happy that part is not in this patch series, the
protocol extension looks huge. ;-)

I'm not going through this patch too carefully, just making some general
observations.

There are lots of stuff using the weston-layout API, but I see also a
lot stuff using Weston core API like the grab handlers and seat stuff.
Since this is the part that vendors replace, would it not be better to
have the Weston core related stuff back in ivi-shell.so?

Or is the stuff used here such, that a real ivi-controller will not
need it?

Or is it just a work in progress to establish an abstraction and that
part is still to do?

How independent of a particular compositor implementation is the so
called weston-layout abstraction supposed to be? Will it evolve into a
completely compositor-agnostic API?

I am just trying to understand what exactly the API surface is, that
external modules like ivi-controller.so will be using. Are they allowed
to use Weston core API, ivi-shell.so exported API, only weston-layout
API?

I said it before, that I think you should pay attention to proper
versioning of the weston-layout API, or tie that to Weston core
versioning.

Again, I would suggest:
- document what APIs the external modules can use
- write a header for the API that ivi-shell.so will export for the
  external modules; this would replace the weston-layout.h and be
  smaller
- let ivi-shell.so export the above mentioned API, so you get rid of
  the library interfaces between libweston-layout and ivi-shell; just
  merge the code and remove everything that falls out by refactoring

That would mean external modules used libwayland-server, weston core(?),
and the ivi-shell.so exported APIs, and not additionally depending on
yet another library libweston-layout.so.

I don't think you currently export any API from ivi-shell.so, but
external modules still depend on it anyway, by relying on it using
libweston-layout.so properly. I think it would be good to make this
dependency explicit.

What do you think?
I believe it should work.


Thanks,
pq