CODEWITHSUNDEEP
c++qt
user360907
user360907

Reputation:

Qt vs native when writing a background application

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:

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.

Upvotes: 7

Views: 2466

Answers (2)

charley
charley

Reputation: 5949

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.)

Upvotes: 12

Nathanael
Nathanael

Reputation: 1772

It doesn't matter if you use Qt or native Linux for your UI as long as you split your UI from your business logic.

I would suggest that you write your business logic as a separate application. As much as possible, keep any platform specific code outside of this application. This provides two benefits IMO.

  1. You get a command line version of your application for free.
  2. You can easily implement a new GUI to drive your application in whatever language/technology you want.

In answer to a few of your specific questions:

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

Qt will always do quirky things ;)

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

Not necessarily. You will have to do some native coding to install your button into the different locations of each platform. One strategy for building GUI's is to not even try to use cross platform code such as Qt, and to instead rewrite the GUI portion of your application in the preferred technology for each platform. For you that would mean C# WPF/Forms in Windows, GTK for Linux (since you specified Gnome), and Objective C/Cocoa for Mac OSX.

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?

Not more so than any other GUI technology.

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.

On Windows it's not terribly difficult. I'm not sure about Gnome or Mac OS X.

Upvotes: 3

Related Questions