[Buildroot] GTK vs Qt

[Buildroot] GTK vs Qt

[Zoran Djordjevic]

When I run GTK demo programs on my ARM board?(built during linux building 
by Buildroot), I start them by quoting it in xinitrc file (together with window 
manager)?and then giving xinit command (is there some other way ?). 
However, when running Qt demo?programs (linux built with Qt support), I can 
start them with quoting only?-qws option (obviously programs are built with
QtCreator) - ie. no xinit ...?
Difference is also regarding startup times (which is?pretty big?difference when
speaking of first start).
What interests me is why different methods of starting GTK and Qt programs and
also why so huge startup?time difference ?
?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121119/d0c968a7/attachment-0001.html>

[Buildroot] GTK vs Qt

[Thomas Petazzoni]

Dear Zoran Djordjevic,

On Mon, 19 Nov 2012 22:40:04 -0800 (PST), Zoran Djordjevic wrote:

> When I run GTK demo programs on my ARM board?(built during linux building 
> by Buildroot), I start them by quoting it in xinitrc file (together with window 
> manager)?and then giving xinit command (is there some other way ?). 
> However, when running Qt demo?programs (linux built with Qt support), I can 
> start them with quoting only?-qws option (obviously programs are built with
> QtCreator) - ie. no xinit ...?
> Difference is also regarding startup times (which is?pretty big?difference when
> speaking of first start).
> What interests me is why different methods of starting GTK and Qt programs and
> also why so huge startup?time difference ?

The Qt you're using runs directly on the framebuffer, so there is no
X.org server. But it's also possible to run Qt on top of X.org (through
not supported by Buildroot at this time).

The Gtk version you're using runs on top of the X.org server, so the
X.org server has to start and initialize itself before starting your
application. It is also possible to run Gtk on top of DirectFB, which
is a lightweight library on top of the framebuffer. However, the Gtk
DirectFB backend has proven to not be that well maintained over the
years, so I'm not sure it's really a good choice.

So basically, you're comparing something that runs on top of X.org with
something that doesn't run on top of X.org.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] GTK vs Qt

[Zoran Djordjevic]

Does it mean that I cannot start?Qt programs built the way 
to use X (on Buildroot built linux)? Or does it mean that I 
must use QtCreator if I want GUI on embedded boards with 
Buildroot built linux ?

Regards 

________________________________
 From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com> 
Cc: "buildroot at busybox.net" <buildroot@busybox.net> 
Sent: Tuesday, November 20, 2012 10:01 AM
Subject: Re: [Buildroot] GTK vs Qt
  
Dear Zoran Djordjevic,

On Mon, 19 Nov 2012 22:40:04 -0800 (PST), Zoran Djordjevic wrote:

> When I run GTK demo programs on my ARM board?(built during linux building 
> by Buildroot), I start them by quoting it in xinitrc file (together with window 
> manager)?and then giving xinit command (is there some other way ?). 
> However, when running Qt demo?programs (linux built with Qt support), I can 
> start them with quoting only?-qws option (obviously programs are built with
> QtCreator) - ie. no xinit ...?
> Difference is also regarding startup times (which is?pretty big?difference when
> speaking of first start).
> What interests me is why different methods of starting GTK and Qt programs and
> also why so huge startup?time difference ?

The Qt you're using runs directly on the framebuffer, so there is no
X.org server. But it's also possible to run Qt on top of X.org (through
not supported by Buildroot at this time).

The Gtk version you're using runs on top of the X.org server, so the
X.org server has to start and initialize itself before starting your
application. It is also possible to run Gtk on top of DirectFB, which
is a lightweight library on top of the framebuffer. However, the Gtk
DirectFB backend has proven to not be that well maintained over the
years, so I'm not sure it's really a good choice.

So basically, you're comparing something that runs on top of X.org with
something that doesn't run on top of X.org.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121120/6d6b5294/attachment.html>

[Buildroot] GTK vs Qt

[Thomas Petazzoni]

Dear Zoran Djordjevic,

On Tue, 20 Nov 2012 02:02:51 -0800 (PST), Zoran Djordjevic wrote:

> Does it mean that I cannot start?Qt programs built the way 
> to use X (on Buildroot built linux)?

Sorry, I don't understand your question. I'll try to explain things
differently.

At the moment, Buildroot is only capable of building a Qt library that
works on top of the framebuffer. It is possible to add support to build
Qt on X.org, but no-one has worked on that until now. So for your
target, with the current Buildroot, if you use Qt, it's on the
framebuffer.

That said, your Qt application itself, if written correctly, can also
be compiled for your desktop machine, and in this case, the Qt you have
in your desktop distribution uses X.org as its graphic backend.

> Or does it mean that I must use QtCreator if I want GUI on embedded
> boards with Buildroot built linux ?

I really don't see the relation between QtCreator and the whole
discussion. QtCreator is an IDE that has some interesting features to
do Qt development, but:

 * You can do Qt development without QtCreator. I've done quite a bit
   of Qt development in Emacs.

 * You can do non-Qt development with QtCreator.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] GTK vs Qt

