Design pattern for GUI and NON GUI mode.
-
@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. -
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
-
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.
-
Here is some prototype I tried to draw
-
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.
-
@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? -
@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?@Ayush-Gupta Yes, starting GUI from console application makes it a GUI application. Look at what @SGaist suggested.
-
sorry it is so confusing for me.
I have to create a QT application (in both GUI and NON-GUI) mode.... and my QT application should be in dll which will launch by other console application.
So means creating two dlls for core and GUI and (core dll should launch) GUI dll ?
and in NON-GUI mode the core dll should not launch GUI dll?
and the commuincation between core dll and GUI dll will be using IPC?
-
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.
@SGaist Can you please explain a little bit more?
-
sorry it is so confusing for me.
I have to create a QT application (in both GUI and NON-GUI) mode.... and my QT application should be in dll which will launch by other console application.
So means creating two dlls for core and GUI and (core dll should launch) GUI dll ?
and in NON-GUI mode the core dll should not launch GUI dll?
and the commuincation between core dll and GUI dll will be using IPC?
@Ayush-Gupta your design is hopelessly broken and it won't work, you were told that many times (see above posts). And this is not Qt specific (on .NET platform it would be the same, for example). Actually, it could work in a "lite" version, but will break horribly later on, so please FORGET that. Please.
Please take time to learn about how GUI works in general (message pumps, GUI threads, ...). Completely unrelated to Qt, but studying Win32 API will make you understand A LOT. GUI thread is usually the "main" thread, OS-speaking, so do not mess with displaying GUI in a worker thread.
So, forget to have a "GUI DLL"; what you mean by this term has no sense whatsoever. Forget completely to have a "application DLL" (means the same as a "white black" or a "near place far, far away").
Let's recap:- You have an existing "console" application that can load a DLL, plugin-like.
- You want to exchange data between that application and some processing code, bidirectionally.
One (of many) solution is making a DLL that exposes a socket interface (you could go first by TCP, because is easy to make bidirectional and lossless) and then develop an application (which can run on its own process and do not ever know what application is talking to) that connects to that socket and exchange messages with the other application. You could look into other IPC (inter-process communication) means and select the most suitable for you, since we do not know what application you want talk to, what it does, and what data exchanges, neither we know what you want to do on the other side (headless/GUI).
Ah, completely forget updating the GUI every 25 ms with a retained mode GUI like Qt (or GTK, or WPF, or Windows Forms, or most GUI frameworks) on a "consumer" system. Your brain does not react so fast to structured information anyway.
And... better if you pretend threads do not exists. It pays off a lot.
