How to simplify a complex item delegate?

[Adam Badura]

I'm waiting. Looks very promising. Those Delegate* types are your own, are they?

[wysota]

I'm waiting. Looks very promising. Those Delegate* types are your own, are they?

Yes, they are mine.

Here is the current state:

delegatelayout1.png

[Adam Badura]

How is this going? I got assigned back to the task at least for some time so I can now introduce improvements.

[wysota]

Are you interested only in the display of items or also about editing and interaction?

[Adam Badura]

Are you interested only in the display of items or also about editing and interaction?

Only display for now.

[wysota]

In that case I will post my current solution and provide a link to it during the weekend. You want to use it in a commercial project?

[Adam Badura]

In that case I will post my current solution and provide a link to it during the weekend. You want to use it in a commercial project?

I hoped I will not have to use it exactly as you did but rather get inspired how to do those things in Qt. But yes, it is a commercial project.

[wysota]

Well, I can tell you how I did it. I have a tree of items that models the structure of the delegate. Items in that tree are subclasses of "DelegateLayoutItem" which can be either subclasses of "DelegateLayout" (which currently can be just DelegateLinearLayout) or DelegateWidget that can be subclassed any way one wants (I have subclasses that offer text or image that comes from the model and static text or static pixmap). The basic idea is that each of them provides a sizeHint() implementation and a paint() implementation. Both of them take a model index and QStyleOptionViewItem instance. The rest is just to calculate sizeHint() down the tree for a specific index and item option and paint everything. Just like for regular widgets or graphics items. I don't respect size policies yet and I only respect right alignment for a vertical layout. There is no event forwarding yet but the same idea can be employed for it.

Here is a sample (not actual, I don't have the code with me right now) implementation of sizeHint:

QSize DelegateText::sizeHint(const QModelIndex &index, const QStyleOptionViewItem &option) const {
  QString text = index.data(m_role).toString();
  return option.fontMetrics.boundingRect(option.rect, 0, text).adjusted(-leftMargin(), -topMargin(), rightMargin(), bottomMargin()).size();
}

QSize DelegateText::sizeHint(const QModelIndex &index, const QStyleOptionViewItem &option) const {
  QString text = index.data(m_role).toString();
  return option.fontMetrics.boundingRect(option.rect, 0, text).adjusted(-leftMargin(), -topMargin(), rightMargin(), bottomMargin()).size();
}

To copy to clipboard, switch view to plain text mode 

and a sample paint:

void DelegateText::paint(QPainter *painter, const QModelIndex &index, const QStyleOptionViewItem &option, const QRect &rect) {
  QRect r = rect.adjusted(leftMargin(), topMargin(), -rightMargin(), -bottomMargin());
  painter->drawText(r, 0, index.data(m_role).toString());
}

void DelegateText::paint(QPainter *painter, const QModelIndex &index, const QStyleOptionViewItem &option, const QRect &rect) {
  QRect r = rect.adjusted(leftMargin(), topMargin(), -rightMargin(), -bottomMargin());
  painter->drawText(r, 0, index.data(m_role).toString());
}

To copy to clipboard, switch view to plain text mode 

[Adam Badura]

That is interesting! But how scalable is that?

Since now I'm facing a much bigger thing of similar sort. We have a list (QAbstractListModel) of channels. The main window shows those channels in a vertical list-like widget. It is not done as a real list. Just looks and behaves like if it was.

But since I'm reworking that piece of code (and its me who introduced that QAbstractListModel instead of custom structures in the first place) I'm considering making it... well... better. The issue is that channel widget is quite a complex widget. Multiple buttons, various modes (influencing what is show within) and so on. The original issue was a playlist which is basically one of three variants of what can be inside that channel widget (surrounded with other controls). Would your solution still be well usable in that case? Now it is not only lots of drawing but also lots of user interaction.

Also I already have .ui files (from previous version) covering the channel widget and all its parts. So not using that would be a waste somewhat. On a plus side we moved to Qt5 as well. Sadly QML is not much of an option (even thou I would lie to try it) mostly due to .ui files being already there.

[wysota]

That is interesting! But how scalable is that?

Hard to say. For ~15k items it takes some time to perform an initial layout but then I'm not noticing any slowdowns.

Considering that there is completely no optimisation, I think the speed is satisfactory.

Since now I'm facing a much bigger thing of similar sort. We have a list (QAbstractListModel) of channels. The main window shows those channels in a vertical list-like widget. It is not done as a real list. Just looks and behaves like if it was.

But since I'm reworking that piece of code (and its me who introduced that QAbstractListModel instead of custom structures in the first place) I'm considering making it... well... better. The issue is that channel widget is quite a complex widget. Multiple buttons, various modes (influencing what is show within) and so on. The original issue was a playlist which is basically one of three variants of what can be inside that channel widget (surrounded with other controls). Would your solution still be well usable in that case?

A general answer is "probably yes" but it depends on your particular usecase. As a last resort you can always use QtQuick.

Sadly QML is not much of an option (even thou I would lie to try it) mostly due to .ui files being already there.

I don't see how that's relevant. You can place a QQuickView (or whatever it was called) in a widget (see http://blog.qt.digia.com/blog/2013/0...ndowcontainer/) and have your list view implemented in QtQuick.

[Adam Badura]

Well, numer of items is limited, few I guess at most. Its only that each item is a complex widget by its own.

Is it possible to have an ordinary .ui based widget in a QQuickView?

[wysota]

Is it possible to have an ordinary .ui based widget in a QQuickView?

No, currently not. You'd have to convert your ui design to QML. Bearing the fact that ui files are xml, you could even write a tool for it.

[Adam Badura]

OK, so I guess this closes the topic at least for some time (until I will go deeper into implementation ).

But to finish it: how complex it would be, in your opinion, to make a class similar to Q[List|Tree]Widget that instead of keeping the model internal, would take external model and a delegate for creating item widgets? Having such a class seems useful for me since I already have the model, have the widgets and creating delegate is trivial...

[Adam Badura]

But to finish it: how complex it would be, in your opinion, to make a class similar to Q[List|Tree]Widget that instead of keeping the model internal, would take external model and a delegate for creating item widgets? Having such a class seems useful for me since I already have the model, have the widgets and creating delegate is trivial...

Now when I read that I think it should be simple. MyListWidget class would take MyListModel and MyDelegate. Then it would create ItemViewWiget for each item in the model (and in general keep in sync to it) and add it to its private QListWidget.

[wysota]

But to finish it: how complex it would be, in your opinion, to make a class similar to Q[List|Tree]Widget that instead of keeping the model internal, would take external model and a delegate for creating item widgets?

I'm not sure what you mean. It seems this is exactly what QListView, QTableView and QTreeView do.