A Cry for Help: Combining GraphicsView and Interview
July 30, 2007 – 3:04 pmOne of the Amarok developers, Ian, has run into some trouble in his summer of code project for the summer. I’m posting a copy of his blog at his request to reach a greater readership. Please, lend your eyes for just a minute!
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.
Thanks!
11 Responses to “A Cry for Help: Combining GraphicsView and Interview”
Ok, so the problem in qtcentre regarding listview animation was related to amarok! I don’t have any solution at the moment but someone might help in the forum. So here is a link to ian’s post for your reference
http://www.qtcentre.org/forum/f-qt-programming-2/t-animations-in-interview-delegates-8304.html
By Gopala Krishna on Jul 30, 2007
I’m really not very familiar with QT (yet), so take this with a grain of salt…
It would seem that QListView ( well, all of the view classes) don’t really need to know anything about the items they’re displaying, except for those visible, and dimensions for those that are not ( so the scroll position/size can be set )…just before the user scrolls an item into view, it can ask the model about it ( and delete the objects going out of the view)
This is how I expect the “virtual” mode of the Win32 listbox works ( check out LVS_OWNERDATA here http://msdn2.microsoft.com/en-us/library/ms670558.aspx )
By tony on Jul 30, 2007
Hi!
As somebody who has taken the widgets-in-view way once, I can tell you what you have to do for that - you just put your widgets into the viewport() of the QListView and you have to handle all geometry changes yourself, probably in QItemDelegate::paint(). You could probably find a way to kill invisible widgets, but I suspect it would still be slow.
Or use the “Overlay editor widget” approach (it’s quite a standard way to use editor widgets!) and use a pixie-dust delegate to implement little icons in the view and limited animations like the “currently playing” animation in Amarok 1.4. You can get your instructions where and how to apply the pixie dust from the model using custom roles, to keep up the model-view-delegate pattern
Oh, you need to find a way to periodically repaint (for animation) - maybe using a clever hack with a frame timer in the model? You can probably send repaint events only where animations are going on, by setting a new value for something (e.g. tint color - a custom role) in the animating row.
QGraphicsView also looks good, although I have no idea how easy it is to implement arbitrary user interaction there.
I’d favor the pixie-dust delegate way of doing things although it’s somewhat limited. So what, it’s a play*list* you are implementing and not a game
*Do* have a good look at QGraphicsView either and ask some people who know more about it.
By Andreas on Jul 30, 2007
Look here:
http://trolltech.com/company/newsroom/events/allevents/devdays2006/videolinks
The ‘Advanced Item Views’ presentation…
By Ivan Čukić on Jul 30, 2007
QAbstractItemDelegate’s createEditor() and associated functions are there for overlaying editor widgets… you can set their geometry through the QStyleOptionViewItem parameter. It’s not clear from the post what the problem with this would be… you reference “abusing the editor widget stuff” in one paragraph and then wonder whether editor widgets are even possible in the next?
By illissius on Jul 30, 2007
illissius - Using createEditor to put widgets everywhere (eg whether stuff is being edited or not) would be abusing createEditor. Using createEditor to create a line edit wouldn’t be abusing createEditor obviously, it would just be limiting.
Ivan Čukić - thanks! I’m going to watch that after writing this comment. I didn’t realize they had all those presentations online, thats awesome.
Andreas - well I could just brute force with a timer connected to a repaint operation and actually get animations right now. I just assume it’d be slow since I can only paint the whole delegate at a time (like QGraphicsScene has a signal where it tells what needs to be repainted I think, but this information would just be discarded unless I’m missing something.). But thanks for your comment, it has me thinking about a few things…
Tony - yea, I’m looking for someone perhaps with experience doing something like this.
It sounds like a fine idea in theory.
By Ian Monroe on Jul 31, 2007
As far as I can tell from the post, the problem was that the cursor in QGraphicsScene editors isn’t animated, which using createEditor() would solve… I gather there’s something else you want to accomplish which this doesn’t let you, but I don’t think you’ve mentioned it (or I’ve failed to notice it).
Also, “Somehow overlay a text edit line just over the text that the user is editing. No idea if this is possible.”, is the bit which confused me. Isn’t that exactly what createEditor() does?
By illissius on Jul 31, 2007
Yes I would like the ability to do other animations in the future.
createEditor probably overrides the whole cell, which given that I only have one cell per row, that wouldn’t work out well. But maybe I’m wrong.
By Ian Monroe on Jul 31, 2007
I have some code implementing the beginnings of MVC classes for QGV as I was going to use them for certain parts of plasma. However, the first big thing you are going to run into is the glaring lack of a ported scrollarea for QGV. You’re talking about dealing with a bunch of items, but you’re quickly to going to note that you can’t even fit more than 10 because you can’t scroll! However, once you implement this, we effectively have all the tools you need. Let me know if you’re interested in doing it.
By Matt Broadstone on Jul 31, 2007
“createEditor probably overrides the whole cell, which given that I only have one cell per row, that wouldn’t work out well. But maybe I’m wrong.”
You can (must? can’t remember) set the geometry of the editor manually, so there’s nothing to stop you from overlaying it just over the actual text. (which is what I did in Krita)
By illissius on Jul 31, 2007