Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #12298 > unrolled thread

[OT] Good Qt Book

Back to article view | Back to comp.arch.embedded

Contents

  [OT] Good Qt Book Tim Wescott <tim@seemywebsite.really> - 2013-06-25 17:48 -0500
    Re: [OT] Good Qt Book Sebastian Doht <seb_doht@lycos.com> - 2013-07-04 22:47 +0200
      Re: [OT] Good Qt Book Tim Wescott <tim@seemywebsite.really> - 2013-07-04 18:23 -0500
        Re: [OT] Good Qt Book Paul Rubin <no.email@nospam.invalid> - 2013-07-04 17:36 -0700
        Re: [OT] Good Qt Book info@quantum-leaps.com - 2013-07-09 07:33 -0700
          Re: [OT] Good Qt Book Tim Wescott <tim@seemywebsite.really> - 2013-07-09 11:35 -0500
            Re: [OT] Good Qt Book Les Cargill <lcargill99@comcast.com> - 2013-07-09 12:29 -0500
    Re: [OT] Good Qt Book Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> - 2013-09-02 18:24 +0200

#12298 — [OT] Good Qt Book

I'm sure that there is at least one good forum on Qt.  But I know most of 
y'all, I more or less trust your judgment, and I think another embedded 
software guy is going to do a better job of recommending a book than a 
typical desktop programmer.

I have O'Reilly's book on Qt, but it's an older version that covers Qt 3, 
and it doesn't go into much detail on some things that are puzzling to me 
as I try to write things more complicated than "hello world", like 
exactly what defines the lifetime of an object and what are good 
strategies to rope large applications together with the whole "slot/
signal" paradigm.

So -- do you do Qt programming?  Do you have any books to recommend?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [next] | [standalone]

#12411

Am 26.06.2013 00:48, schrieb Tim Wescott:
> I'm sure that there is at least one good forum on Qt.  But I know most of
> y'all, I more or less trust your judgment, and I think another embedded
> software guy is going to do a better job of recommending a book than a
> typical desktop programmer.
>
> I have O'Reilly's book on Qt, but it's an older version that covers Qt 3,
> and it doesn't go into much detail on some things that are puzzling to me
> as I try to write things more complicated than "hello world", like
> exactly what defines the lifetime of an object and what are good
> strategies to rope large applications together with the whole "slot/
> signal" paradigm.
>
> So -- do you do Qt programming?  Do you have any books to recommend?
>


