All of lore.kernel.org
 help / color / mirror / Atom feed
* The Mythical Sato Replacement
@ 2012-07-09 21:06 Burton, Ross
  2012-07-09 21:33 ` Martin Jansa
  2012-07-09 22:36 ` Khem Raj
  0 siblings, 2 replies; 8+ messages in thread
From: Burton, Ross @ 2012-07-09 21:06 UTC (permalink / raw)
  To: OE-core

Hi all,

I've been mulling over a replacement for the Sato environment for some
time now, so I think it's time to talk about my thoughts and get more
feedback from users of oe-core.

Some background: back in 2007[1] Sato was designed to be an
reference/demo PDA environment for mobile devices with (relatively!)
high-DPI but physically small screens[2], such as the Sharp Zaurus and
Nokia 770/N800/N810/etc.  It was designed to look visually distinctive
compared to the competition at the time, and demonstrate all the
features that a handheld PDA should have (at the time).  I think it's
fair to say it mostly succeeded at that although it didn't exactly set
the world on fire.

Fast-forward five years: Sato is still part of oe-core and showing
it's age and unsuitability for the requirements that oe-core now has
compared to the original design requirements for Sato.

So, what does oe-core require from a graphical environment?  As this
is oe-core the list should be fairly short, so how about:
- some way of launching arbitrary applications
- a terminal
- a text editor
- a web browser
- network configuration
- an interactive test suite for verifying that various pieces of
hardware are working: play a media file, show touchscreen events,
display key events, and so on.  More about this later.
- lightweight

There's also a set of anti-requirements:
- no half-baked PIM suite
- no games
- no giant dependency stack or tight integration into the rest of
oe-core.  Pulling the Sato replacement out entirely, or reusing parts
of it, should be easily done.

Re-using an existing environment is one option but I don't think it's
a great one.  LXDE is very minimal but the Windows 95 aesthetic isn't
exactly attractive, XFCE is surprisingly large these days.  We don't
really want much, so I think maintaining our own shell is a worthwhile
investment.

Hopefully there aren't any objections so far?  I'll assume not, and
introduce my proposal for Project Shuku[3].

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.

The interesting bit is then the test application.  We need a graphical
environment so that we can run applications specific to our needs (and
the desktop handles this fine already) and verify that the system is
in fact working correctly.  Currently this is done in an ad-hoc
manner: using the music player to play audio files, gst-launch to play
videos, poking at the the touchscreen to verify that it works.  I'm
proposing a specific test application so that instead of attempting to
use general purpose applications as test tools, we have a specific
tool.

For example, when playing back a video file it's important that any
hardware acceleration available is actually used.  The test tool could
play the file using GStreamer's playbin and then display the resulting
pipeline so you can verify that VAAPI is being used, the correct audio
sink, the correct network source, and so on.  To verify that the input
devices are working, list them at the evdev level and let you see the
raw events, display touches, and so on.

I've also been considering the brave new world of Wayland.  Whilst
porting to GTK+ 3 all of the X11-specific code can be logically
separated so that a small Weston plugin can be written that integrates
the pieces together.  This will give a Wayland-native graphical
environment that is visually identical to the X environment.

There's plenty of other things to discuss -- visual design and so on
-- but that can wait for another day.

So those are my thoughts.  Any comments?

Ross

[1] Five years ago!
http://www.burtonini.com/wordpress/2007/08/01/poky-linux-3-0-blinky-released/
[2] QVGA, for example, was explicitly not a target.  The Sharp Zaurus,
a typical test device, had a VGA screen.
[3] In the glorious tradition of naming projects by translating words
to other languages, I ended up with 尗 (U+5C17) which means "younger of
brothers", and Shuku is one of the pronunciations.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-09 21:06 The Mythical Sato Replacement Burton, Ross
@ 2012-07-09 21:33 ` Martin Jansa
  2012-07-09 22:36 ` Khem Raj
  1 sibling, 0 replies; 8+ messages in thread
From: Martin Jansa @ 2012-07-09 21:33 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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

