Design pattern for GUI and NON GUI mode.

Ayush Gupta

I am trying to create an QT application which can run in GUI and NON-GUI mode.

The goal is all the work that has to be done in GUI mode should also be done in Non-GUI mode but in NON-GUI mode I will not have overhead of creating the instance of GUI and so my code works faster.

Can anyone please suggest me good design pattern for this ?

In GUI mode I need to have abstraction with GUI in GUI mode and in NON-GUI mode the GUI mode should be replaced by empty stub something like that ?

Please provide some suggestions.

jsulm

@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:

all the work that has to be done

What kind of work is that?
The simple solution is to put this work in gui independant modules (cpp files) and use these modules in both modes to do the actual work.

Ayush Gupta

It will be dll which will be called by other applications. In Non-gui mode it should process all the data (without intialising the UI component) and in GUI mode it should process all the data but present information in form of GUI to the user and user can able to input it manually.

JonB

@Ayush-Gupta
Unless @jsulm says otherwise: my thought would be to provide two DLLs, one uses no UI stuff at all, the other does use UI and makes calls into the non-UI for services.

Ayush Gupta

The problem is I am already having code implemented but the code of GUI is tightly coupled with code with NON-GUI.

I want to run application in both GUI and NON-GUI mode. In NON-GUI mode there should be no overhead of creating instance of GUI components (forms etc) but in GUI all instances of form etc should be created.

I need to refactor my existing code without doing much over head.

And the GUI components should be initialised and created in GUI mode only.

Is any design pattern can be pushed for abstraction ?

Snorkelbuckle

Looks like you can do what you want using QApplication.

Check this out, there is even detailed information on how to do it, although I've never tried it, looks promising.

https://doc.qt.io/qt-5/qapplication.html#details

Here is an excerpt:

  QCoreApplication* createApplication(int &argc, char *argv[])
  {
      for (int i = 1; i < argc; ++i)
          if (!qstrcmp(argv[i], "-no-gui"))
              return new QCoreApplication(argc, argv);
      return new QApplication(argc, argv);
  }

  int main(int argc, char* argv[])
  {
      QScopedPointer<QCoreApplication> app(createApplication(argc, argv));

      if (qobject_cast<QApplication *>(app.data())) {
         // start GUI version...
      } else {
         // start non-GUI version...
      }

      return app->exec();
  }

mrjj

Hi
This is the classic pattern where you want to separate the data and presentation.
So you want to move all code to from Mainwindow to a separate non-gui class
that handles the data and its processing as a unit.
Then change Mainwindow to simply call methods of this data handler class both to alter data and
to get data to show.

For the non gui application, you would then simply call the methods of the data handler class
as needed.

so basically the first task is to decouple all data processing from MainWindow to
own class.

Astrinus

@Ayush-Gupta Have you looked into Hexagonal Architecture? Netflix Tech Blog has a good explanation: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749
A way to apply to a Qt application means your DLL exposes only "business logic classes", that communicate by means of signal and slots. You can think the classes in the DLL being Lego pieces.
Then in the main (a.k.a. composition root a.k.a the one that assembles Lego pieces together to create a sculpture) you wire DLL classes together and to your GUI (if you have one) in order to make them act as you would.
Bear in mind that I am not speaking in theory, most of software that was developed [at least in part] by me follows this structure and has proven to be {fully AND easily} testable, easy to adapt/change and rock solid.

Ayush Gupta

@mrjj In the case shoukd I not create instance of MainWindow class for non-gui mode?

In GUI mode how can I connect signal/slots of core with GUI?

mrjj

@Ayush-Gupta

Exactly. Structure the code so all logic, data processing and handling is with the classes so it can do the same with and without a MainWindow.

If you let core classes inherit QObject ( and add the macro also)
then you can directly use signal and slot regardless of gui / non gui.

Ayush Gupta

@mrjj Would this be good desgin to inherit Q_OBJECT to core class?
And if we do not intialise GUI in non-gui mode but still signal will be sent to core.
Won't that extra burden to the core application where emitting signal not required for non-gui application?

mrjj

@Ayush-Gupta
Hi
The price is not that high for normal designs,
as you won't have a thousand instances of core class etc .

Also signal and slots are a core design element in Qt
so even non-GUI classes like network use signals & slots so
if your goal is to have the same code work with both a GUI on top and via command line, i
would surely use signals and slots with "core"

Its only if you wanted core to be 100% clean of any Qt so it could also be used without any Qt at all, i would resort to use callback etc.

The signal and slot system is just much better than classic callbacks.

SGaist

Hi,

I think I have at least partly answered on your other thread with regard to that.

From your description, it feels like you are currently trying to couple these two modes too much in one single application.

I'd recommend taking some time to do a bit of design so you can really cleanly separate the functionalities which belongs to each type of application.

This makes me think a bit of linux daemons. Many of them are running in the background as they should be have an API that you can use to talk with them for example using DBus. With that you can write a GUI that's completely decoupled from the "core" part that keeps running its life.

Ayush Gupta

@SGaist said in Design pattern for GUI and NON GUI mode.:

DBus

What if I need to update the GUI in seperate thread ?

Ayush Gupta

My GUI and core will be called by other application and it will provided in one dll application.
So I need to communicate between core and GUI with one dll and update the GUI in seperatee thread,

Below is the flow which I need to design.

Application <-----> Get Data <----->
QT Application ----> Core
<------>Set Data<-----> -----> Gui ( The data in GUI should be
updated in seperate thread
but data should come from
core)

jsulm

@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:

What if I need to update the GUI in seperate thread ?

This is not supported!
If you need to update the UI from other thread then simply emit signals from that thread and update UI in the slots in main thread.

Ayush Gupta

@jsulm Slot will be in GUI part only and signal will emitted from core.
so should I do event processing in diffrent thread?

jsulm

@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:

so should I do event processing in diffrent thread?

Events are not related to signals/slots

Ayush Gupta

There are lot of lag in my system which involved this QT application also.

I need to reduce lags by creating a headless mode application (without GUI). and also if GUI is launched then it should be updated in a diffrent thread.

I understand that seperating core and GUI works here. with signal/slots core and GUI can communicate.

I also know that processEvents() should be called to keep GUI alive if we dont call app->exec(),

How can I update GUI in seperate thread ? Is the processEvents() is causes lag which I need to call and process in extra thread?

Or signal/slots are also burder?

jsulm

@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:

How can I update GUI in seperate thread ?

Again: you do NOT update GUI from another thread as GUI thread! This is simply not supported.
Your other thread should only tell GUI thread to update.

"Or signal/slots are also burder?" - in what way?

"Is the processEvents() is causes lag" - if you're using processEvents then your design is most likely broken. It should not be used. Simply start event loop, this is how Qt applications work.