Question

I’m about to write a piece of software for my MSc project in C++ and I wish to use this as an opportunity to learn either the Linux native API or the Qt API, both of which are of interest to me, but I’m not sure which one would be more appropriate. I’m sorry if this question seems long, convoluted and somewhat ambiguous, but I fear that if I make the wrong decision now, it could derail the entire project.

The application I am going to create has very little in the way of an interface. It will and a configuration menu, a couple of dialogues with progress bars that inform the user that stuff’s happening, and a button that will make the application do it’s thing. I intend, in the long run, to deploy this application on Windows, Mac OS and Linux, and this button will have a different location on each platform (Gnome panel on Linux, system tray on Windows, and whatever the panel is called on Mac OS).

The rest of it will be running in the background, and when the user presses the button to get it going, it will seek out certain pieces of information about the applications that are currently running, compile it into a XML file, and synchronise it, via a service I’m also going to produce myself and host on and Amazon EC2 instance running Linux. When they log onto another computer connected to this EC2 instance and hit the ‘application go’ button, the synced data will be pulled down and placed on their computer.

Now my question:

What would be the better choice of API here: native or Qt? While Qt would seem like the obvious choice for a cross-platform application, some of my concerns are:

• Will Qt become quirky if I try to do stuff without using the GUI widgets?
• Is going native (and thus, pretty deep into the OS) overkill for something such as this?
• Given that the app is going to be running in the background, and thus alongside other applications, will Qt, and the additional layers of abstraction it will bring with it, have a detrimental effect on the performance of the rest of the user’s session?
• If I use Qt, how difficult will it be to ‘break out’ of the Qt wrapper for things like placing the ‘application go’ button in the appropriate location on each platform.

While I have mentioned that I want it to be cross-platform, I’ve had some pretty bad experiences with applications that have been ported to a platform using a dropdown menu, and will happily rewrite the client-side app if it results in a substantial improvement in the user experience.

Answer 1

I vote Qt. The Qt code base is nicely factored to separate the “QtCore” library from the “QtGui” libary. The “QtCore” includes support for processes/threads, signals/slots, and state like that which would be used “independent” of GUI components. (For example, the “QSlider” widget is merely a GUI component that presents the state managed by the actual component inside the QtCore library, which is useful for bounds checking a value-within-a-range, which can be nicely applied even on non-GUI applications, like hardware control systems.)

For some problems, the signals/slots uniquely provides many design options (flexibility). It fundamentally permits communication/signaling between types and objects that are not directly coupled (e.g., when neither includes the header of the other). While not all designs warrant that, it is dynamic and powerful for inter-process communication, hardware control systems, flexibly-scaled module systems, and GUI applications.

Finally, the cross-platform wrapping of “convenience” things like processes/threads is very nice, thread-safety through signals/slots is very nice, the read/write codecs, file parsing, and media file support is very nice, and it has “QDesktop“-type things that makes your “icon tray” and other platform-specific implementation much easier.

Qt is not at all quirky when you don’t use the QtGui library. (Just make sure to use “-= QtGui” in your qmake if you don’t want to link the QtGui.lib, not a big deal.)

Will Qt become quirky if I try to do stuff without using the GUI
widgets?

No. However, it does have build requirements (e.g., “moc”).

Is going native (and thus, pretty deep into the OS) overkill for
something such as this?

No, but depending on your language, you’ll need support for threads, processes, codecs, etc. So, Qt can simplify that (since those are not handled directly by the C/C++ languages, you’ll need a library of some kind).

Given that the app is going to be running in the background, and thus
alongside other applications, will Qt, and the additional layers of
abstraction it will bring with it, have a detrimental effect on the
performance of the rest of the user’s session?

No. For cross-thread and cross-process communication, it will be about as fast as you can get. For GUI, it will be on par with any GUI (but probably one of the fastest of any GUI).

If I use Qt, how difficult will it be to ‘break out’ of the Qt wrapper
for things like placing the ‘application go’ button in the
appropriate location on each platform.

Pretty easy — it’s cross-platform, but you have tremendous flexibility for platform-specific coupling. (e.g., embed Qt in MFC-app is easy, embedding MFC in Qt app is easy, mixing QML/Qt-Widgets is easy, etc.)