GUI based images

GUI based images

[Belal, Awais]

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

Hi,


Can anyone please shed some light on why OE only provides SATO based images (core-image-sato) when it comes to GUI based images? There are other solutions like LXDE, have these been evaluated? Is there a specific reason to go with SATO?


BR,
Awais

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

Re: GUI based images

[Jussi Kukkonen]

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

On 8 May 2017 at 13:51, Belal, Awais <Awais_Belal@mentor.com> wrote:
>
> Hi,
>
> Can anyone please shed some light on why OE only provides SATO based
images (core-image-sato) when it comes to GUI based images? There are other
solutions like LXDE, have these been evaluated? Is there a specific reason
to go with SATO?

Sato is extremely lightweight (not just runtime-wise but with regards to
build time and maintenance effort). I admit I'm not familiar with LXDE but
other DEs known as lightweight are in reality on another level compared to
Sato... Sato projects themselves are tiny and depend on very little: this
is quite beneficial since it keeps the automated test runtimes reasonable.

The other big reason is that it's there and mostly works (not as a modern
DE for daily use but as a test platform for Xorg, mesa, GTK+, GStreamer,
etc). If someone was committed to bringing in a more modern alternative
that wouldn't ruin our build times or bring in vast amounts of new recipes,
I'm sure it would be considered. Note that at this point at least I would
hope "modern" would mean "handles wayland case in some manner"...

My 2c,
  Jussi

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

Re: GUI based images

[Alexander Kanavin]

On 05/08/2017 02:33 PM, Jussi Kukkonen wrote:

> Sato is extremely lightweight (not just runtime-wise but with regards to
> build time and maintenance effort). I admit I'm not familiar with LXDE
> but other DEs known as lightweight are in reality on another level
> compared to Sato... Sato projects themselves are tiny and depend on very
> little: this is quite beneficial since it keeps the automated test
> runtimes reasonable.

LXDE in particular is Gtk2 based, it's no longer being developed, and 
has been superseded by LXQt. So it's a non-starter (and so is LXQt, 
which should be clear from its name :).

Generally, we have resources for maintaining only one GUI desktop in 
oe-core layer, and right now that is Sato. If you're okay with XFCE, 
that is provided via meta-xfce layer:

http://cgit.openembedded.org/meta-openembedded/tree/meta-xfce/recipes-core/images/core-image-minimal-xfce.bb?h=master

Alex

Re: GUI based images

[Paul Eggleton]

On Monday, 8 May 2017 11:39:53 PM NZST Alexander Kanavin wrote:
> On 05/08/2017 02:33 PM, Jussi Kukkonen wrote:
> > Sato is extremely lightweight (not just runtime-wise but with regards to
> > build time and maintenance effort). I admit I'm not familiar with LXDE
> > but other DEs known as lightweight are in reality on another level
> > compared to Sato... Sato projects themselves are tiny and depend on very
> > little: this is quite beneficial since it keeps the automated test
> > runtimes reasonable.
> 
> LXDE in particular is Gtk2 based, it's no longer being developed, and 
> has been superseded by LXQt. So it's a non-starter (and so is LXQt, 
> which should be clear from its name :).

FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 01:15 AM, Paul Eggleton wrote:
>> LXDE in particular is Gtk2 based, it's no longer being developed, and
>> has been superseded by LXQt. So it's a non-starter (and so is LXQt,
>> which should be clear from its name :).
>
> FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?

We would first have to agree that Qt5 belongs in oe-core with 
appropriate level of maintenance and QA, and that it's okay to add half 
an hour or more to the building time of a standard GUI image.

 From the screenshots of LxQT, it looks like yet another Win95 clone 
meant strictly for desktop use that would certainly scale poorly to 
small resolution screens. Who would be the target audience for it in the 
embedded space? For the purposes of 'engineering UI', Sato is fine, and 
we don't need something else.

Alex

Re: GUI based images

[Alex J Lennon]

On 09/05/17 09:05, Alexander Kanavin wrote:
> On 05/09/2017 01:15 AM, Paul Eggleton wrote:
>>> LXDE in particular is Gtk2 based, it's no longer being developed, and
>>> has been superseded by LXQt. So it's a non-starter (and so is LXQt,
>>> which should be clear from its name :).
>>
>> FWIW I think this is a little short-sighted. Why are we ruling out Qt 
>> exactly?
>
> We would first have to agree that Qt5 belongs in oe-core with 
> appropriate level of maintenance and QA, and that it's okay to add 
> half an hour or more to the building time of a standard GUI image.
>
> From the screenshots of LxQT, it looks like yet another Win95 clone 
> meant strictly for desktop use that would certainly scale poorly to 
> small resolution screens. Who would be the target audience for it in 
> the embedded space? For the purposes of 'engineering UI', Sato is 
> fine, and we don't need something else.
>
> Alex

fwiw. I would love to be able to develop devices like those pictured 
below, which I believe are based on Qt for Device Creation.

https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png

ref: https://www.qt.io/qt-for-device-creation/

Cheers,

Alex

Re: GUI based images

[Ian Arkver]

On 09/05/17 09:44, Alex J Lennon wrote:
> 
> 
> On 09/05/17 09:05, Alexander Kanavin wrote:
>> On 05/09/2017 01:15 AM, Paul Eggleton wrote:
>>>> LXDE in particular is Gtk2 based, it's no longer being developed, and
>>>> has been superseded by LXQt. So it's a non-starter (and so is LXQt,
>>>> which should be clear from its name :).
>>>
>>> FWIW I think this is a little short-sighted. Why are we ruling out Qt 
>>> exactly?
>>
>> We would first have to agree that Qt5 belongs in oe-core with 
>> appropriate level of maintenance and QA, and that it's okay to add 
>> half an hour or more to the building time of a standard GUI image.
>>
>> From the screenshots of LxQT, it looks like yet another Win95 clone 
>> meant strictly for desktop use that would certainly scale poorly to 
>> small resolution screens. Who would be the target audience for it in 
>> the embedded space? For the purposes of 'engineering UI', Sato is 
>> fine, and we don't need something else.
>>
>> Alex
> 
> fwiw. I would love to be able to develop devices like those pictured 
> below, which I believe are based on Qt for Device Creation.
> 
> https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png 
> 
> 
> ref: https://www.qt.io/qt-for-device-creation/
> 
> Cheers,
> 
> Alex
> 

They have their own meta-b2qt layer for that. See "Embedded 
documentation" and "Building Your Own Embedded Linux Image" from that
page.

It's not an OE-core thing, imho.

Regards,
Ian

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 12:18 PM, Ian Arkver wrote:
> They have their own meta-b2qt layer for that. See "Embedded
> documentation" and "Building Your Own Embedded Linux Image" from that
> page.
>
> It's not an OE-core thing, imho.

I digged a bit deeper, and meta-b2qt is in fact open source:

http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/README

"Boot to Qt (b2qt) is the reference distro used in Qt for Device 
Creation [1]. It combines Poky, meta-qt5 and various BSP meta layers to 
provide an integrated solution for building device images and toolchains 
with the latest Qt version."

Seriously, for those who say that qt5 should be in oe.core - this does 
the job far better than oe-core ever would.

Alex

Re: GUI based images

[Burton, Ross]

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

On 9 May 2017 at 10:30, Alexander Kanavin <alexander.kanavin@linux.intel.com
> wrote:

> Seriously, for those who say that qt5 should be in oe.core - this does the
> job far better than oe-core ever would.
>

This. :)

Ross

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

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 11:44 AM, Alex J Lennon wrote:
> fwiw. I would love to be able to develop devices like those pictured
> below, which I believe are based on Qt for Device Creation.
>
> https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png
>
>
> ref: https://www.qt.io/qt-for-device-creation/

Sadly, Qt for Device Creation is a commercial product. They even provide 
Yocto recipes :)

Alex

Re: GUI based images

[Mike Looijmans]

On 09-05-17 10:44, Alex J Lennon wrote:
>
>
> On 09/05/17 09:05, Alexander Kanavin wrote:
>> On 05/09/2017 01:15 AM, Paul Eggleton wrote:
>>>> LXDE in particular is Gtk2 based, it's no longer being developed, and
>>>> has been superseded by LXQt. So it's a non-starter (and so is LXQt,
>>>> which should be clear from its name :).
>>>
>>> FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?
>>
>> We would first have to agree that Qt5 belongs in oe-core with appropriate
>> level of maintenance and QA, and that it's okay to add half an hour or more
>> to the building time of a standard GUI image.
>>
>> From the screenshots of LxQT, it looks like yet another Win95 clone meant
>> strictly for desktop use that would certainly scale poorly to small
>> resolution screens. Who would be the target audience for it in the embedded
>> space? For the purposes of 'engineering UI', Sato is fine, and we don't need
>> something else.
>>
>> Alex
>
> fwiw. I would love to be able to develop devices like those pictured below,
> which I believe are based on Qt for Device Creation.
>
> https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png

Things like that can be cooked up in OE using just meta-qt4 (or 5, but haven't 
tried yet) and a main application recipe (just a QT project that you develop 
on your desktop) that inherits qt4e.

Qt doesn't need X11, saving big on build and boot time.