On Mon, Jul 09, 2012 at 10:06:11PM +0100, Burton, Ross wrote:
> Hi all,
> 
> I've been mulling over a replacement for the Sato environment for some
> time now, so I think it's time to talk about my thoughts and get more
> feedback from users of oe-core.
> 
> Some background: back in 2007[1] Sato was designed to be an
> reference/demo PDA environment for mobile devices with (relatively!)
> high-DPI but physically small screens[2], such as the Sharp Zaurus and
> Nokia 770/N800/N810/etc.  It was designed to look visually distinctive
> compared to the competition at the time, and demonstrate all the
> features that a handheld PDA should have (at the time).  I think it's
> fair to say it mostly succeeded at that although it didn't exactly set
> the world on fire.
> 
> Fast-forward five years: Sato is still part of oe-core and showing
> it's age and unsuitability for the requirements that oe-core now has
> compared to the original design requirements for Sato.
> 
> So, what does oe-core require from a graphical environment?  As this
> is oe-core the list should be fairly short, so how about:
> - some way of launching arbitrary applications
> - a terminal
> - a text editor
> - a web browser
> - network configuration
> - an interactive test suite for verifying that various pieces of
> hardware are working: play a media file, show touchscreen events,
> display key events, and so on.  More about this later.
> - lightweight
> 
> There's also a set of anti-requirements:
> - no half-baked PIM suite
> - no games
> - no giant dependency stack or tight integration into the rest of
> oe-core.  Pulling the Sato replacement out entirely, or reusing parts
> of it, should be easily done.
> 
> Re-using an existing environment is one option but I don't think it's
> a great one.  LXDE is very minimal but the Windows 95 aesthetic isn't
> exactly attractive, XFCE is surprisingly large these days.  We don't
> really want much, so I think maintaining our own shell is a worthwhile
> investment.
> 
> Hopefully there aren't any objections so far?  I'll assume not, and
> introduce my proposal for Project Shuku[3].
> 
> 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.
> 
> The interesting bit is then the test application.  We need a graphical
> environment so that we can run applications specific to our needs (and
> the desktop handles this fine already) and verify that the system is
> in fact working correctly.  Currently this is done in an ad-hoc
> manner: using the music player to play audio files, gst-launch to play
> videos, poking at the the touchscreen to verify that it works.  I'm
> proposing a specific test application so that instead of attempting to
> use general purpose applications as test tools, we have a specific
> tool.
> 
> For example, when playing back a video file it's important that any
> hardware acceleration available is actually used.  The test tool could
> play the file using GStreamer's playbin and then display the resulting
> pipeline so you can verify that VAAPI is being used, the correct audio
> sink, the correct network source, and so on.  To verify that the input
> devices are working, list them at the evdev level and let you see the
> raw events, display touches, and so on.
> 
> I've also been considering the brave new world of Wayland.  Whilst
> porting to GTK+ 3 all of the X11-specific code can be logically
> separated so that a small Weston plugin can be written that integrates
> the pieces together.  This will give a Wayland-native graphical
> environment that is visually identical to the X environment.
> 
> There's plenty of other things to discuss -- visual design and so on
> -- but that can wait for another day.
> 
> So those are my thoughts.  Any comments?

Why not use enlightenment? It works good with meta-efl layer and it
looks like there will be E17 release after all :)
http://e17releasemanager.wordpress.com/
so we won't need to use so much stuff from svn recipes.

Cheers,

> 
> Ross
> 
> [1] Five years ago!
> http://www.burtonini.com/wordpress/2007/08/01/poky-linux-3-0-blinky-released/
> [2] QVGA, for example, was explicitly not a target.  The Sharp Zaurus,
> a typical test device, had a VGA screen.
> [3] In the glorious tradition of naming projects by translating words
> to other languages, I ended up with 尗 (U+5C17) which means "younger of
> brothers", and Shuku is one of the pronunciations.
> 
> _______________________________________________
> 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-09 21:06 The Mythical Sato Replacement Burton, Ross
  2012-07-09 21:33 ` Martin Jansa
@ 2012-07-09 22:36 ` Khem Raj
  2012-07-10  8:46   ` Richard Purdie
  2012-07-10  8:56   ` Jack Mitchell
  1 sibling, 2 replies; 8+ messages in thread
