Building your own UI

Building your own UI

[James Abernathy]

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

This may be a dumb question, but I'll ask anyway.

Suppose you have a project where you need a very custom user interface. Not
just a series of applications that appear on a desktop like you see in
sato, or Gnome, or KDE.  Basically your application becomes the UI.

I can see 2 approaches to this:

   1. Start with core-image-minimal and add the packages you need to
   support GFX, X11, and your application plus dependencies.
   2. Take core-image-sato and change the applications to be your subtasks
   , and the look-and-feel of the desktop.

What are the considerations of both approaches?
Is one better, or easier than the other?
How would you do this in Yocto?
Where do you look for information you need to accomplish this?

JIm A

[-- Attachment #2: Type: text/html, Size: 907 bytes --]

Re: Building your own UI

[autif khan]

> This may be a dumb question, but I'll ask anyway.
>
> Suppose you have a project where you need a very custom user interface. Not
> just a series of applications that appear on a desktop like you see in sato,
> or Gnome, or KDE.  Basically your application becomes the UI.
>
> I can see 2 approaches to this:
>
> Start with core-image-minimal and add the packages you need to support GFX,
> X11, and your application plus dependencies.
> Take core-image-sato and change the applications to be your subtasks , and
> the look-and-feel of the desktop.
>
> What are the considerations of both approaches?
> Is one better, or easier than the other?
> How would you do this in Yocto?
> Where do you look for information you need to accomplish this?

We are still in the very early stages of architecture design and development

For now we are leaning towards keeping everything that comes with
core-image-sato and writing a full screen app on top of it. Likely to
be written in .NET (mono). A prototype (proof of concept) has been
successfully developed :-)

As I said - still in very early stages of arch/design and dev. So
things may still change.

Re: Building your own UI

[Sean Liming]

>> This may be a dumb question, but I'll ask anyway.
>
>> Suppose you have a project where you need a very custom user 
>> interface. Not just a series of applications that appear on a desktop 
>> like you see in sato, or Gnome, or KDE.  Basically your application
becomes the UI.
>
>> I can see 2 approaches to this:
>
>> Start with core-image-minimal and add the packages you need to support 
>> GFX, X11, and your application plus dependencies.
>> Take core-image-sato and change the applications to be your subtasks , 
>> and the look-and-feel of the desktop.
>
>> What are the considerations of both approaches?
> >Is one better, or easier than the other?
> >How would you do this in Yocto?
>> Where do you look for information you need to accomplish this?

>We are still in the very early stages of architecture design and
development

>For now we are leaning towards keeping everything that comes with
core-image-sato and writing a full screen app on top of it. Likely to be
written in .NET (mono). A prototype (proof of concept) has been successfully
developed :-)

>As I said - still in very early stages of arch/design and dev. So things
may still change.


If it is okay to jump in an comment, I was going to ask the same question at
some point. 

The need to have the application as the main UI or shell to the system is
important for branding. Launching sato or other desktop would not be
desirable. As an example, Windows uses Explorer.exe as the shell, but can be
replaced with any application. Windows was architected this way. It would be
nice to have similar architecture here, but I know it is easier said than
done. As you said this is early in design.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Building your own UI

[autif khan]

>>> This may be a dumb question, but I'll ask anyway.
>>
>>> Suppose you have a project where you need a very custom user
>>> interface. Not just a series of applications that appear on a desktop
>>> like you see in sato, or Gnome, or KDE.  Basically your application
> becomes the UI.
>>
>>> I can see 2 approaches to this:
>>
>>> Start with core-image-minimal and add the packages you need to support
>>> GFX, X11, and your application plus dependencies.
>>> Take core-image-sato and change the applications to be your subtasks ,
>>> and the look-and-feel of the desktop.
>>
>>> What are the considerations of both approaches?
>> >Is one better, or easier than the other?
>> >How would you do this in Yocto?
>>> Where do you look for information you need to accomplish this?
>
>>We are still in the very early stages of architecture design and
> development
>
>>For now we are leaning towards keeping everything that comes with
> core-image-sato and writing a full screen app on top of it. Likely to be
> written in .NET (mono). A prototype (proof of concept) has been successfully
> developed :-)
>
>>As I said - still in very early stages of arch/design and dev. So things
> may still change.
>
>
> If it is okay to jump in an comment, I was going to ask the same question at
> some point.
>
> The need to have the application as the main UI or shell to the system is
> important for branding. Launching sato or other desktop would not be
> desirable. As an example, Windows uses Explorer.exe as the shell, but can be
> replaced with any application. Windows was architected this way. It would be
> nice to have similar architecture here, but I know it is easier said than
> done. As you said this is early in design.

