Design pattern for GUI and NON GUI mode.
-
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. -
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.
@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. -
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. -
@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?
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. -
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.@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 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?@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.
-
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.
-
@SGaist said in Design pattern for GUI and NON GUI mode.:
DBus
What if I need to update the GUI in seperate thread ?
-
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) -
@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 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 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. -
@jsulm Slot will be in GUI part only and signal will emitted from core.
so should I do event processing in diffrent thread?@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
-
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?
-
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?
@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.
-
starting event loop means here calling app->exec() ? But it makes the application blocking.
-
starting event loop means here calling app->exec() ? But it makes the application blocking.
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
starting event loop means here calling app->exec()
No.
Please read documentation: https://doc.qt.io/qt-5/qthread.html
" QThread object manages one thread of control within the program. QThreads begin executing in run(). By default, run() starts the event loop by calling exec() and runs a Qt event loop inside the thread." -
Yes I have read this,
My QT application launches two forms (main window) then I called app->exec.
Then other application use to update data in my QT application using dll interface functions.
But if call app->exec() there in no update in GUI.
I need to call processEvents() for that
-
Yes I have read this,
My QT application launches two forms (main window) then I called app->exec.
Then other application use to update data in my QT application using dll interface functions.
But if call app->exec() there in no update in GUI.
I need to call processEvents() for that
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
But if call app->exec() there in no update in GUI.
Where do you call this? In this DLL?
I'm confused a bit with your description.
Is this other app a completely different app (other process)? -
Yes other app is different app (Non QT C++ application) which will call my QT application as dll application and will process the data from it and fetch the data using interface applications.
-
Yes other app is different app (Non QT C++ application) which will call my QT application as dll application and will process the data from it and fetch the data using interface applications.
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
which will call my QT application
In this case your Qt application is not an application but a DLL.
In this case you can run your DLL in another thread where you call app->exec().
But I'm still confused: is this other app a non-gui (console) app? If so why does it load a DLL which opens a GUI?
It should be other way around: you have a GUI application (Qt) which uses a DLL. This DLL does the data processing and passes the data from/to Qt application.
