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
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 W
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
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
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 sub
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 pa
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 i
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 w
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,
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 proje
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
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 u
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
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
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
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 fro
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.open
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/cgi
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 bas
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-creati
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
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 li
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 deploye
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 ex
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
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 lightwei
on.
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&#
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 d
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 project
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 thems
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
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
--
_
32 matches
Mail list logo
