Qt thinking - pointers?

[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) http://www.slideshare.net/YnonPerek/...atterns‎

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?