Qt thinking - pointers?

[turboscrew]

It seems that the time has come for me to start thinking QT things, so as a QT-newbie, but old fart in programming I'd like to ask:

Any pointers to writings on thinking QT - the paradigm?
Something about what kind of architectures are preferable within QT community.
I understand that QT is "advertized" as good framework for event based systems. Why, How?
Are there generally accepted ideas of basic patterns? (Like in C#/WPF it's almost always MVVM).
What should the main function do? The main work or almost nothing?
...
(I hope you get the picture.)

Also, is there a good technical overview about what QT is made of and how it works?

[aamer4yu]

Firstly, its Qt and not QT :eek:

Secondly you can go through http://qt-project.org/resources/getting_started
The most important things to know about Qt are -
Signals and Slots
Object trees and ownership.

Rest if you are familiar with C++, you should sail smoothly :)

[turboscrew]

Thanks - I'll have a look there.

[turboscrew]

Hm, those pages don't seem to give any ideas about "good" program structures.

Does anyone know any SW architecture related material?
(Which way to think about the SW to be implemented using Qt.)

[aamer4yu]

Qt is C++. So any pattern for C++ application should also work with Qt.

Additional links you can browse more are as follows -
1) An Introduction to Design Patterns in C++ with Qt 4 [ Google for this book ]
http://www.ics.com/design-patterns

2) www.slideshare.net/YnonPerek/qt-design-patterns‎

[toufic.dbouk]

An Introduction to Design Patterns in C++ with Qt
A Great book, went through it at my university class. Its really helpful.

[turboscrew]

Qt is C++. So any pattern for C++ application should also work with Qt.

Additional links you can browse more are as follows -
1) An Introduction to Design Patterns in C++ with Qt 4 [ Google for this book ]
http://www.ics.com/design-patterns

2) www.slideshare.net/YnonPerek/qt-design-patterns‎

Thanks. Part I chapter 8 on. The rest seems to be general C++ (and O-O).
Although, not so sure about the "Qt thinking"-part.

BTW, with "Object trees and ownership." you mean the "parent-relation"?

[aamer4yu]

BTW, with "Object trees and ownership." you mean the "parent-relation"?

Yes, Its the parent child relation . This provides a semi garbage collection like system where you don't have to delete all the child objects individually, but if you delete the parent then all the child objects will be deleted automatically. :)



Although, not so sure about the "Qt thinking"-part.
Yes, I don't think there is a book for that. And with Qt 5, I wonder if developer days are the best thing to follow to learn and think in Qt :-)

May be discussions and real life problems will help understand the Thinking in Qt part :)

[turboscrew]

Yes, I don't think there is a book for that. And with Qt 5, I wonder if developer days are the best thing to follow to learn and think in Qt :-)

May be discussions and real life problems will help understand the Thinking in Qt part :)

It's just that lerning by induction is slow - the details need to be many. And not all of them are done by
knowledgeable programmer... ;-)

[turboscrew]

More concrete case:
I’m writing a simple external device commander that “discusses” with the computer via serial port.

There are two kinds of commands: simple one line commands and a bit more complex multiblock commands. A block is some hundreds of bytes long. Simple command is just a couple of tens of bytes long.

Is it good idea to have mainwindow to handle the UI, simple commander, block commanderand a device specific serial handler (using the QSerialPort)? Later on, the UI will be dropped and the rest is to be moved into a “subsystem” of a bigger whole.
The mainwindow has slots of all “command sending” widgets (mostly buttons), and when a command is sent, it gets data from other fields (command parameters) and sends the bunch to the appropriate commander, that handle the command and “code” them using the device specific serial handler.
The mainwindow has “command signals” and “response slots” and so do the command handlers and the device specific serial handler.
The mainwindow ties the “command signals” and “response slots” together, except that the device specific serial handler connects its “command signals” and “response slots” with the QSerialPort stuff.
Is that an OK structure? Am I overusing/underusing signals/slots?

How about handling ACK-messages? Those can come for both simple and multiblock commands. Is it better to use a flag for routing the ACK to the appropriate commander, or is re-connecting signals/slots between the device specific serial handler and the appropriate commander a preferred way?