[PATCH weston] README: introduce libweston

[Giulio Camuffo]

2015-07-15 12:23 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Wed, 15 Jul 2015 12:03:34 +0300
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>
>> 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
>
>> > 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.
>
> Of course, step by step. :-)
>
>> >
>> > 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.
>
> Perhaps, but I think a safer default would be to start with such things
> in the host program, and then if compositor projects want them,
> think about how to share them.

Ah, sure, I agree with that.

>
>> > Are there other plugins I've forgot?
>>
>> Well, there are the text/input method plugins... to be decided what to
>> do with them too.
>
> Oh yeah, good point.
>
> At first, I think input methods should be left out of libweston. They
> have GUI elements, need shell cooperation, and so tie quite much to the
> DE.
>
> Well, many of them, I suppose. If one implemented just the compose key,
> that would be pretty universal. But IIRC the input methods Weston has
> is just the OSK, which falls into the DE domain.
>
>> > 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?
>
> It's a define we use in our build, -DIN_WESTON. It's only used by
> shared/matrix.c. Hmm, not sure why I listed it with libweston related
> things.
>
>
> Thanks,
> pq