Anatomy of a Qt "Buddy List" - Am I on the right track architecturally?
For days I've been battling with Qt, Models, Views, Delegates. I have a long way to go but at least I wish to know that architecturally, I am on the right Track. If you can comment on that, you're more than welcome.
A Scrollable Buddy List, similar to what Skype has. The following requirements must be supported:
complete control over the drawing of each row. Typically, Icons of variable width based on status of the object represented by the row.
Variable height for rows, typically, more detailed row display for the selected row.
Added controls for selected rows (action buttons).
Full control over the sorting of the list
different types of rows typically, a buddy or a textual placeholder with a label indicating the type of buddies directly under it (e.g. "offline contacts", "online contacts").
My thoughts were as follows:
Use a QListView for the listview control Use a derived
QAbstractList model to hold the buddy data. It will have an std::vector array with a collection of "MyContactClass". Each "MyContactClass" instance will represent a buddy, with its related data fields
Use a QAbstractItemDelegate derived class to handle the painting and sizeHinting of the rows
Hook up the model and delegate to the QListView
populate the model...
Have the QListView populated
I understand there are many details to this and it's not trivial at all. What I wanted to ask you is: Are items #1 to #6 correct architecturally given what I'm trying to do.
You should also consider using QML along with a ListView element. This will likely be easier for you to customise the appearance. You can still use the same C++ based list model. Take a look at the QML docs and examples. I think you will be pleasantly surprised just how quickly this can be done.
tobias.hunger last edited by
Sounds sensible to me. Just one hint: If you are going for lots of entries in the list then having a fixed row height will speed up processing quite a bit as the view does not need to access all previous elements to find the y-position of an element of the list.
As Tobias said your proposed approach is perfectly reasonable. The decision between whether to use a QWidget-based view like QListView with a custom delegate or to use QML in a QDeclarativeView will largely be based upon how much bling you want to add to your buddy list. For example do you want the delegate to expand when a user clicks on it to show more information and as it expands to be nicely animated? If so then QML excels at this sort of thing. It is possible to do this in a QWidget type solution but it will be a lot more work.
If you want a fairly static list (ie few or no animations) then go with QListView. If you want something more dynamic then go for QML. Either way the model on the backend stays the same.
That is actually a good suggestion by ZapB. Note that you can do this without making your whole application a QML app. It is possible to create custom widgets based on QDeclarativeView that run QML inside them, but can be used like any other widget in the application.
Yes that is what I was trying to get at. Many people still seem to think that it must be all QML or nothing whereas of course as you know it is perfectly possible to mix and match as needed.