[Qt-interest] QVBoxLayout with 100s of items is hanging

[Qt Quest]

Hi André,

Yes! At first I didnt see that KWidgetItemDelegate uses the pool (and not the other way around). I built a demo application which is working - Thanks!

I'm noticing few things which are disturbing:
1. Allocation - for every row createItemWidgets() is being called which takes a lot of time and memory.

2. Continuing point 1 above: It takes a lot of time to draw the list:
100 items: 0.5 sec
1000 items: 8 sec
10000 items: 60+ sec
I've put counters in the create..() method and it is indeed called for every row.

I'm sure we can cut the processing time considerably. 
I'm thinking of reusing the shown widget for all the 100s of lines (e.g. 2 widgets * 30 visible lines = 60 widgets created only once).
What do you think?
Thanks!




________________________________
From: Andre Somers <andre at familiesomers.nl>
To: Qt-interest <qt-interest at trolltech.com>
Sent: Fri, November 27, 2009 2:32:28 PM
Subject: Re: [Qt-interest] QVBoxLayout with 100s of items is hanging

Hi,

Qt Quest wrote:
> I like the solution of real widgets as with KWidgetItemDelegate. I've 
> downloaded the code and also found a test code for that class. 
> However, I do not understand how the methods of it are being used, 
> specifically createItemWidgets() and updateItemWidgets(). Who calls 
> them and when? I saw a class named KWidgetItemDelegatePool which calls 
> these protected methods but the test application does not use it. So 
> my question is how do these widgets end up being drawn?
The nice thing is: that is not your concern! The delegate pool works in 
the background for you.
Simply subclass KWidgetItemDelegate, and reimplement createItemWidgets, 
paint, sizeHint and updateItemWidgets.

In createItemWidgets, you simply create a single QLabel and return it. 
Also, hook up any signals there. In my case, I created a private 
linkActivated slot in the delegate (you can, it is a QObject derived 
class!), did some small work on the custom link, and emitted my own 
custom clicked signal. I hooked up this slot to the QLabel's 
linkActivated signal.

My paint reimplementation just takes care of the palette in case the row 
is selected, and then calls KWidgetItemDelegate::paintWidgets. The 
sizeHint is trivial in my case, I just return a fixed size hint.

The updateItemWidgets is the most important one. Here you set the 
contents for the widgets, in your case your label based on the model 
index. Cast the generic QWidgets you get to the QLabel you created 
before. I my case, I am constructing the simple HTML there, and set it 
as HTML on the label using it's setText method. Preso!
>
> BTW:
> At first I did have one big HTML but it was very unnatural delving 
> into HTML related interaction (forms and scripts) instead of GUI 
> controls interaction (clicks and checks).
> Therefore I abandoned it for QCheckBoxes and QLabels.
Pitty, it's really not that difficult. You can insert a QObject into 
your page's JavaScript environment. Give it a slot that accepts an 
appropriate key. Then you can use the checkbox's onClick event to call 
this slot, and you have your handling back in Qt.

Anyway, it was just a suggestion. It saves you from the headache of 
getting real widgets to work properly in an item view.

André

_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091127/f5bb2ef2/attachment.html