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
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
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.
Tim, if your goal is not to use Qt in the final product, I would _not_ reco mmend to use it just for prototyping/developing. It seems to me that what y ou really need is a simple C library, which would allow you to render the e mbedded 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 t o 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 pl atform-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 Target ing and Agile Prototyping of Embedded Software on Windows" (see
formatting link
The blog points you to a simple, open source GUI library for Win32 and example code.
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
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...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.