GUI based images

Hi,

Can anyone please shed some light on why OE only provides SATO based

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.

Quoted 6 lines · Jussi Kukkonen

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 :).

Quoted 3 lines

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?

Quoted 4 lines · Paul Eggleton

Quoted 3 lines

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 :).

Quoted 1 line

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

Quoted 5 lines · Alexander Kanavin

Quoted 4 lines · Paul Eggleton

Quoted 3 lines

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 :).

Quoted 7 lines

Quoted 1 line

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.

wrote:

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

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/

Quoted 17 lines · Alexander Kanavin

Quoted 5 lines · Paul Eggleton

Quoted 3 lines

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.

Quoted 1 line

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

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

Quoted 3 lines · Paul Eggleton

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

Quoted 10 lines · Khem Raj

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.

Quoted 8 lines · Khem Raj

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.

Quoted 10 lines · NZST Alexander Kanavin

Quoted 8 lines · Khem Raj

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

Quoted 3 lines

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.

Quoted 8 lines

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

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.

Quoted 6 lines · Paul Eggleton

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?

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.

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.

Quoted 7 lines · Paul Eggleton

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.

Quoted 4 lines

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.

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.)

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.

Quoted 11 lines · Paul Eggleton

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.

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?

Quoted 4 lines · Ross

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

Quoted 8 lines · Alexander Kanavin

Quoted 4 lines · Ross

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?

Quoted 7 lines

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.

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.

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

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

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

Quoted 6 lines · Jussi Kukkonen

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.

Quoted 7 lines

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