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 <[email protected]> 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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
