How is de-GUI a complex C ++ / Qt4 application related to tanglewad?

Question

We have a big dirty application written in C ++ and Qt4, a lot of library dependencies, hundreds of classes and the lack of a consistent structure. Usually it starts as a graphical application that interacts interactively, but sometimes it starts in manual mode from another program that passes command line parameters and communicates with it using dbus. The GUI still shows, but no human or trained monkey can click anything. "Relaxen und watch das blinkenlights" In the interactive or automatic mode, when the application starts, image files are recorded.

My work in the next few weeks is to add the "no gui" function, so that the application can run in hands-off mode and write its own image files without even having to display its graphical interface. Internally, the images to be recorded are created using QImage and other objects other than the Qt GUI, but they have other objects that include the Qt GUI classes. After several attempts to figure out the clutter, I can't find a way to unravel things like an image-creating application without fully launching the GUI. At one time, I was hoping I could just set xxx.visible = false; for all xxx that are GUI objects, but this is impractical or possible (AFIK).

Are there any general strategies for adding this no-gui function to this application? Some technique that does not require a deep reorganization of the class hierarchy?

Answer 1

A long and difficult way is to figure out what and how logic is executed, extract the logic into some QObject based classes (with signals and slots) and make this a QtCore application. I know that this does not help, but that the path is correct .

If setting all GUI elements to hidden (or maybe just QMainWindow?) Is not an option, this is the only thing you can do.

Qt allows you to do this, but if the source encoder did not plan it, you have a lot of refactoring / transcoding.

Answer 2

It really depends on how the program is written. If the logic is somewhat separate from the interface, then it can be as simple as figuring out which class is inheriting from the QMainWindow class and making sure it is never initialized.

In the case where logic is everywhere, I highly recommend trying to get all the logic in the form of a signal or slot (which probably already happened, given that this is a GUI application), then just do not initialize the QMainWindow instance and call them manually.

Answer 3

Try subclassing the interface classes (QMainWindow, QDialog, etc.) and implement your logic there.