How to design Qt applications are better?

[FinderCheng]

I found most Qt applications are extends QMainWindow class and there are lots of QAction instances. So my question is how to design these QActions? Most starts' books put them into QMainWindow's subclass derictly, but when this application gets bigger and bigger, it is rather difficult to manage them.

Could you tell me how to design Qt applcations' code? Or some other suggestions? Or could you let me know some open source Qt applications' code to study? Don't tell me KDE because its code is so big that I hardly read it.

Thank you all!

[Lykurg]

I found most Qt applications are extends QMainWindow class and there are lots of QAction instances. So my question is how to design these QActions? Most starts' books put them into QMainWindow's subclass derictly, but when this application gets bigger and bigger, it is rather difficult to manage them.

But somewhere you have to manage them. So a QMainWindow is the best place for it. There you also set the connections up. A way for better managing is that you declare two functions: initActions() where you set up all the actions and initConnections() where you establish all the connections. Move both functions to the bottom of your file, then you don't "see" them.

Could you tell me how to design Qt applcations' code?

Like any other C++ program. Have a look at the examples and tutorials which came with Qt.

Or some other suggestions? Or could you let me know some open source Qt applications' code to study? Don't tell me KDE because its code is so big that I hardly read it.

Try KDE But of course not the whole, just pick up one application and study its code. E.g. Konqueror.

[axeljaeger]

I think it is a matter of personal taste.

I agree with you that the QMainWindow subclass is a good candidate to become the good object of a QApplication.

From the academic point of view, this is purely wrong because a window is a view class and should not contain any business logic code at all.

I suggest to put most code in QObject-subclasses and let these objects provide actions that you can put around in your mainwindow. The downside of this approach is that you cannot do it with designer.

An extra suggestion from me is to put most of your code in subclasses of QAbstractListModel or QAbstractTableModel if it somehow represents a list in any form, even if you will not it in a listview in the final gui. The nice thing about this is that you can attach a listview to it for debugging purposes instead of adding a lot of qDebug.

[FinderCheng]

Yeah, thank you all!
I was a Qt starter from Java coder. People always say "make clear layer" so try not to add logical business code. As a result I wanted to create a class "ActionManager" to manage all QAction instances. But in C++ applications maybe there are different. So thank you all again!
Any other suggestions? Thanks!

[axeljaeger]

What shall this action manager do? In the end, an action in Qt is a wrapper around either a property or a slot that adds a nice name and an icon. What do you want to manage there?

[FinderCheng]

I've no idea. I want to put all actions there, such as a map, the then it can get by its key. Then in this class all action connections are connected so simply gets out.

[axeljaeger]

So this class will have EVERY other class of your application as a dependency? Because it has to know all the objects that are receiving signals. This is not a very modular approach.

[FinderCheng]

Yes, it seems it has to know all classes who need to use QActions. So it may a friend class of these classes. It is not good design. Or you can make a lot of signals and slots between these classes, but I think this makes it too complex. So what's your opinion? Where should these QActions put? QMainWindow's subclass is a good place? I'd not quite follow your post hours ago.

[axeljaeger]

I would not put all QActions in a single place.

ATM I'm developing an application that does light control.

It has a number of components, for example the component that talks to the hardware. This component provides a QAction connectAction that I can use anywhere else. Because my hardware controller owns that QAction, it can uncheck it when I plug out my hardware.

Let each component provide their actions and then use the mainwindow just to put the actions somewhere in the GUI.