We do have a lot of open questions that we will answer in good time:

1) Should the application be executed as root or as some user or as nobody

2) Should we trim the image? (we are not short on space or ram)

3) Aforementioned - should the app run from inittab or rcS.d or something else

We will figure out these things when we are on that bridge.

I do have a question - you have provided the example of Windows -
where explorer is the shell and can be changed. However, there is no
argument here - what are the clear (no brainer) or subjective
arguments for one versus the other.

Re: Building your own UI

[Sean Liming]

>>> This may be a dumb question, but I'll ask anyway.
>>
>>> Suppose you have a project where you need a very custom user 
>>> interface. Not just a series of applications that appear on a 
>>> desktop like you see in sato, or Gnome, or KDE.  Basically your 
>>> application
> becomes the UI.
>>
>>> I can see 2 approaches to this:
>>
>>> Start with core-image-minimal and add the packages you need to 
>>> support GFX, X11, and your application plus dependencies.
>>> Take core-image-sato and change the applications to be your subtasks 
>>> , and the look-and-feel of the desktop.
>>
>>> What are the considerations of both approaches?
>> >Is one better, or easier than the other?
>> >How would you do this in Yocto?
>>> Where do you look for information you need to accomplish this?
>
>>We are still in the very early stages of architecture design and
>> development
>
>>For now we are leaning towards keeping everything that comes with
> >core-image-sato and writing a full screen app on top of it. Likely to 
> >be written in .NET (mono). A prototype (proof of concept) has been 
> >successfully developed :-)
>
>>As I said - still in very early stages of arch/design and dev. So 
>>things
> >may still change.
>
>
> >If it is okay to jump in an comment, I was going to ask the same 
> >question at some point.
>
> >The need to have the application as the main UI or shell to the system 
> >is important for branding. Launching sato or other desktop would not 
>> be desirable. As an example, Windows uses Explorer.exe as the shell, 
>> but can be replaced with any application. Windows was architected this 
>> way. It would be nice to have similar architecture here, but I know it 
> >is easier said than done. As you said this is early in design.

>We do have a lot of open questions that we will answer in good time:

>1) Should the application be executed as root or as some user or as nobody

>2) Should we trim the image? (we are not short on space or ram)

>3) Aforementioned - should the app run from inittab or rcS.d or something
else

>We will figure out these things when we are on that bridge.

>I do have a question - you have provided the example of Windows - where
explorer is the shell and can be changed. However, there is no argument here
- what are >the clear (no brainer) or subjective arguments for one versus
the other.

There are two reasons or user models: security and branding.

Using the Windows example. A system boots to Explorer desktop and then
launches an application. If someone can close the application and get to the
desktop, it is a security vulnerability someone could get into all sorts of
data and control panel settings.  By switching the application as the shell
(replacing explorer.exe) where the OEM has created a unique UI for the
device, it locks the system down. The custom shell can also provide controls
or back door access for administrative functions like display and network
settings. For Windows the devices boots to the Administrator account so the
application is not impeded from the system.

A custom UI helps with branding by creating a unique UI, the device has a
unique look and feel that tells the user this is a device and they have no
idea what is underneath. Launching Explorer and then the application doesn't
create the unique device look and feel.

Another method that OEMs do with Windows is to have a base shell launches
the main application. Again, the base shell replaces the  Explorer.exe with
something that is unique for the devices. If the main application needs to
be replaced, the main application can be shut down and the base shell still
provides some UI to perform the upgrade.

I am new to Linux embedded so I don't know how this would be architected.

Re: Building your own UI

[Joshua Lock]

On 07/02/12 07:57, James Abernathy wrote:
> This may be a dumb question, but I'll ask anyway.
> Suppose you have a project where you need a very custom user interface.
> Not just a series of applications that appear on a desktop like you see
> in sato, or Gnome, or KDE.  Basically your application becomes the UI.
> I can see 2 approaches to this:
>
>  1. Start with core-image-minimal and add the packages you need to
>     support GFX, X11, and your application plus dependencies.
>  2. Take core-image-sato and change the applications to be your subtasks
>     , and the look-and-feel of the desktop.
>
> What are the considerations of both approaches?

A key selling point of the Yocto approach is to provide a highly 
customised OS for your target application, rather than taking an 
existing solution and stripping it back.

2. is the antithesis of the Yocto approach if you don't want/need the 
Sato UI.

The intention is that the core metadata should provide sufficient 
granularity through the defined images and tasks to get people started.

I'd recommend something like 1. only taking core-image-core (horrible 
name I know) if you want an X based OS.

We no doubt need more documentation in this area, and Hob is designed to 
help here.


> Is one better, or easier than the other?

Creating your own image is better in that you only build and ship what 
you need. Arguably building atop a custom image is easier, but you lose 
control.

> How would you do this in Yocto?

You might consider creating a custom image by starting with 
core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries 
to provide the core functionality you desire.

$ less foo.bb
# a noddy example image, base of a NAS OS

# start with core-image-minimal
require recipes-core/images/core-image-minimal.bb

IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
IMAGE_INSTALL += "my-custom-nas-app"

> Where do you look for information you need to accomplish this?

Mostly by following examples in the existing metadata at the moment, see 
the comment above about hob and documentation.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Building your own UI

[jfabernathy]

On 02/07/2012 01:54 PM, Joshua Lock wrote:
> On 07/02/12 07:57, James Abernathy wrote:
>> This may be a dumb question, but I'll ask anyway.
>> Suppose you have a project where you need a very custom user interface.
>> Not just a series of applications that appear on a desktop like you see
>> in sato, or Gnome, or KDE.  Basically your application becomes the UI.
>> I can see 2 approaches to this:
>>
>>  1. Start with core-image-minimal and add the packages you need to
>>     support GFX, X11, and your application plus dependencies.
>>  2. Take core-image-sato and change the applications to be your subtasks
>>     , and the look-and-feel of the desktop.
>>
>> What are the considerations of both approaches?
>
> A key selling point of the Yocto approach is to provide a highly 
> customised OS for your target application, rather than taking an 
> existing solution and stripping it back.
>
> 2. is the antithesis of the Yocto approach if you don't want/need the 
> Sato UI.
>
> The intention is that the core metadata should provide sufficient 
> granularity through the defined images and tasks to get people started.
>
> I'd recommend something like 1. only taking core-image-core (horrible 
> name I know) if you want an X based OS.
>
I built core-image-core and it works and is basic. So it's not a really 
small Sato???

> We no doubt need more documentation in this area, and Hob is designed 
> to help here.
>
>
>> Is one better, or easier than the other?
>
> Creating your own image is better in that you only build and ship what 
> you need. Arguably building atop a custom image is easier, but you 
> lose control.
>
>> How would you do this in Yocto?
>
> You might consider creating a custom image by starting with 
> core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries 
> to provide the core functionality you desire.
>
> $ less foo.bb
> # a noddy example image, base of a NAS OS
>
> # start with core-image-minimal
> require recipes-core/images/core-image-minimal.bb
>
> IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
> IMAGE_INSTALL += "my-custom-nas-app"
>
I have difficulty understanding the difference in IMAGE_FEATURES and 
IMAGE_INSTALL.  To me IMAGE_INSTALL is clear I've used that in a 
core-image-sato.bbappend file in an image directory in my own recipes-xx 
directory.  I see how IMAGE_FEATURES is uses in the core-image-core:

IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"

But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where 
it's defined.  The apps-console-core is define in the Poky Refernce manual:

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image

However, I'm not sure were to find it's definition in the many recipes.

Jim A

>> Where do you look for information you need to accomplish this?
>
> Mostly by following examples in the existing metadata at the moment, 
> see the comment above about hob and documentation.
>
> Cheers,
> Joshua

Re: Building your own UI

[Joshua Lock]

On 07/02/12 13:54, jfabernathy wrote:
> On 02/07/2012 01:54 PM, Joshua Lock wrote:
>> On 07/02/12 07:57, James Abernathy wrote:
>>> This may be a dumb question, but I'll ask anyway.
>>> Suppose you have a project where you need a very custom user interface.
>>> Not just a series of applications that appear on a desktop like you see
>>> in sato, or Gnome, or KDE. Basically your application becomes the UI.
>>> I can see 2 approaches to this:
>>>
>>> 1. Start with core-image-minimal and add the packages you need to
>>> support GFX, X11, and your application plus dependencies.
>>> 2. Take core-image-sato and change the applications to be your subtasks
>>> , and the look-and-feel of the desktop.
>>>
>>> What are the considerations of both approaches?
>>
>> A key selling point of the Yocto approach is to provide a highly
>> customised OS for your target application, rather than taking an
>> existing solution and stripping it back.
>>
>> 2. is the antithesis of the Yocto approach if you don't want/need the
>> Sato UI.
>>
>> The intention is that the core metadata should provide sufficient
>> granularity through the defined images and tasks to get people started.
>>
>> I'd recommend something like 1. only taking core-image-core (horrible
>> name I know) if you want an X based OS.
>>
> I built core-image-core and it works and is basic. So it's not a really
> small Sato???
>
>> We no doubt need more documentation in this area, and Hob is designed
>> to help here.
>>
>>
>>> Is one better, or easier than the other?
>>
>> Creating your own image is better in that you only build and ship what
>> you need. Arguably building atop a custom image is easier, but you
>> lose control.
>>
>>> How would you do this in Yocto?
>>
>> You might consider creating a custom image by starting with
>> core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries
>> to provide the core functionality you desire.
>>
>> $ less foo.bb
>> # a noddy example image, base of a NAS OS
>>
>> # start with core-image-minimal
>> require recipes-core/images/core-image-minimal.bb
>>
>> IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
>> IMAGE_INSTALL += "my-custom-nas-app"
>>
> I have difficulty understanding the difference in IMAGE_FEATURES and
> IMAGE_INSTALL. To me IMAGE_INSTALL is clear I've used that in a
> core-image-sato.bbappend file in an image directory in my own recipes-xx
> directory. I see how IMAGE_FEATURES is uses in the core-image-core:
>
> IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"
>
> But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where
> it's defined. The apps-console-core is define in the Poky Refernce manual:
>
> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image
>
>
> However, I'm not sure were to find it's definition in the many recipes.

The features are defined in core-image.bbclass:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass

Most of them translate into one or more task recipes 
(meta/recipes-*/tasks/) except package-management which translates to 
ROOTFS_PKGMANAGE which in turn is defined in each of the package 
management rootfs construction classes (meta/classes/rootfs_*.bbclass).


Aside: I usually rely in git grep to track down where a variable is defined.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Building your own UI

[jfabernathy]

On 02/07/2012 07:47 PM, Joshua Lock wrote:
>
>
> On 07/02/12 13:54, jfabernathy wrote:
>> On 02/07/2012 01:54 PM, Joshua Lock wrote:
>>> On 07/02/12 07:57, James Abernathy wrote:
>>>> This may be a dumb question, but I'll ask anyway.
>>>> Suppose you have a project where you need a very custom user 
>>>> interface.
>>>> Not just a series of applications that appear on a desktop like you 
>>>> see
>>>> in sato, or Gnome, or KDE. Basically your application becomes the UI.
>>>> I can see 2 approaches to this:
>>>>
>>>> 1. Start with core-image-minimal and add the packages you need to
>>>> support GFX, X11, and your application plus dependencies.
>>>> 2. Take core-image-sato and change the applications to be your 
>>>> subtasks
>>>> , and the look-and-feel of the desktop.
>>>>
>>>> What are the considerations of both approaches?
>>>
>>> A key selling point of the Yocto approach is to provide a highly
>>> customised OS for your target application, rather than taking an
>>> existing solution and stripping it back.
>>>
>>> 2. is the antithesis of the Yocto approach if you don't want/need the
>>> Sato UI.
>>>
>>> The intention is that the core metadata should provide sufficient
>>> granularity through the defined images and tasks to get people started.
>>>
>>> I'd recommend something like 1. only taking core-image-core (horrible
>>> name I know) if you want an X based OS.
>>>
>> I built core-image-core and it works and is basic. So it's not a really
>> small Sato???
>>
>>> We no doubt need more documentation in this area, and Hob is designed
>>> to help here.
>>>
>>>
>>>> Is one better, or easier than the other?
>>>
>>> Creating your own image is better in that you only build and ship what
>>> you need. Arguably building atop a custom image is easier, but you
>>> lose control.
>>>
>>>> How would you do this in Yocto?
>>>
>>> You might consider creating a custom image by starting with
>>> core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries
>>> to provide the core functionality you desire.
>>>
>>> $ less foo.bb
>>> # a noddy example image, base of a NAS OS
>>>
>>> # start with core-image-minimal
>>> require recipes-core/images/core-image-minimal.bb
>>>
>>> IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
>>> IMAGE_INSTALL += "my-custom-nas-app"
>>>
>> I have difficulty understanding the difference in IMAGE_FEATURES and
>> IMAGE_INSTALL. To me IMAGE_INSTALL is clear I've used that in a
>> core-image-sato.bbappend file in an image directory in my own recipes-xx
>> directory. I see how IMAGE_FEATURES is uses in the core-image-core:
>>
>> IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"
>>
>> But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where
>> it's defined. The apps-console-core is define in the Poky Refernce 
>> manual:
>>
>> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image 
>>
>>
>>
>> However, I'm not sure were to find it's definition in the many recipes.
>
> The features are defined in core-image.bbclass:
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass 
>
>
> Most of them translate into one or more task recipes 
> (meta/recipes-*/tasks/) except package-management which translates to 
> ROOTFS_PKGMANAGE which in turn is defined in each of the package 
> management rootfs construction classes (meta/classes/rootfs_*.bbclass).

Thanks, Joshua,

I have build a number of the images with minimal x11 features to see the 
difference. All of them appear to be the basic Sato without the apps or 
borders. And all start with the bit Yocto Project Splash screen.  I 
remember back a few years and it may go back to more than that, you 
could launch just X without a window manager or at least a basic one and 
all you had was one xterm session. You could right click and create 
another xterm, but anything else had to be launched from the command 
line in the xterm.  like glxgears, mplayer, etc.  It was a good way of 
testing without committing to a look and feel.  Does that level exist in 
Yocto.  I'm not seeing how I use what I'm seeing even with the x11-basic 
to create a custom platform look.

BTW, I built core-image-clutter and it looks just like core-image-sato.  
Not sure the difference.
Also build the qt4e-demo-image.  That is pretty cool demo.  Probably 
takes a lot to figure out how to following that look and feel.

JIm A


> Aside: I usually rely in git grep to track down where a variable is 
> defined.
>
> Cheers,
> Joshua

Re: Building your own UI

[Joshua Lock]