A Zynq demo running QT on a plain framebuffer boots in about 7 seconds (from 
NOR flash) into the fully functional GUI, on a 10" touch panel, and all of it 
fits in about 20MB flash storage.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: GUI based images

[Burton, Ross]

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

On 8 May 2017 at 23:15, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> FWIW I think this is a little short-sighted. Why are we ruling out Qt
> exactly?
>

My only strong opinion on what goes into oe-core is that it should be small
(both in size and build time) and basic.  It's not going to fit everyones
needs and is basically there to be a UI until the users replace it with
something more suitable.  Sato does this without being too huge and there's
not currently a strong impetus to replace it.

The development of Wayland does make the long-term prospect of Sato
interesting: do we port Sato to Wayland too, or keep the Wayland images
using the standard Weston demo shell?

Ross

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

Re: GUI based images

[Khem Raj]

On Tue, May 9, 2017 at 2:24 AM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 8 May 2017 at 23:15, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>>
>> FWIW I think this is a little short-sighted. Why are we ruling out Qt
>> exactly?
>
>
> My only strong opinion on what goes into oe-core is that it should be small
> (both in size and build time) and basic.  It's not going to fit everyones
> needs and is basically there to be a UI until the users replace it with
> something more suitable.  Sato does this without being too huge and there's
> not currently a strong impetus to replace it.
>
> The development of Wayland does make the long-term prospect of Sato
> interesting: do we port Sato to Wayland too, or keep the Wayland images
> using the standard Weston demo shell?

I think we should always intend to align the reference stack with
whats commonly used in
userbases we target to address with project, we will not be serving
the project goals and its username if we
trim down to packages which are just used for reference, if majority of the
community we intend to address uses QT or any other stack for that matter
then we should align our requirements accordingly which will be mutually
beneficial IMO

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 11:19 PM, Khem Raj wrote:
> I think we should always intend to align the reference stack with
> whats commonly used in
> userbases we target to address with project, we will not be serving
> the project goals and its username if we
> trim down to packages which are just used for reference, if majority of the
> community we intend to address uses QT or any other stack for that matter
> then we should align our requirements accordingly which will be mutually
> beneficial IMO

I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
or any kind of 'reference stack', and decisions on what goes into it 
should not be based on how popular it is. If you do this, you risk 
overextending the layer, and ending up not doing a particularly good job 
on any of the things it tries to do. It's best to allow other layers to 
flourish, let the domain specialists do their job and decide for 
themselves how they want to do things, and have a curated list of layers 
that are known to be high quality and approved by Yocto Project.

If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
actually develop the Qt stack itself. End of story.

Alex

Re: GUI based images

[Khem Raj]

On Tue, May 9, 2017 at 1:39 PM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 05/09/2017 11:19 PM, Khem Raj wrote:
>>
>> I think we should always intend to align the reference stack with
>> whats commonly used in
>> userbases we target to address with project, we will not be serving
>> the project goals and its username if we
>> trim down to packages which are just used for reference, if majority of
>> the
>> community we intend to address uses QT or any other stack for that matter
>> then we should align our requirements accordingly which will be mutually
>> beneficial IMO
>
>
> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection or
> any kind of 'reference stack', and decisions on what goes into it should not
> be based on how popular it is. If you do this, you risk overextending the
> layer, and ending up not doing a particularly good job on any of the things
> it tries to do. It's best to allow other layers to flourish, let the domain
> specialists do their job and decide for themselves how they want to do
> things, and have a curated list of layers that are known to be high quality
> and approved by Yocto Project.
>
> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who
> actually develop the Qt stack itself. End of story.

Don't get bogged down with QT5, its not at all about QT5 or no qt5,see
it from a users point of view and you will probably understand what I
am trying to say. Relevance of what you include in core is very
essential. Look at
any infra typical example is android, they ensure what consists of the core
pieces and keep them aligned and add/remove major pieces with newer
releases. We need to always evaluate coverage of core and make amends
if we dont then integration efforts become more over releases and at
some point a distro can decide its not worth using OE-Core and fork.
So evaluating
the sub-systems should always be done and we should not be afraid of
shuffling the cards if that aligns well with what the users are needing at
a certain point in time.

Re: GUI based images

[Paul Eggleton]

On Wednesday, 10 May 2017 8:39:58 AM NZST Alexander Kanavin wrote:
> On 05/09/2017 11:19 PM, Khem Raj wrote:
> > I think we should always intend to align the reference stack with
> > whats commonly used in
> > userbases we target to address with project, we will not be serving
> > the project goals and its username if we
> > trim down to packages which are just used for reference, if majority of
> > the community we intend to address uses QT or any other stack for that
> > matter then we should align our requirements accordingly which will be
> > mutually beneficial IMO
> 
> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
> or any kind of 'reference stack', and decisions on what goes into it 
> should not be based on how popular it is. 

A number of things have been added to OE-Core because they are widely used, so 
I don't think that's true. However, that doesn't mean that would be used as a 
justification to add Qt5. I'm not even convinced we would need to add Qt5 to 
OE-Core in order to use it as part of a reference UI - the key requirement 
would be for us to commit to being part of its testing and maintenance, 
everything else is just logistics.

> If you do this, you risk overextending the layer, and ending up not doing a
> particularly good job on any of the things it tries to do. It's best to
> allow other layers to  flourish, let the domain specialists do their job and
> decide for themselves how they want to do things, and have a curated list of
> layers that are known to be high quality and approved by Yocto Project.
> 
> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
> actually develop the Qt stack itself. End of story.

Your opinion is noted. My opinion is that we ought to be providing a good 
reference that can be used as a basis for real products (regardless of whether 
whatever direction we choose to go is Qt-based or not) - the rest of our stack 
*is* used that way, after all. We regularly get comments about how Sato isn't 
suitable as such a basis, so the expectation is there. I don't think adding 
Wayland support alone will answer that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: GUI based images

[Philip Balister]

On 05/09/2017 03:03 PM, Paul Eggleton wrote:
> On Wednesday, 10 May 2017 8:39:58 AM NZST Alexander Kanavin wrote:
>> On 05/09/2017 11:19 PM, Khem Raj wrote:
>>> I think we should always intend to align the reference stack with
>>> whats commonly used in
>>> userbases we target to address with project, we will not be serving
>>> the project goals and its username if we
>>> trim down to packages which are just used for reference, if majority of
>>> the community we intend to address uses QT or any other stack for that
>>> matter then we should align our requirements accordingly which will be
>>> mutually beneficial IMO
>>
>> I strongly disagree. Oe-core is not a Greatest Embedded Hits collection 
>> or any kind of 'reference stack', and decisions on what goes into it 
>> should not be based on how popular it is. 
> 
> A number of things have been added to OE-Core because they are widely used, so 
> I don't think that's true. However, that doesn't mean that would be used as a 
> justification to add Qt5. I'm not even convinced we would need to add Qt5 to 
> OE-Core in order to use it as part of a reference UI - the key requirement 
> would be for us to commit to being part of its testing and maintenance, 
> everything else is just logistics.
> 
>> If you do this, you risk overextending the layer, and ending up not doing a
>> particularly good job on any of the things it tries to do. It's best to
>> allow other layers to  flourish, let the domain specialists do their job and
>> decide for themselves how they want to do things, and have a curated list of
>> layers that are known to be high quality and approved by Yocto Project.
>>
>> If you want qt5, use meta-qt5 and meta-b2qt, both made by people who 
>> actually develop the Qt stack itself. End of story.
> 
> Your opinion is noted. My opinion is that we ought to be providing a good 
> reference that can be used as a basis for real products (regardless of whether 
> whatever direction we choose to go is Qt-based or not) - the rest of our stack 
> *is* used that way, after all. We regularly get comments about how Sato isn't 
> suitable as such a basis, so the expectation is there. I don't think adding 
> Wayland support alone will answer that.

Does anyone currently ship a real product based on sato?

Yes, I am aware that sato works for testing gui stuff, just trying to
understand if it is used beyond that.

Philip

> 
> Cheers,
> Paul
> 

Re: GUI based images

[Alexander Kanavin]

On 05/10/2017 12:03 AM, Paul Eggleton wrote:
> Your opinion is noted. My opinion is that we ought to be providing a good
> reference that can be used as a basis for real products (regardless of whether
> whatever direction we choose to go is Qt-based or not) - the rest of our stack
> *is* used that way, after all. We regularly get comments about how Sato isn't
> suitable as such a basis, so the expectation is there. I don't think adding
> Wayland support alone will answer that.

Paul, I do believe specifics matter, and I'm not seeing much of that in 
this discussion :-(

No one has yet provided any idea what this reference UI would try to 
achieve other than it 'being a basis for real products'. This is far too 
vague. Is it a tablet style UI with app launcher, and status bar, 
similar to Sato? Or is it a collection of mutually exclusive fullscreen 
apps that somehow showcase common embedded use cases? Please help me 
understand this.

Then there's the question of who's going to do the heavy lifting.
Are we writing, testing and maintaining our own, and if so, who has time 
for it? Or is there some off-the-shelf thing that would fit, and that 
has miraculously escaped our attention until now?


Alex

Re: GUI based images

[Paul Eggleton]

On Wednesday, 10 May 2017 9:31:10 PM NZST Alexander Kanavin wrote:
> On 05/10/2017 12:03 AM, Paul Eggleton wrote:
> > Your opinion is noted. My opinion is that we ought to be providing a good
> > reference that can be used as a basis for real products (regardless of
> > whether whatever direction we choose to go is Qt-based or not) - the rest
> > of our stack *is* used that way, after all. We regularly get comments
> > about how Sato isn't suitable as such a basis, so the expectation is
> > there. I don't think adding Wayland support alone will answer that.
> 
> Paul, I do believe specifics matter, and I'm not seeing much of that in 
> this discussion :-(

Well, we don't have the specifics yet. Discussion about what to do about a 
reference UI has come up a number of times over the last few years (e.g. at OE 
developer meetings) but it hasn't really gone anywhere, because nobody pushed 
it.

I make no secret of it - I am a Qt supporter. I'm willing to be convinced 
that's not the right answer, though, if there are solid arguments. However, if 
you'll excuse my paraphrasing, "it's not in OE-Core and can't be, therefore we 
should just ignore it" isn't a case against it, it's a logistical issue. We 
could easily get past that by bringing meta-qt5 into poky as we do with OE-
Core, or even just adding it to the build configuration as needed.

> No one has yet provided any idea what this reference UI would try to 
> achieve other than it 'being a basis for real products'. This is far too 
> vague. Is it a tablet style UI with app launcher, and status bar, 
> similar to Sato? Or is it a collection of mutually exclusive fullscreen 
> apps that somehow showcase common embedded use cases? Please help me 
> understand this.

So to my mind I think we ought to be doing two things:

1) Have a reference stack that (a) we test regularly and (b) has a reasonable 
expectation of people being able to practically pick it up and build upon it.

2) Show that stack doing something "useful". Tablet-style UIs are interesting 
but you could spend a whole bunch of work building and maintaining that and 
get very little in return - none of our userbase is going to take such a thing 
and use it. On the other hand, a "common embedded use cases" demo set is at 
least theoretically closer to what someone might be doing with the stack in 
production and it's not hard to imagine you could throw a few of those 
together in a fairly short space of time. We may even find people willing to 
contribute something they've already built.

> Then there's the question of who's going to do the heavy lifting.
> Are we writing, testing and maintaining our own, and if so, who has time 
> for it? Or is there some off-the-shelf thing that would fit, and that 
> has miraculously escaped our attention until now?

So, I don't have all the answers - I actually have relatively few of them. The 
main reason I spoke up is I think we need to work through this and figure it 
out rather than shutting down discussion. If we keep Sato effectively on life 
support as we have done up until now, then it'll never get solved, and in the 
mean time we are presenting something that is frankly woefully outdated which 
we have to maintain entirely by ourselves.

(FWIW, I don't think this is something we need to solve in the upcoming 2.4 
development cycle, but I think we ought to be planning to resolve it in 2.5 / 
2.6.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: GUI based images

[Alexander Kanavin]

On 05/10/2017 01:55 PM, Paul Eggleton wrote:
> I make no secret of it - I am a Qt supporter. I'm willing to be convinced
> that's not the right answer, though, if there are solid arguments. However, if
> you'll excuse my paraphrasing, "it's not in OE-Core and can't be, therefore we
> should just ignore it" isn't a case against it, it's a logistical issue. We
> could easily get past that by bringing meta-qt5 into poky as we do with OE-
> Core, or even just adding it to the build configuration as needed.

That's not what I'm saying. I'm saying that for people who want a 
'reference UI for real products' and have no problem with Qt, we should 
officially endorse meta-b2qt.

Seriosuly. They have a wayland compositor, and an app launcher, and a 
set of embedded-specific demos, and it's written and tested by 
specialists with an explicit target of making it easy to make products. 
And it's open source with optional commercial support. In that light, 
there is no sense whatsoever in solving the same problem in oe-core, poorly.

> If we keep Sato effectively on life
> support as we have done up until now, then it'll never get solved, and in the
> mean time we are presenting something that is frankly woefully outdated which
> we have to maintain entirely by ourselves.

Sato is not a reference UI, and has no pretensions of being that. It's 
strictly an engineering UI, which is a different thing, and it's very 
useful in that capacity.

Alex

Re: GUI based images

[Paul Eggleton]

On Wednesday, 10 May 2017 11:09:59 PM NZST Alexander Kanavin wrote:
> On 05/10/2017 01:55 PM, Paul Eggleton wrote:
> > I make no secret of it - I am a Qt supporter. I'm willing to be convinced
> > that's not the right answer, though, if there are solid arguments.
> > However, if you'll excuse my paraphrasing, "it's not in OE-Core and can't
> > be, therefore we should just ignore it" isn't a case against it, it's a
> > logistical issue. We could easily get past that by bringing meta-qt5 into
> > poky as we do with OE-Core, or even just adding it to the build
> > configuration as needed.
> 
> That's not what I'm saying. I'm saying that for people who want a 
> 'reference UI for real products' and have no problem with Qt, we should 
> officially endorse meta-b2qt.
> 
> Seriosuly. They have a wayland compositor, and an app launcher, and a 
> set of embedded-specific demos, and it's written and tested by 
> specialists with an explicit target of making it easy to make products. 
> And it's open source with optional commercial support. In that light, 
> there is no sense whatsoever in solving the same problem in oe-core, poorly.

If that works then great! By all means let's test it and endorse it. At the 
moment we barely even acknowledge it's existence - it's not even in the layer 
index (though that is generally up to the layer maintainer, we can certainly 
encourage them to submit it.)

> > If we keep Sato effectively on life support as we have done up until now,
> > then it'll never get solved, and in the mean time we are presenting
> > something that is frankly woefully outdated which we have to maintain
> > entirely by ourselves.
> 
> Sato is not a reference UI, and has no pretensions of being that. It's 
> strictly an engineering UI, which is a different thing, and it's very 
> useful in that capacity.

You and I might understand that, but someone coming to the project fresh 
won't, mainly because we've never officially stated that anywhere. The only 
mention of anything like it is in fact the opposite - in the development 
manual we state "The Yocto Project ... also features the Sato reference User 
Interface, which is optimized for stylus-driven, low-resolution screens.". 
Granted, that statement is probably as old as Sato itself, but I think it 
speaks to how organised our messaging is on this topic.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: GUI based images

[Alexander Kanavin]

On 05/10/2017 11:15 PM, Paul Eggleton wrote:
> If that works then great! By all means let's test it and endorse it. At the
> moment we barely even acknowledge it's existence - it's not even in the layer
> index (though that is generally up to the layer maintainer, we can certainly
> encourage them to submit it.)

Yes, should definitely be tried out. I have only looked at the contents 
of the layer, and the overview part of the documentation, so I might 
have a bit rosier picture of it :)

I'm not sure how much attention Qt wants to draw to it - they probably 
want to lure people into commercial support contracts instead. However, 
the layer *is* licensed under GPLv3, and it pulls all code from public 
repos. And I can also imagine they could be quite happy to have Qt 
designated the official reference UI in YP.

> You and I might understand that, but someone coming to the project fresh
> won't, mainly because we've never officially stated that anywhere. The only
> mention of anything like it is in fact the opposite - in the development
> manual we state "The Yocto Project ... also features the Sato reference User
> Interface, which is optimized for stylus-driven, low-resolution screens.".
> Granted, that statement is probably as old as Sato itself, but I think it
> speaks to how organised our messaging is on this topic.

Yes, in 2017 this statement should be changed to reflect reality.

Alex

Re: GUI based images

[Jussi Kukkonen]

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

I had a look at b2qt earlier and Alex asked me to share on list as well so
I'll resurrect this thread from May...

On 10 May 2017 at 14:09, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 05/10/2017 01:55 PM, Paul Eggleton wrote:
>
>> I make no secret of it - I am a Qt supporter. I'm willing to be convinced
>> that's not the right answer, though, if there are solid arguments.
>> However, if
>> you'll excuse my paraphrasing, "it's not in OE-Core and can't be,
>> therefore we
>> should just ignore it" isn't a case against it, it's a logistical issue.
>> We
>> could easily get past that by bringing meta-qt5 into poky as we do with
>> OE-
>> Core, or even just adding it to the build configuration as needed.
>>
>
> That's not what I'm saying. I'm saying that for people who want a
> 'reference UI for real products' and have no problem with Qt, we should
> officially endorse meta-b2qt.
>
> Seriosuly. They have a wayland compositor, and an app launcher, and a set
> of embedded-specific demos, and it's written and tested by specialists with
> an explicit target of making it easy to make products. And it's open source
> with optional commercial support. In that light, there is no sense
> whatsoever in solving the same problem in oe-core, poorly.


My verdict after a bit of testing and some light digging at the sources:
Very cool demo, vastly better than Sato for "Trade show demo unit" use case
(although the current content is naturally just Qt marketing). It does not
seem useful as Sato-the-QA-platform replacement and I would be wary of
suggesting it for any product use without caveats: my worry is the
maintenance status of the DE components.

Some details:
* Some of the "Desktop Environment" components are possibly not meant for
production use: e.g. the wayland compositor/WM does not seem completely
finished, either from feature or polish POV. It's even called
"democompositor". The last real code change in the relevant repo was in Feb
2016. For a single app use case this might not matter.
* It wouldn't work as a generic desktop (needs launcher specific files per
application)
* That wouldn't be so bad but the only app they include is the browser, the
rest are ads or demos (browser admittedly is very nice)

Jussi

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

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 12:24 PM, Burton, Ross wrote:
> The development of Wayland does make the long-term prospect of Sato
> interesting: do we port Sato to Wayland too, or keep the Wayland images
> using the standard Weston demo shell?

There is a third option: find a functional, pretty, lightweight wayland 
shell, and provide that. I think the prime candidate for that at the 
moment is Maynard, but it has its own issues, mainly that upstream isn't 
really developing it anymore. Jussi is OOO this week, maybe he can add 
his 2c a bit later.

https://github.com/raspberrypi/maynard/wiki


Alex

Re: GUI based images

[Jussi Kukkonen]

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

On 11 May 2017 at 10:53, Alexander Kanavin <alexander.kanavin@linux.
intel.com> wrote:

> On 05/09/2017 12:24 PM, Burton, Ross wrote:
>
>> The development of Wayland does make the long-term prospect of Sato
>> interesting: do we port Sato to Wayland too, or keep the Wayland images
>> using the standard Weston demo shell?
>>
>
> There is a third option: find a functional, pretty, lightweight wayland
> shell, and provide that. I think the prime candidate for that at the moment
> is Maynard, but it has its own issues, mainly that upstream isn't really
> developing it anymore. Jussi is OOO this week, maybe he can add his 2c a
> bit later.
>
> https://github.com/raspberrypi/maynard/wiki


You pretty much said my 2c: Maynard wouldn't need that much development and
maintenance to be useful as a minimal DE that scales to different devices.
Unfortunately it's not getting the love and care it needs. Writing wayland
compositors/desktops seems to be common pastime so I'm a little sad someone
hasn't picked up Maynard as their hobby project.

Even if Maynard was maintained it would fill a similar niche as Sato now
does for X: not something we'd especially expect people to ship on products.

Jussi

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

Re: GUI based images

[Khem Raj]

On Mon, May 15, 2017 at 5:36 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
> On 11 May 2017 at 10:53, Alexander Kanavin
> <alexander.kanavin@linux.intel.com> wrote:
>>
>> On 05/09/2017 12:24 PM, Burton, Ross wrote:
>>>
>>> The development of Wayland does make the long-term prospect of Sato
>>> interesting: do we port Sato to Wayland too, or keep the Wayland images
>>> using the standard Weston demo shell?
>>
>>
>> There is a third option: find a functional, pretty, lightweight wayland
>> shell, and provide that. I think the prime candidate for that at the moment
>> is Maynard, but it has its own issues, mainly that upstream isn't really
>> developing it anymore. Jussi is OOO this week, maybe he can add his 2c a bit
>> later.
>>
>> https://github.com/raspberrypi/maynard/wiki
>
>
> You pretty much said my 2c: Maynard wouldn't need that much development and
> maintenance to be useful as a minimal DE that scales to different devices.
> Unfortunately it's not getting the love and care it needs. Writing wayland
> compositors/desktops seems to be common pastime so I'm a little sad someone
> hasn't picked up Maynard as their hobby project.
>
> Even if Maynard was maintained it would fill a similar niche as Sato now
> does for X: not something we'd especially expect people to ship on products.

some users of OE make SBCs for them having a good light weight DE is
desired, thats where XFCE and MATE LXDE LXQT etc fill in since they
are light enough
and well used in desktop world too, so you get the right fit, other users of OE
who do graphics and video dont really use DEs, so they are fine with
GL context but there is a shift towards wayland and embedded
compositors around wayland since weston is quite generic e.g. see

https://github.com/rdkcmf/westeros

I am pretty sure one of above DEs will pick wayland at some point but
until then we have weston

Re: GUI based images

[Burton, Ross]

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

On 8 May 2017 at 12:33, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote:

> Sato is extremely lightweight (not just runtime-wise but with regards to
> build time and maintenance effort). I admit I'm not familiar with LXDE but
> other DEs known as lightweight are in reality on another level compared to
> Sato... Sato projects themselves are tiny and depend on very little: this
> is quite beneficial since it keeps the automated test runtimes reasonable.
>

Also Sato works on a wide range of devices: if you have a 30" monitor with
a keyboard/mouse, or a 4" touchscreen, it is still usable.  It's not
optimal on anything, but it's functional on everything.  Put LXDE on a 4"
capacitive touchscreen and you'll probably have trouble getting anything to
start.

Obviously if you're happy to say "I target desktop users" then there's
meta-gnome, meta-xfce, and so on.

