[OE-core] Qt in OE-core

[Martin Jansa]

On Wed, Jan 08, 2014 at 01:44:59PM -0500, Trevor Woerner wrote:
> 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:

The same for meta-x11 or meta-xorg, even when a lot of projects (maybe
the most) will just include meta-x* by default.

> - 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?

+1 for whole e-mail.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140108/4b6a7a0e/attachment-0002.sig>