[Zoran Djordjevic]

OK -let me put question this way. If I successfully compile/run 
QT program on desktop, and then recompile the same source with
let's say Builtroot built compiler (for ARM), should I expect that 
this program will understand -qws option (which I thought is strictly
related to QtCreator). The only way I succeeded to start Qt demo 
programs was with -qws. Hope it's more clear question.
?
Regards
 

________________________________
 From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com> 
Cc: "buildroot at busybox.net" <buildroot@busybox.net> 
Sent: Tuesday, November 20, 2012 11:09 AM
Subject: Re: [Buildroot] GTK vs Qt
  
Dear Zoran Djordjevic,

On Tue, 20 Nov 2012 02:02:51 -0800 (PST), Zoran Djordjevic wrote:

> Does it mean that I cannot start?Qt programs built the way 
> to use X (on Buildroot built linux)?

Sorry, I don't understand your question. I'll try to explain things
differently.

At the moment, Buildroot is only capable of building a Qt library that
works on top of the framebuffer. It is possible to add support to build
Qt on X.org, but no-one has worked on that until now. So for your
target, with the current Buildroot, if you use Qt, it's on the
framebuffer.

That said, your Qt application itself, if written correctly, can also
be compiled for your desktop machine, and in this case, the Qt you have
in your desktop distribution uses X.org as its graphic backend.

> Or does it mean that I must use QtCreator if I want GUI on embedded
> boards with Buildroot built linux ?

I really don't see the relation between QtCreator and the whole
discussion. QtCreator is an IDE that has some interesting features to
do Qt development, but:

* You can do Qt development without QtCreator. I've done quite a bit
?  of Qt development in Emacs.

* You can do non-Qt development with QtCreator.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121120/015f88c3/attachment-0001.html>

[Buildroot] GTK vs Qt

[Thomas Petazzoni]

Dear Zoran Djordjevic,

On Tue, 20 Nov 2012 02:23:35 -0800 (PST), Zoran Djordjevic wrote:
> OK -let me put question this way. If I successfully compile/run 
> QT program on desktop, and then recompile the same source with
> let's say Builtroot built compiler (for ARM), should I expect that 
> this program will understand -qws option (which I thought is strictly
> related to QtCreator). The only way I succeeded to start Qt demo 
> programs was with -qws. Hope it's more clear question.

Aaah. Ok. No, -qws *has* nothing to do with Qt Creator.

-qws is the option to tell Qt to start the Qt Windowing System.

When you run a Qt application on your desktop, there is already a
windowing system (X.org) and a window manager. So Qt is just a toolkit
like any other, it just draws inside a window provided by the windowing
system.

However, when you build Qt for your embedded system so that it runs
directly on the framebuffer, there is no windowing system provided. So
Qt has its own, that you must enable for the *first* Qt application you
run, using the -qws option.

You can run multiple Qt applications on your embedded system thanks to
this. The first one will have to be started with -qws, the other ones
will automatically connect to the first one thanks to a Unix socket,
and therefore be able to share the screen.

You probably want to read:

 http://doc.qt.digia.com/qt/qt-embedded-architecture.html
 http://doc.qt.digia.com/qt/qt-embedded-running.html

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] GTK vs Qt

[Zoran Djordjevic]

Thanks, it's more clear now. I will read articles you
pointed at. Maybe I will have some more questions then.
?
Regards
 

________________________________
 From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com> 
Cc: "buildroot at busybox.net" <buildroot@busybox.net> 
Sent: Tuesday, November 20, 2012 11:45 AM
Subject: Re: [Buildroot] GTK vs Qt
  
Dear Zoran Djordjevic,

On Tue, 20 Nov 2012 02:23:35 -0800 (PST), Zoran Djordjevic wrote:
> OK -let me put question this way. If I successfully compile/run 
> QT program on desktop, and then recompile the same source with
> let's say Builtroot built compiler (for ARM), should I expect that 
> this program will understand -qws option (which I thought is strictly
> related to QtCreator). The only way I succeeded to start Qt demo 
> programs was with -qws. Hope it's more clear question.

Aaah. Ok. No, -qws *has* nothing to do with Qt Creator.

-qws is the option to tell Qt to start the Qt Windowing System.

When you run a Qt application on your desktop, there is already a
windowing system (X.org) and a window manager. So Qt is just a toolkit
like any other, it just draws inside a window provided by the windowing
system.

However, when you build Qt for your embedded system so that it runs
directly on the framebuffer, there is no windowing system provided. So
Qt has its own, that you must enable for the *first* Qt application you
run, using the -qws option.

You can run multiple Qt applications on your embedded system thanks to
this. The first one will have to be started with -qws, the other ones
will automatically connect to the first one thanks to a Unix socket,
and therefore be able to share the screen.

You probably want to read:

http://doc.qt.digia.com/qt/qt-embedded-architecture.html
http://doc.qt.digia.com/qt/qt-embedded-running.html

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121120/eec4210b/attachment.html>