On Mon, 30 Jan 2017 14:42:42 +0000 "Ucan, Emre (ADITG/SW1)" <eu...@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. Would you swallow ivi-layout into libweston-ivi.so? Will hmi-controller.so be a plugin to weston, ivi-shell or libweston-ivi.so? Will the ivi-shell plugin remain with Weston, or move to libweston? Or will it become libweston-ivi.so? 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). 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.
pgpu4peW2_KIu.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel