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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
