4

I am designing an application that should work as GUI or console (command line) app. One mode at a time. When application will be compiled as console it should not use any GUI libraries. As I am doing such thing for the first time, I would like to ask about pitfalls, tips and tricks for such case. What approach wolud be the best? Simply use macros like #define withGUI 1 to switch? Or to make something like client/server solution?

Misery
  • 689
  • 2
  • 8
  • 25
  • 1
    Implementing [interfaces](http://stackoverflow.com/questions/318064/how-do-you-declare-an-interface-in-c) with preprocessor defines is bad even in C. Don't even think about doing it that way. – Kuba hasn't forgotten Monica Mar 13 '14 at 13:51
  • 1
    One thing to note is, your console application should use `QCoreApplication` (or subclass), while GUI version should use something like `QApplication`. It's probably best if you have two subdir projects, which produce separate applications for console and for GUI. Then have shared (non-GUI-depending) code in third subproject, which is a library. – hyde Mar 13 '14 at 16:44

2 Answers2

3

There is a design pattern for this called Model View Controller (MVC). This separates the presentation of data from the model of data itself, with a controller acting as a delegate and controlling the update of the view with updates to the model.

Qt provides a similar system, but just uses the model and view.

The main point to focus on here is the separation of the model of your data from its visual representation. Get that right and it will be simple to maintain both a GUI and console version of your application.

With signals and slots, it's quite simple; any changes made by the view (either GUI or command line) causes a signal to be picked up by the model. Likewise, when data in the model changes, emit signals for the connected view to update its representation of that data.

TheDarkKnight
  • 27,181
  • 6
  • 55
  • 85
  • 1
    Downside of using Qt model-view framework is, it may be a little or even a lot of work to use it from the console version, depending what functionality is needed. Depending what kind of data it is, it may be easier to use something simpler to hold the actual data, then *possibly* use QAbstractItemModel stuff only in the GUI part (with custom model which access the shared data storage). – hyde Mar 13 '14 at 16:49
  • 2
    @hyde, I completely agree. My mentioning MVC and Qt's model-view framework was more for the idea of reference into good design, rather than implying it should be used directly. Perhaps I didn't make that clear enough. – TheDarkKnight Mar 13 '14 at 16:56
  • No, you were clear about the overall idea, I just wanted to bring out that point about using Qt MV framework with console. – hyde Mar 13 '14 at 17:13
2

I would completely separate the business logic and the GUI into the stand alone libraries - one for each. In case of the console application mode I will link to the only library that contains the logical part and to both libraries otherwise. With this you will not need to put #ifdef-s everywhere in your code and make it hard to read.

vahancho
  • 20,808
  • 3
  • 47
  • 55