You are here

A Cry for Help: Combining GraphicsView and Interview

Background Info

My Summer of Code project is to spruce up the playlist. My idea was to use Qt's new Interview system to make Amarok more memory efficient and less laggy even with large number of tracks in the playlist - performance of Amarok 1.x suffers noticeably with large playlists. This has largely worked out well.

To make the playlist look good I decided to use GraphicsView. So for the past month I've been using QGraphicsScene to paint the items in a QListView using a QAbstractItemDelegate subclass. The subclass overrides the ::paint method, which provides a QPainter. I send the painter to QGraphicsScene::render and it paints the item.

The problem

What I've come to find out is that QGraphicsScene render is really meant for printing, not for screen display. Since (you might have noticed) there's no QGraphicsView involved, there's nothing to translate normal QWidget events into their GraphicsView counterparts. After looking at qgraphicsview.cpp, I found it wasn't hard to simply put that sort of functionality into QListView. So currently double clicking works in QListView and you can initiate edits this way.

What initiating edits has made quite clear is that there animation's do not work (the cursor doesn't blink), and unlike with the event-translation issue, there is no clear solution. Without a QGraphicsView and with Delegate's simplistic painting system (which is all-or-nothing) I don't see how to do it easily.

Possible Solutions

Widgets Everywhere

Using some hack or another (setItemWidget, abusing the editor widget stuff, dark magic) I could make each item on the playlist a widget. Andrew of Skype (who attended aKademy) apparently has similar issues (wanting to use Interview, but with interactive custom widgets which you can see if you use Skype). He made it pretty clear to me that this was a life-sucking endeavour. It also has obvious efficiency issues... playlist items can't be QObjects due to memory issues, let alone QWidgets (though if there was some smart way to only have 100 qwidgets at a time that would work).

Overlay Editor Widget

Somehow overlay a text edit line just over the text that the user is editing. No idea if this is possible. And it doesn't allow any other animations to be used.

Pixie-dust the delegate or QListView to display the animations

Under the current regime, somehow let the delegate or the QListView know when and where it needs to repaint the QGraphicsScene to show the animations.

Replace QListView with a QGraphicsView

...and implement everything that QListView does in a QGraphicsView subclass. Really this is what I'm leaning towards at the moment. This would be very similar to what the Drill Down Example does, except with 100x the data.

One of the main benefits of Model/View is that it only has in memory the data being displayed. It doesn't really store any data, on every paint operation the View asks the Model for the data. I really don't know where to start on replicating this sort of functionality in QGraphicsView. Would I just constantly delete and add items as the user scrolls?

I would appreciate any suggestions. :-) Whether its something (else) I've missed or how I would go about implementing the last solution.


Seb posted my blog to get feedback from the Planet KDE crowd.