On 01/08/14 10:56, Paul Eggleton wrote: > However, one concern I have always had with Qt being moved out of > OE-Core though is that I very much doubt the same will happen with > GTK+ and GNOME UI components that we carry, which I think will lead to > the (perhaps erroneous, but logical) assumption in new users' minds > that we support or recommend these more than we do Qt. Given Qt's > popularity in the embedded space I don't think this would be the right > message to be sending out. Any concrete ideas on how we would address > this perception issue?
Would it be worthwhile to ask that the OE TSC take on the task of defining what is "core" and what is not? Does this definition already exist? >From the moment OE chose to adopt a layered strategy, people started questioning how to define a layer and what recipes should be part of one layer versus another. But it doesn't seem as though there's been much interest in setting any definite rules or definitions in this regard. Maybe it would be worth the effort to at least try? In my opinion... Personally I would be in favour of removing GTK+ and the GNOME UI from the core and putting them in their own layer for all the same reasons I think Qt should be in its own layer: - a "basic" image doesn't need them - we can have different layers to track separate major releases (as with qt3, qt4, and qt5) There are so many ways to do GUI "things" on top of a Linux system. Frankly I'm not even in a position where I could enumerate all of them, or even sort them out: - x11, wayland, mir, (directfb) (http://en.wikipedia.org/wiki/Display_server) - qt, gtk+, wxwidgets, tcl/tk, fltk (http://en.wikipedia.org/wiki/List_of_widget_toolkits) - xlib, xcb (client libraries implementing x11 protocol) - weston, mutter, kwin, clayland (display servers implementing the wayland display server protocol) - opengl, opengles, egl, ... (I can't even begin to figure out how to draw a diagram that shows how all these projects fit together!) Maybe if there are significant competing projects which do the same thing, then they should be implemented in their own layer: - meta-python - meta-perl And if there are completing projects which do the same thing but which aren't significantly large projects on their own (e.g. http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers) then they should form a layer together of their own: - meta-apache-httpd - meta-http-servers - boa - cherokee - lighttpd - nginx Or maybe all projects which do the same thing different ways should be in their own layer? That way we don't have to distinguish between "significant" and "lightweight" projects" - meta-scripting-languages - python - perl - ruby - meta-http-servers - apache - boa - cherokee - lighttpd - nginx And maybe "core" should be just enough to get a console-based image working? _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