From: Khem Raj @ 2012-07-09 22:36 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-09 22:36 ` Khem Raj
@ 2012-07-10  8:46   ` Richard Purdie
  2012-07-10  8:53     ` Martin Jansa
  2012-07-10  8:56   ` Jack Mitchell
  1 sibling, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2012-07-10  8:46 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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.

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-10  8:46   ` Richard Purdie
@ 2012-07-10  8:53     ` Martin Jansa
  0 siblings, 0 replies; 8+ messages in thread
From: Martin Jansa @ 2012-07-10  8:53 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-09 22:36 ` Khem Raj
  2012-07-10  8:46   ` Richard Purdie
@ 2012-07-10  8:56   ` Jack Mitchell
  2012-07-10 11:33     ` Burton, Ross
  1 sibling, 1 reply; 8+ messages in thread
From: Jack Mitchell @ 2012-07-10  8:56 UTC (permalink / raw)
  To: openembedded-core

On 09/07/12 23:36, 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.
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

I think Wayland support would be cool also. I think it would be a 
fantastic way to get people involved and encourage adoption.

A Raspberry Pi build for its specific architecture with Wayland and an 
automatically populated SDK and toolchain? People would be flocking...

Just my 2p!

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-10  8:56   ` Jack Mitchell
@ 2012-07-10 11:33     ` Burton, Ross
  2012-07-10 16:05       ` Elvis Dowson
  0 siblings, 1 reply; 8+ messages in thread
From: Burton, Ross @ 2012-07-10 11:33 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

On 10 July 2012 09:56, Jack Mitchell <ml@communistcode.co.uk> wrote:
>> Did you consider QT instead of GTK+ ? I think having wayland would be
>> cool.
>
> I think Wayland support would be cool also. I think it would be a fantastic
> way to get people involved and encourage adoption.

Regarding Wayland, I covered that later in the email.  I really want
to see Wayland in oe-core, and the Shuku plan includes a Wayland
route.  I had a good chat with krh last night, the hardest bit will be
updating GTK+ to work with the latest Wayland.

Regarding Qt/EFL/wxWidgets/whatever, as Richard explained the
underlying principle is the most return on investment.  There are
several factors:

- the toolkit must be known by the person doing the work
- the toolkit must have a regular release cycle
- the toolkit must have ABI/API stability so that upgrading the
toolkit doesn't imply updating the UI
- working on an existing UI is better than starting from scratch

I'm willing to step up and do the initial work, and my preferred
toolkit is GTK+.  The Sato shell is sufficient for our requirements,
so the Shuku proposal is a low-investment plan that should give us a
refreshed UI for a few more years.

Sato has been on life-support for several years now, so if someone had
a pressing urge to write a replacement in Qt or EFL they've had plenty
of time to do it... and nobody has.

Ross



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: The Mythical Sato Replacement
  2012-07-10 11:33     ` Burton, Ross
@ 2012-07-10 16:05       ` Elvis Dowson
  0 siblings, 0 replies; 8+ messages in thread
From: Elvis Dowson @ 2012-07-10 16:05 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

Hi,
       How about adding a meta-android layer, and creating a core-image-minimal-android build? 

The android kernels are available, they have a qemu target for android, and the android sdk will need a bbclass to download, build and create an android root filesystem. A couple of targets already are compatible, mostly the TI OMAP/AM series. 

Elvis Dowson


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2012-07-10 16:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-09 21:06 The Mythical Sato Replacement Burton, Ross
2012-07-09 21:33 ` Martin Jansa
2012-07-09 22:36 ` Khem Raj
2012-07-10  8:46   ` Richard Purdie
2012-07-10  8:53     ` Martin Jansa
2012-07-10  8:56   ` Jack Mitchell
2012-07-10 11:33     ` Burton, Ross
2012-07-10 16:05       ` Elvis Dowson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.