Qt for thin GUI client
-
Background:
I have an old M&C product I created in Borland CPP Builder and sold years ago with systems still in operation throughout the world but have not done anything with it in more than 10 years after pivoting to HW control system products and then eventually shutting down my company and going back to work in the corporate world working as a product/program manager. Due to corporate downsizing I recently got laid off and decided I would spend some time looking at bringing my product out of retirement, refreshing it a bit, and seeing if there is a market for it. My first goal is to investigate changing the GUI architecture a bit and porting it to a different framework/toolkit as I do not want to be handcuffed to the Embaradaro/Borland echosystem any longer. Having played with QT years ago while initially looking at porting my application off of the Borland product and revisiting QT for the past couple of weeks am confidant that QT Widgets would meet my needs without too much effort and pain but now am wondering if there is a better route to take and am asking you all for you feedback/suggestions on this. I have not done ANY SW development for more the 5 years and for the prior 5 years I was strictly doing embedded c programming form my custom HW products so my Desktop SW Development skills are severely degraded, but are coming back quickly, and I have zero experience in web based languages such as HTML, JS, an CSS.
For reference, the architecture of my current design is client server based with a monolithic GUI (written in BCB Bulider) that connects to a middle-ware process/server written C++ that acts as a message passing conduit between the GUI and all the device drivers for the system. The device drivers are individual processes (C++) that communicate with various external HW devices (via Serial ports, SNMP, TCP, Telnet..) and interface with the middle-ware sever via shared memory.
Goal:
My end goal is to change the GUI architecture and move all the business back-end logic and functionality out of the GUI to the middle-ware server and end up with a thin-client type of GUI where multiple GUI clients can connect to the system (middle-where). I want the solution to be designed from the start with high performance as a top priority as I believe it is good practice to start this way to avoid having to address possible performance issues down the road after the product has been put into service. I guess this is the embedded programmer in me. I do not want to move the GUI to a pure HTML web based solution where the GUI is simply implemented as web pages running in a browser.
Question for the Community:
As stated above, it looks like I can do what I want to do in QT Widgets, but am wondering if there is a better, more appropriate path to take and would really appreciate any and all feedback the community is willing to provide. I know the following possibilities would push me out of the QT echo-system, so this may not be the most appropriate form to ask these questions, but I still plan on possibly porting the middle-ware and device drivers to QT. Some other possible options such as Electron or Tauri look interesting, but having zero experience in web based application development gives me pause as this is not an exercise to learn a bunch of new SW technologies to upgrade my SW development skills to better position me to reenter the job market as a SW engineer, this is simply an effort to see if I can refresh my product that has over 20 years of proven field operation reliability with minimal effort and then see if there is a market for it.
Thanks in advance for any and all feedback you all can provide.
Cheers.
-
Hi,
Your target architecture sounds fine so I would say go ahead. One thing that I would do as a first step is to get a test project up and running with as much as possible your current architecture so you can acquire a better grasp of what should really be moved and what could stay close to your GUI code. That way you won't be attacking two different fronts at once.
Disclaimer: I am not trying to sell anything. The following are commercial products but they seem to be something worth investing some time to check.
Depending on what you want to use as thin client and the constraints you have, you might want to check the Qt Company offerings like Boot2Qt and the Qt Safe Renderer.
Something else that might also be of interest is KDAB's courses/articles/OpenSource projects. They have quite an extensive knowledge that you might find interesting for your projects.
Hope it helps
-
@SGaist
Thank your for your response, I will definitely check those options out.What are your thoughts on using Widgets vs QML giving my product type and the fact that this is a full fledged desktop application without the need to target mobile devices such as tablets?
One this I forgot to mention is that cross platform capability/compatibility (linux, Mac) it not really a requirement, though it would be a nice option. I have be in many customer, both commercial and government, facilities, and have never seen GUI clients running on anything other than Windows. Yes, for personal systems, but not for commercial products like this one. I'm sure there are cases, but my guess is that it is rare, so Windows is my initial target platform.
Thanks again
-
On the widgets VS QtQuick, if you want to implement fancy animations, you should go with QtQuick. Otherwise, widgets have a pretty long history of working well (there are bugs, let's be lucid but the technology has been proven) so if you have everything you need there, go for it. The Qt Graphics View framework is also something you might want to take a look at. Note that you can integrate QtQuick elements in a widgets application so you can combine the best of both worlds.
Even if you only have Windows customers, building for Linux and macOS can sometime help you unearth some bugs and issues in your code (beside the learning value).
-
@visinet said in Qt for thin GUI client:
I want the solution to be designed from the start with high performance as a top priority as I believe it is good practice to start this way to avoid having to address possible performance issues down the road after the product has been put into service.
If this means focusing on data spatial and temporal locality, minimizing copying, structuring of independently computable tasks, and similar, then yes, apply those practices.
If it means explicit parallel execution and writing clever but inscrutable code, then the conventional wisdom about premature optimization applies. A reliable source of requests for help here involves unnecessary use of threading, and attempts to perform calculations or communication as fast as possible for results that are not externally visible.
-
If you want to have multiple GUIs running on different computers you'll have to separate the application logic from the GUI and have a separate process running for the GUI which connects through TCP or something similar. Qt can help you out with this.
I haven't had a need for QML so far. In some environments people prefer the trusted old Windows look they are used to. If you want to target younger customers QML could help to get a fresh looking GUI. But, it also means you should have a UI designer who understands his job.
There is another (non-Qt way) to go the web route without actually having to do any proper web programming. There is Wt (https://www.webtoolkit.eu/wt) which initially borrowed from QWidgets (just like Qt is supposed to be pronounce "cute", Wt is supposed to be pronounce "witty"). You just write a plain old C++ program (very similar to Qt) which will serve HTML and JavaScript for browsers to connect to. Only downside is that besides the commercial license there is only the GPL and no LGPL!
-
@SimonSchroeder Thanks so much for the suggestions everyone, I truly value the input from others that are most definitely more talented than myself.