On 08/02/12 12:52, jfabernathy wrote:
> On 02/07/2012 07:47 PM, Joshua Lock wrote:
>> On 07/02/12 13:54, jfabernathy wrote:
>>> On 02/07/2012 01:54 PM, Joshua Lock wrote:
>>>> On 07/02/12 07:57, James Abernathy wrote:
>>>>> This may be a dumb question, but I'll ask anyway.
>>>>> Suppose you have a project where you need a very custom user
>>>>> interface.
>>>>> Not just a series of applications that appear on a desktop like you
>>>>> see
>>>>> in sato, or Gnome, or KDE. Basically your application becomes the UI.
>>>>> I can see 2 approaches to this:
>>>>>
>>>>> 1. Start with core-image-minimal and add the packages you need to
>>>>> support GFX, X11, and your application plus dependencies.
>>>>> 2. Take core-image-sato and change the applications to be your
>>>>> subtasks
>>>>> , and the look-and-feel of the desktop.
>>>>>
>>>>> What are the considerations of both approaches?
>>>>
>>>> A key selling point of the Yocto approach is to provide a highly
>>>> customised OS for your target application, rather than taking an
>>>> existing solution and stripping it back.
>>>>
>>>> 2. is the antithesis of the Yocto approach if you don't want/need the
>>>> Sato UI.
>>>>
>>>> The intention is that the core metadata should provide sufficient
>>>> granularity through the defined images and tasks to get people started.
>>>>
>>>> I'd recommend something like 1. only taking core-image-core (horrible
>>>> name I know) if you want an X based OS.
>>>>
>>> I built core-image-core and it works and is basic. So it's not a really
>>> small Sato???
>>>
>>>> We no doubt need more documentation in this area, and Hob is designed
>>>> to help here.
>>>>
>>>>
>>>>> Is one better, or easier than the other?
>>>>
>>>> Creating your own image is better in that you only build and ship what
>>>> you need. Arguably building atop a custom image is easier, but you
>>>> lose control.
>>>>
>>>>> How would you do this in Yocto?
>>>>
>>>> You might consider creating a custom image by starting with
>>>> core-image-minimal and adding IMAGE_FEATURES and IMAGE_INSTALL entries
>>>> to provide the core functionality you desire.
>>>>
>>>> $ less foo.bb
>>>> # a noddy example image, base of a NAS OS
>>>>
>>>> # start with core-image-minimal
>>>> require recipes-core/images/core-image-minimal.bb
>>>>
>>>> IMAGE_FEATURES += "package-management nfs-server ssh-server-dropbear"
>>>> IMAGE_INSTALL += "my-custom-nas-app"
>>>>
>>> I have difficulty understanding the difference in IMAGE_FEATURES and
>>> IMAGE_INSTALL. To me IMAGE_INSTALL is clear I've used that in a
>>> core-image-sato.bbappend file in an image directory in my own recipes-xx
>>> directory. I see how IMAGE_FEATURES is uses in the core-image-core:
>>>
>>> IMAGE_FEATURES += "apps-console-core ${X11_IMAGE_FEATURES}"
>>>
>>> But I have no idea what ${X11_IMAGE_FEATURES} is or how to find where
>>> it's defined. The apps-console-core is define in the Poky Refernce
>>> manual:
>>>
>>> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-image
>>>
>>>
>>>
>>> However, I'm not sure were to find it's definition in the many recipes.
>>
>> The features are defined in core-image.bbclass:
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/core-image.bbclass
>>
>>
>> Most of them translate into one or more task recipes
>> (meta/recipes-*/tasks/) except package-management which translates to
>> ROOTFS_PKGMANAGE which in turn is defined in each of the package
>> management rootfs construction classes (meta/classes/rootfs_*.bbclass).
>
> Thanks, Joshua,
>
> I have build a number of the images with minimal x11 features to see the
> difference. All of them appear to be the basic Sato without the apps or
> borders. And all start with the bit Yocto Project Splash screen. I
> remember back a few years and it may go back to more than that, you
> could launch just X without a window manager or at least a basic one and
> all you had was one xterm session. You could right click and create
> another xterm, but anything else had to be launched from the command
> line in the xterm. like glxgears, mplayer, etc. It was a good way of
> testing without committing to a look and feel. Does that level exist in
> Yocto. I'm not seeing how I use what I'm seeing even with the x11-basic
> to create a custom platform look.

It's perfectly possible, it just may be that you have to create your own 
bare bones image.

The problem with trying to provide generic tasks and images is that 
everyones opinion of what constitutes minimal/bare bones is different. :-)

This thread has made it clear that we need to expedite the formation of 
some documentation guiding folks through building custom images.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre