Re: [OE-core] GUI based images
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.kana...@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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On Mon, May 15, 2017 at 5:36 AM, Jussi Kukkonen wrote: > On 11 May 2017 at 10:53, Alexander Kanavin > 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On 11 May 2017 at 10:53, Alexander Kanavin 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On Tue, May 9, 2017 at 1:39 PM, 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. 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. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On Tue, May 9, 2017 at 2:24 AM, Burton, Ross wrote: > > On 8 May 2017 at 23:15, Paul Eggleton 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On 9 May 2017 at 10:30, Alexander Kanavin 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On 8 May 2017 at 23:15, Paul Eggleton 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On Mon, May 8, 2017 at 4:43 AM, Burton, Ross wrote: > > On 8 May 2017 at 12:33, 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. > > > 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. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
> 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 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On 8 May 2017 at 12:33, 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. > 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GUI based images
On 8 May 2017 at 13:51, Belal, Awais 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] GUI based images
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
