Design pattern for GUI and NON GUI mode.

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.

Ayush Gupta

starting event loop means here calling app->exec() ? But it makes the application blocking.

jsulm

@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."

Ayush Gupta

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

jsulm

@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)?

Ayush Gupta

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.

jsulm

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

Ayush Gupta

Yes other app is non-gui console app.

It opens other GUI to show and process the data sended by non-gui console app.

But now I have to make my QT (DLL) in both headless mode (non-gui) and GUI mode in same DLL.

Actually QT (DLL) is simulator of system and the other non-gui console app sends the data to QT dll app and QT DLL app also send data to non-gui console app

SGaist

Can you describe exactly the architecture of your system ?
Because you are sending mixed messages here.
At one point you wanted to have an application that you could run either with GUI or not.
Now you have a console application that has some sort of DLL interface to drive an application and get fed by another one and one should support two different modes. That make everything unclear.

If you could add a drawing of your design, that might also be of great help.

Ayush Gupta

Here is some prototype I tried to draw

SGaist

As I already suggest, you really should consider using IPC rather making your console application drive a GUI application by hand which will make it not a console application. Apply the Unix mantra: one tool that does its job well.

See the various possibilities for inter-process communication. Missing there (fix under way), there's also QLocalServer/Socket.

Ayush Gupta

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

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.

console application I need to keep as it is since it part of system.

I need to work QT application (DLL).
So you mean here two launch core and GUI as two different process and make the code in seperate DLL?