Ross

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

Re: GUI based images

[Alexander Kanavin]

On 05/08/2017 02:43 PM, Burton, Ross wrote:

> Obviously if you're happy to say "I target desktop users" then there's
> meta-gnome, meta-xfce, and so on.

I would not recommend meta-gnome, as it's not well maintained, and 
should be used only for adding specific gnome apps to an image. It 
doesn't define any full 'gnome images' or 'gnome packagegroups' that 
would provide an integrated desktop.

Alex

Re: GUI based images

[Belal, Awais]

> Generally, we have resources for maintaining only one GUI desktop in
> oe-core layer, and right now that is Sato. If you're okay with XFCE,
> that is provided via meta-xfce layer

I should probably quote every email on this thread and say THANKS! for the information and explanation.

BR,
Awais

________________________________________
From: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Sent: Monday, May 8, 2017 4:47 PM
To: Burton, Ross; Belal, Awais
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] GUI based images

On 05/08/2017 02:43 PM, Burton, Ross wrote:

> Obviously if you're happy to say "I target desktop users" then there's
> meta-gnome, meta-xfce, and so on.

I would not recommend meta-gnome, as it's not well maintained, and
should be used only for adding specific gnome apps to an image. It
doesn't define any full 'gnome images' or 'gnome packagegroups' that
would provide an integrated desktop.

Alex

Re: GUI based images

[Khem Raj]

On Mon, May 8, 2017 at 4:43 AM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 8 May 2017 at 12:33, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote:
>>
>> Sato is extremely lightweight (not just runtime-wise but with regards to
>> build time and maintenance effort). I admit I'm not familiar with LXDE but
>> other DEs known as lightweight are in reality on another level compared to
>> Sato... Sato projects themselves are tiny and depend on very little: this is
>> quite beneficial since it keeps the automated test runtimes reasonable.
>
>
> Also Sato works on a wide range of devices: if you have a 30" monitor with a
> keyboard/mouse, or a 4" touchscreen, it is still usable.  It's not optimal
> on anything, but it's functional on everything.  Put LXDE on a 4" capacitive
> touchscreen and you'll probably have trouble getting anything to start.
>
> Obviously if you're happy to say "I target desktop users" then there's
> meta-gnome, meta-xfce, and so on.
>

A general usecase is that someone takes the reference and tweaks it to
meet the needs of a product quickly. For such usecases, it would be good to
consider the most widely used UI framework in embedded space. I
personally don't know how much sato is deployed but QT based systems
are quite widely deployed as far as I know. I think users can drive maximum
out of the testing and stabilization we do if they were using the reference
software as much as possible.

Re: GUI based images

[Alexander Kanavin]

On 05/09/2017 01:50 AM, Khem Raj wrote:
> A general usecase is that someone takes the reference and tweaks it to
> meet the needs of a product quickly. For such usecases, it would be good to
> consider the most widely used UI framework in embedded space. I
> personally don't know how much sato is deployed but QT based systems
> are quite widely deployed as far as I know. I think users can drive maximum
> out of the testing and stabilization we do if they were using the reference
> software as much as possible.

Qt itself does not provide a UI, so we would need to find an appropriate 
qt-based replacement for Sato that has the same characteristics and is 
suitable as an 'engineering UI'. What is your suggestion for that?

I personally think meta-qt5 works fine; it's only missing a reference UI 
environment. Why not add LxQt to that layer?


Alex

Re: GUI based images

[Max Krummenacher]

Am Dienstag, den 09.05.2017, 11:10 +0300 schrieb Alexander Kanavin:
> On 05/09/2017 01:50 AM, Khem Raj wrote:
> > A general usecase is that someone takes the reference and tweaks it to
> > meet the needs of a product quickly. For such usecases, it would be good to
> > consider the most widely used UI framework in embedded space. I
> > personally don't know how much sato is deployed but QT based systems
> > are quite widely deployed as far as I know. I think users can drive maximum
> > out of the testing and stabilization we do if they were using the reference
> > software as much as possible.
> 
> Qt itself does not provide a UI, so we would need to find an appropriate 
> qt-based replacement for Sato that has the same characteristics and is 
> suitable as an 'engineering UI'. What is your suggestion for that?
> 
> I personally think meta-qt5 works fine; it's only missing a reference UI 
> environment. Why not add LxQt to that layer?
> 
Andreas already has those recipes in meta-qt5-extra:
https://layers.openembedded.org/layerindex/recipe/39614/

And for those who want a look at LXDE:
http://git.toradex.com/cgit/meta-lxde.git/tree/recipes-lxde/packagegroup/packagegroup-lxde-extended.
bb?h=master

Max

> 
> Alex