[OE-core] [Openembedded-architecture] Future of sato and X in oe-core

[Alexander Kanavin]

The question is: what are the use cases for an 'example/reference UI'? Why
have one at all at this point? Remember, the core project is severely
under-staffed and we need to commit our limited resources wisely.

Alex

On Tue, 11 Feb 2020 at 14:53, Adrian Bunk <bunk at stusta.de> wrote:

> On Tue, Feb 11, 2020 at 01:49:27PM +0100, Alexander Kanavin wrote:
> >...
> > - matchbox is reliant on gtk3 (to be obsoleted by gtk4 this year), and
> does
> > not have a Wayland compositor. Yocto project does not have the resources
> to
> > do the gtk4 port, or add a compositor.
> >
> > - no 'lightweight Wayland compositor with a desktop/launcher experience"
> > has emerged in the open source space; I think the only realistic choice
> at
> > the moment is the reference compositor Weston which provides a blank
> > desktop with ability to open terminal windows.
> >
> > So the way I think things should be going (seeking opinions/inputs of
> > course):
> >...
> > - oe-core continues to support and runtime-test X for as long as
> possible;
> > for this a new image (say, 'core-image-sato-xorg') is created which will
> > provide matchbox under X. However, once upstream bitrot sets in, and pain
> > threshold is exceeded, this will be removed and/or relegated to a legacy
> > layer.
> >
> > Thoughts?
>
> matchbox made sense at a time when you could go into a shop and buy an
> internet tablet with Linux running on 256 MB flash with 256 MB RAM.
>
> Part of the problem is that the only remaining usage of this branch
> of matchbox development seems to be as example UI for Yocto.
>
> For matchbox/sato I am wondering whether replacing it with parts of
> meta-xfce from meta-openembedded would be a good way forward.
>
> Upstream Xfce still seems to be 2-3 years away from gtk4 and Wayland
> support, but at the point where supporting X might become a problem
> this should be available.
>
> Xfce was my first thought as replacement since it appears to be
> well-maintained in meta-openembedded, no strong opinion whether
> it is actually the best option.
>
> > Regards,
> > Alex
>
> cu
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200211/d8d32bac/attachment-0001.html>