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

[Qt Quest]

I want to clarify that the createItemWidgets() is called for all the rows in the list instead of all the visible rows, as it should have.

Here's the main function of the app. The whole example was taken from KDE test code, and simplified for my task. Maybe I'm doing something wrong here...

 
int main(int argc, char **argv)
{
QApplication app(argc, argv);
QMainWindow *mainWindow = new QMainWindow();
mainWindow->setMinimumSize(640, 480);
QListView *listView = new QListView();
QStringListModel *model = new QStringListModel();
model->insertRows(0, 10000);
/*	for (int i = 0; i < 10000; ++i)
{
model->setData(model->index(i, 0), "Test " + QString::number(i), Qt::DisplayRole);
}
*/
listView->setModel(model);
MyDelegate *myDelegate = new MyDelegate(listView);
listView->setItemDelegate(myDelegate);
listView->setVerticalScrollMode(QListView::ScrollPerPixel);
mainWindow->setCentralWidget(listView);
mainWindow->show();
//    model->removeRows(0, 95);
return app.exec();
}




________________________________
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/7ea8e31c/attachment.html