[PATCH weston] ivi-shell: add screen_remove_layer API

[Ucan, Emre (ADITG/SW1)]

Hi Pekka,

> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> Sent: Montag, 6. Februar 2017 13:47
> To: Ucan, Emre (ADITG/SW1)
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH weston] ivi-shell: add screen_remove_layer API
> 
> On Mon, 30 Jan 2017 14:42:42 +0000
> "Ucan, Emre (ADITG/SW1)" <eucan at de.adit-jv.com> wrote:
> 
> > Hi Pekka,
> >
> > You are right. I will send second patch and add the function to end
> > of the function list.
> >
> > It is stated in ivi-shell/README that ivi_layout interface is stable.
> > But I think should not be stable yet. Because we are missing some
> > important features (e.g. output hotplugging) or some existing
> > feautures are IMO unnecessary (e.g. orientation). Furthermore,
> > libweston is changing quite fast. It gets new features in every
> > release. If we want to use these new features in ivi-shell, we have
> > to add new APIs time to time into ivi_layout interface.
> 
> So far libweston also breaks its ABI on every release (major version
> bump). That covers also ivi-layout API in my opinion, but has not been
> clearly documented I believe. The opinion may have even been different
> at the time of writing the README, too - I think it was before
> libweston was a thing.
> 
> In any case my standpoint is that ABI breaks are major features unless
> there is a very good reason to break things closer to a release.
> 
> > I want to implement a shared library for ivi-shell (libweston-ivi)
> > similar to weston-desktop library, when I have time. Then, it would
> > be easier to handle ABI breakages. Because it will be parallely
> > installable. Another advantage is that adding an API would be just a
> > minor version bump, because it would be backwards compatible.
> 
> There are a lot of shared objects involved with ivi-shell already.
> Would be nice to see some high level plans and architecture
> documentation on how it all fits together and which parts can change
> how. I fear there might be too many different interfaces that need to
> be maintained.

What is the preferred document type for a design document in wayland community?
Should I put these information in READMEs or create some sequence diagrams ?

> 
> Would you swallow ivi-layout into libweston-ivi.so?

My basic idea is to merge ivi-shell and ivi-layout together and create libweston-ivi.so.
Only input panel stuff should move to controllers.

> 
> Will hmi-controller.so be a plugin to weston, ivi-shell or
> libweston-ivi.so?

 Hmi-controller should be new shell plugin for weston.

> 
> Will the ivi-shell plugin remain with Weston, or move to libweston? Or
> will it become libweston-ivi.so?

Ivi-shell should move to libweston-ivi.so. Only hmi-controller should remain with Weston.

> 
> IVI is different from libweston-desktop: the latter needs considerable
> code for handling the client-facing protocols and it implements many
> practical details, while leaving the high-level window management to
> the user (the desktop-shell plugin). IVI however has very little
> client-facing protocol and all of window management is externalized to
> controller plugins, so it's hard to see any analogue.
> 
> If your idea is to transform ivi-layout into libweston-ivi.so, merge
> ivi-shell plugin into it, and change controller plugins to be on the
> same level as the desktop-shell Weston plugin is, I think that might be
> a good idea. A libweston-based compositor written purely for IVI would
> not need a controller as a plugin at all, but just link to and use
> libweston-ivi which offers the window management interfaces (ivi-layout
> API).

Exactly.

> 
> I'm not asking you answer these questions here in this thread, but they
> are things I think you would need to consider.
> 
> 
> Thanks,
> pq
> 
> PS. In my mind I have had the idea of turning main.c et al. into a
> static convenience library and turning each shell plugin into a
> separate executable instead. But, it's a lot of work for questionable
> gain, and will have issues with weston-launch.

Best regards

Emre Ucan
Software Group I (ADITG/SW1)