[PATCH weston] README: introduce libweston

[Pekka Paalanen]

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.

> > 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