[OE-core] Qt in OE-core

[Trevor Woerner]

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?