Re: The Mythical Sato Replacement

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]

On Tue, Jul 10, 2012 at 09:46:38AM +0100, Richard Purdie wrote:
> On Mon, 2012-07-09 at 15:36 -0700, Khem Raj wrote:
> > On Mon, Jul 9, 2012 at 2:06 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > >
> > > Shuku will be a descendent of Sato, that is continue to use the
> > > Matchbox Window Manager, Desktop, and Panel; although the latter two
> > > will be updated for GTK+ 3.  All applications will be removed and
> > > fully reconsidered when adding back, so the text editor might well
> > > change from leafpad to something that had a release in two years,
> > > Midori is looking like a good web browser choice instead of Web, the
> > > PIM suite removed, and so on.
> > 
> > Did you consider QT instead of GTK+ ? I think having wayland would be cool.
> 
> Ross didn't cover the question "Why do we need anything in OE-Core at
> all?". The answer is that we do need *something* to actually test the
> components we build. Its all well and good having toolchains, libraries,
> architecture support, graphics, X11 etc. but if we can't tell whether it
> works or not we're in a bad way. I've said this before but I want to
> make it really clear that I believe in testing what we ship, otherwise
> its worthless.

But then it still can be in extra layer (maybe in oe-core repo), no?

Basic tests with oe-core only and then test graphics/X11 with
oe-core+meta-foo layer. Where meta-foo can be sato/qt/kde/enlightenment/..
and maintained/released together with oe-core.

Cheers,

> As I see it, there are some significant advantages of matchbox:
> 
> a) It doesn't put us in any one UI camp. I don't want OE-Core to be seen
> as Qt only, or GNOME only, or enlightenment only. I know matchbox uses
> GNOME components but its sufficiently different that it illustrates a
> key value of what the OE architecture offers, the ability to customise
> and innovate. As such I think it makes a compelling reference UI.
> 
> b) Its simple. There is no large complex stack to build and include.
> 
> c) Ownership wise, we can choose which direction to take some of the
> matchbox/sato components in, not least as Ross authored matchbox-desktop
> and matchbox-panel version 2.
> 
> We also need to be mindful of resources and expertise which is something
> people perhaps don't immediately realise. Whist I've been able to find
> the Yocto Project resources to cover the work on the core and much of
> the feature development work we want to undertake, I've struggled to
> convince people to put development resources into replacing Sato as its
> hard to make a business case for or give a specific target for the UI.
> As such, any plan which involves significant development effort is not
> going to be resource feasible. A nice feature of Ross' plan is that it
> can be done incrementally to a degree, it doesn't involve large amounts
> of development effort and we have expertise directly on the team for
> most of the work needed.
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]