If you use Qt4, a book about Qt3 is rather useless, lots of things have 
changed. The O'Reilly seems to be good but I have not looked at one for 
a while (I am sure a German book won't help you much). I do only litte 
GUI stuff with Qt once a while and the online documentation is really a 
great ressource.
Just beware that the Qt framework can handle a lot of stuff but its main 
focus is GUI and not performance. I heard stories were performance of 
applications using Qt for everything was an issue. The signal-slot 
paradigm can also become a mess to debug for applications using rather 
complicated control work. Thats why it is always a good to use Qt only 
for the GUI frontend and let it talk to a backend application doing the 
real work.

Best regards,

Sebastian

Ps: To say at least something useful: The lifetime of a Qt Object is 
bound to the lifetime of its parent which is usually some visual element 
(Dialog, Widget, MainForm etc.)

[toc] | [prev] | [next] | [standalone]

#12414

On Thu, 04 Jul 2013 22:47:23 +0200, Sebastian Doht wrote:

> Am 26.06.2013 00:48, schrieb Tim Wescott:
>> I'm sure that there is at least one good forum on Qt.  But I know most
>> of y'all, I more or less trust your judgment, and I think another
>> embedded software guy is going to do a better job of recommending a
>> book than a typical desktop programmer.
>>
>> I have O'Reilly's book on Qt, but it's an older version that covers Qt
>> 3,
>> and it doesn't go into much detail on some things that are puzzling to
>> me as I try to write things more complicated than "hello world", like
>> exactly what defines the lifetime of an object and what are good
>> strategies to rope large applications together with the whole "slot/
>> signal" paradigm.
>>
>> So -- do you do Qt programming?  Do you have any books to recommend?
>>
>>
> 
> If you use Qt4, a book about Qt3 is rather useless, lots of things have
> changed. The O'Reilly seems to be good but I have not looked at one for
> a while (I am sure a German book won't help you much). I do only litte
> GUI stuff with Qt once a while and the online documentation is really a
> great ressource.
> Just beware that the Qt framework can handle a lot of stuff but its main
> focus is GUI and not performance. I heard stories were performance of
> applications using Qt for everything was an issue. The signal-slot
> paradigm can also become a mess to debug for applications using rather
> complicated control work. Thats why it is always a good to use Qt only
> for the GUI frontend and let it talk to a backend application doing the
> real work.
> 
> Best regards,
> 
> Sebastian
> 
> Ps: To say at least something useful: The lifetime of a Qt Object is
> bound to the lifetime of its parent which is usually some visual element
> (Dialog, Widget, MainForm etc.)

Thanks Sebastian.  Much of what you say I already know.  I'm in about the 
same situation as you vis-a-vis Qt: I use it when I need a GUI, usually 
on some test software.  I hadn't really noticed the slowness, because I'm 
usually doing something small.

The software I'm working on at the moment has a little bitty component 
that will ultimately be put on a board with an ARM processor, but in the 
mean time I'm debugging it on a PC.  I need pretty graphs and buttons and 
file access and all that stuff to talk to it, hence Qt.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#12415

Tim Wescott <tim@seemywebsite.really> writes:
> The software I'm working on at the moment has a little bitty component 
> that will ultimately be put on a board with an ARM processor, but in the 
> mean time I'm debugging it on a PC.  I need pretty graphs and buttons and 
> file access and all that stuff to talk to it, hence Qt.

If it's just for debugging and demos and you don't need a really slick
consumer GUI app, the simplest approach may be to embed an HTTP server
in your program and point a browser at it.  Then all the gui elements
become simple HTML, which is usually easier than programming an in-app
gui toolkit.

[toc] | [prev] | [next] | [standalone]

#12439

On Thursday, July 4, 2013 7:23:38 PM UTC-4, Tim Wescott wrote:
> The software I'm working on at the moment has a little bitty
> component that will ultimately be put on a board with an ARM
> processor, but in the mean time I'm debugging it on a PC.
> I need pretty graphs and buttons and file access and all that
> stuff to talk to it, hence Qt.

> Tim Wescott

Tim, if your goal is not to use Qt in the final product, I would _not_ recommend to use it just for prototyping/developing. It seems to me that what you really need is a simple C library, which would allow you to render the embedded user interface with and LCD, LEDs, and buttons on a Windows PC, but that would provide a direct binding to C. This, in turn, would allow you to run the _same_ code on the PC and in the embedded target. Of course, you need to clearly define a Board Support Package interface to separate the platform-dependent implementations, but this is a good thing in the long run.

Anyway, I've blogged about this exact issue in a post entitled "Dual Targeting and Agile Prototyping of Embedded Software on Windows" (see http://embeddedgurus.com/state-space/2013/04/dual-targeting-and-agile-prototyping-of-embedded-software-on-windows/). The blog points you to a simple, open source GUI library for Win32 and example code.

Miro Samek
state-machine.com 

[toc] | [prev] | [next] | [standalone]

#12440

On Tue, 09 Jul 2013 07:33:25 -0700, info wrote:

> On Thursday, July 4, 2013 7:23:38 PM UTC-4, Tim Wescott wrote:
>> The software I'm working on at the moment has a little bitty component
>> that will ultimately be put on a board with an ARM processor, but in
>> the mean time I'm debugging it on a PC.
>> I need pretty graphs and buttons and file access and all that stuff to
>> talk to it, hence Qt.
> 
>> Tim Wescott
> 
> Tim, if your goal is not to use Qt in the final product, I would _not_
> recommend to use it just for prototyping/developing. It seems to me that
> what you really need is a simple C library, which would allow you to
> render the embedded user interface with and LCD, LEDs, and buttons on a
> Windows PC, but that would provide a direct binding to C. This, in turn,
> would allow you to run the _same_ code on the PC and in the embedded
> target. Of course, you need to clearly define a Board Support Package
> interface to separate the platform-dependent implementations, but this
> is a good thing in the long run.
> 
> Anyway, I've blogged about this exact issue in a post entitled "Dual
> Targeting and Agile Prototyping of Embedded Software on Windows" (see
> http://embeddedgurus.com/state-space/2013/04/dual-targeting-and-agile-
prototyping-of-embedded-software-on-windows/).
> The blog points you to a simple, open source GUI library for Win32 and
> example code.
> 
> Miro Samek state-machine.com

That's interesting advise.  For someone other than me, granted, but it's 
interesting advise.

What I'm doing is prototyping a signal processing algorithm that's going 
to live in a headless processor that will communicate with a second, 
separate processor running a customer-oriented GUI.  I will never touch 
their GUI -- I need my own GUI.

I need a Tim-oriented GUI, or maybe an engineer-oriented GUI, that 
initially hosts the natively-compiled function, but later will talk on 
the serial link to the remote board.  Because of the nature of the 
algorithm, I need to present its output in a graphical manner to properly 
debug the algorithm and its implementation.

The nature of the data that I want to throw up on the screen is markedly 
different from what my customer wants to show _their_ customer: at best 
it is rich in confusing (to the end user) detail; at worst it will be 
giving up a lot of clues to proprietary methods and information that we 
don't want to share.

So I need a GUI that I can sit here and happily write my way, without 
polluting the customer's user-oriented GUI with my needs, or polluting 
their schedule with my demands, or allowing them to hold me back with 
their needs for a clean user interface.

I use Qt because even on a single platform its a much easier environment 
to get quick GUI's up and running than to try to just talk directly to X, 
and it's C++ based which is the language that I'm most familiar with 
using.  So even though it's huge and clunky, in its way, I still find it 
useful: I just want to be a bit better at it.

And, in the event that a customer ever says "hey -- we need that!", well, 
I work on a Linux machine, and most of my customers use Windows.  I'm 
sure that I'd find all sorts of pitfalls the first time I set out to 
build one of my projects on mingw, but I'd be much further along to a 
solution than I would if I weren't using Qt.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#12442

Tim Wescott wrote:
> On Tue, 09 Jul 2013 07:33:25 -0700, info wrote:
>
<snip>
>
> And, in the event that a customer ever says "hey -- we need that!", well,
> I work on a Linux machine, and most of my customers use Windows.  I'm
> sure that I'd find all sorts of pitfalls the first time I set out to
> build one of my projects on mingw, but I'd be much further along to a
> solution than I would if I weren't using Qt.
>


This gets a lot easier when you learn something like Tcl or Python for 
these sort of quick-and-dirty, or personal GUI apps. Either Python
or Tcl are fiddly enough without having to suffer the slings and arrows 
of Qt.

If you need some sort of 'C' program with a scripting language,
then you can open the 'C' program as a pipe and whale away.

Since time on the personal GUI is, in essence, sunk cost...

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#13294

Tim Wescott skrev 2013-06-26 00:48:
> I'm sure that there is at least one good forum on Qt.  But I know most of
> y'all, I more or less trust your judgment, and I think another embedded
> software guy is going to do a better job of recommending a book than a
> typical desktop programmer.
>
> I have O'Reilly's book on Qt, but it's an older version that covers Qt 3,
> and it doesn't go into much detail on some things that are puzzling to me
> as I try to write things more complicated than "hello world", like
> exactly what defines the lifetime of an object and what are good
> strategies to rope large applications together with the whole "slot/
> signal" paradigm.
>
> So -- do you do Qt programming?  Do you have any books to recommend?
>

Qt Development by Johan Thelin
www.apress.com

BR
Ulf Samuelsson

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web