[PATCH weston] README: introduce libweston

[Giulio Camuffo]

2015-07-15 11:43 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Wed, 15 Jul 2015 10:51:34 +0300
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>
>> Hi, one comment below but it looks ok to me, also with Bryce's comments.
>>
>> 2015-07-14 13:07 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:
>> > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>> >
>> > What is libweston and where do we intend to go with it.
>> >
>> > Cc: Giulio Camuffo <giuliocamuffo at gmail.com>
>> > Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>> > ---
>> >  README | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> >  1 file changed, 138 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/README b/README
>
>> > +Libweston design goals
>> > +----------------------
>> > +
>> > +The high-level goal of libweston is that what used to be shell plugins
>> > +will be main executables. Instead of launching 'weston' with various
>> > +arguments to choose the shell, one would be launching
>> > +'weston-desktop', 'weston-ivi', 'orbital', etc. The main executable
>>
>> That's ok, though splitting weston in various executables is not my
>> goal so i don't think i'm going to do it :P.
>
> Sure, no problem. :-)
>
> It's just a logical extension as I'm sure other projects will want to
> have their own main(), and up to now we have assumed they are just
> plugins.
>
> I think converting Weston to do this will help in the libweston API
> design. Our shell plugins want to launch several processes, so it will
> be simpler if they just do it with our main.c provided code, rather
> than plumb through libweston.
>
> Do you have an opinion about other plugins?
>
> I would suggest that libweston would not have "a plugin API" for
> loading shared objects that are not libweston internal details. Any
> plugin system would be specific to the hosting program. Of course,
> those plugins could use the libweston API as they wish, if the host
> program intends it.
>
> This means that if we share the Xwayland XWM implementation through
> libweston, xwayland.so will be a libweston internal detail. That's all
> good so far, but then other projects likely want their own code for
> drawing the X11 decorations so we're going to need some API for that.

That makes sense, but i think as a first step we can ignore it and
keep the cairo decorations in libweston, or maybe even have them
forever with the ability to swap them with custom ones.

>
> I never looked into the color management plugins enough to make a guess
> whether they should be completely or partly a (optional) libweston
> feature. Maybe Weston could just offer (renderer-specific?) ways to set
> the color correction parameters (LUT, matrix, whatever), and it would
> be the host program's responsibility to get those parameters from
> somewhere?

I'm not sure, i never looked into the colord plugin either... The more
we can share between compositors the better, but i can't really
comment on it right now.

>
> Are there other plugins I've forgot?

Well, there are the text/input method plugins... to be decided what to
do with them too.

>
> hmi-controller.so is plugin to the ivi-shell plugin, so it naturally
> becomes a plugin for the weston-ivi host program.
>
> Just so the following doesn't get lost, some time ago I gathered a
> small TODO list for post-libweston:
> - remove IN_WESTON
IN_WESTON?
> - weston-launch to launch all kinds of libweston apps; argv[0] based?
> - turn desktop-shell from a plugin into an executable
> - turn ivi-shell from a plugin into an executable
> - remove -export-dynamic
>
>
> Thanks,
> pq