In recent years the graphics capabilities of desktops and handhelds have been growing more rapidly than their central processors. This is a revolution that is being accelerated by animating user interfaces. This in turn is based on the fact that you can make more usable and more attractive user interfaces using animations.
Qt has been steadily working on solutions that allow more dynamic user interfaces and animations for core features to actually use this available graphics power. Providing support via a framework like Qt sets a baseline and thus allows developers to create usable apps faster.
In Qt this all started with QGraphicsView and we are seeing a coherent vision progress steadily. And now its time for itemviews to be looked at 
Itemviews is the collective name for the widgets that show lists, tables and trees. Qt4 has a solution for these widgets already, which works fine for a large set of usecases. There are also usecases where they lack somewhat. Dynamic and fluid user interfaces are a major part of that.
We have started a research project to address all these shortcomings and provide a solution that makes it easier and faster to make beautiful and usable lists, tables and trees. In this blog I want to give an overview of what we have done and what our plans are going forward. Additionally we have put our research project online for everyone to download and play with.
Who is it for?
At this time of development we focussed on great design, good APIs and making easy the common usecases and possible the complex ones. For this reason there will be missing concepts, broken features and in general things may just fall apart. You have been warned
Who we are looking for are developers that want to kick the tires or our new baby, especially useful are developers that have specific usecases in mind of lists and tables that are a challenge to do in the Qt Itemviews. Having running examples build on top of the ItemViewsNG will help us a lot going forward and it will shape the direction we are going.
The actual repository where we work will be public and so people can just follow our progress as we go but we also encourage developers to contribute their patches back to our main repo.
Design
For the next generation of item views, we choose to use QGraphicsView concepts. The obvious advantage is reuse of concepts and features. 
If you look at the simple list example the individual list items (each row of text, really) is an individual graphics item (QGraphicsWidget, specifically). GraphicsView has various features that are very useful for us. It is very cheap graphics wise to move around the individual items, for example. This allows animations of individual items to use hardware acceleration automatically. GraphicsView also gives us features like being able to click on an item and that item having code to handle it so you can just use the existing concepts and code for making your individual items be drawn and behave the way you want. For old-graphicsview coders; this mirrors the concept of delegates in many ways.
All this talking about graphicsview may raise the question on how to integrate this with traditional user interfaces with QWidgets. A good question, and we created specific widgets for each of the 3 types of item views with proper defaults and simple to use APIs. These are the QtListWidgetNG, the QtTableWidgetNG and the QtTreeWidgetNG. These widgets come with several replaceable components that make it easy to change the look or the interaction separately and so mix and match to your liking.
Let me focus on the QtListWidgetNG here; behind the widget are various classes worth mentioning;
- The QtGraphicsListView allows customizers to decide how to show the individual list items. The default class uses separate graphics view items which has the advantage that we can cheaply animate them.
- The view decides which items to show by asking the QtListModelInterface. As the name states that is just an interface and thus has no implementation. We provide a simple implementation as the QtListDefaultModel.
- All the communication goes via the QtListController class. This includes things like handling keyboard and mouse input received by the QtListWidgetNG but also things like when the active item in the list is changed for some reason then the scrollbar moves to the correct position.
In the ItemViewNG repository today you will find several implementations of at least the listview which allows for an easy way to customize your list.
Here are some usages;
// Simples case; show a complete list
QtListWidgetNG widget1;
widget1.defaultModel()->appendItem(new QtListDefaultItem("Simple!"));
widget1.show();
// Use an alternative view that shows the items as
// icons in a flow and we also use a custom model here.
QtListWidgetNG widget2;
QtListController *controller = widget2.controller();
// custom model comes from the iconFlow example.
controller->setModel(new IconsModel(controller));
controller->setView(new QtGraphicsFlowView());
widget2.resize(QSize(240, 200));
widget2.show();
I started this blog stating that we created the new itemviews based on the idea that we needed pretty user interfaces, and here I am pasting code and showing really boring and standard widgets So lets show a bit more action; I made a screencast of the photoAlbum example that we made on top of the itemviews.
The demo (source-file) really shows a list of images quite similar to the boring list screenshot above, only instead of using the default QGraphicsListView we use a tweaked one to show the items vertically and almost full screen.
Next to that we changed the controller to a QtKineticController which provides the scrolling and flicklist behavior.
Where is it again?
On gitweb/labs.
You’ll appreciate the API docs too. Both are very clearly unfinished as this is research-in-progress!
Compilation requires Qt4.5 (works fine) or the kinetic branch (for some extra functionality, like the photo album).
Lets see who makes the coolest usage example list based on this 
Possibly related posts:
22 comments
Very cool! That last example looks similar to my tests with having some animated panes. (See http://blog.chatonka.com/AnimatedPanes.ogv ) I’m using the Qt Animation Framework (which is wonderful, I can’t wait for Qt Kinetic). It’s kind of hard to see when I’m holding down the mouse button and when it’s released and the applet is animating, but I hope you get the idea.
Hi Thomas,
Thanks for posting the code. We’ve explored most corners of the item/view framework whilst building Mendeley (www.mendeley.com) and for me there are two major limitations in the existing framework which we have worked around:
* Lack of support for efficient rich content rendering. On the web it is really easy to build a list of items containg text with varying fonts and sizes, icons, pictures etc. This isn’t so easy to do in Qt desktop applications. The default delegates give you plain text and an icon. It is possible to use QTextDocument to render more interesting output using a custom delegate but QTextDocument::fromHtml()’s poor performance makes this quite difficult. Using QTextLayout requires a lot of code for something ‘simple’ as does using QTextDocument/QTextCursor to construct the text. The ability to construct and lay-out items with QGraphicsWidget and friends would solve this.
* Lack of support for interactive items. The current model assumes that each item is either in a ‘display’ mode or an ‘editing’ mode. Again on the web, it is easy to have clickable links and icons displayed in items along with inline editing controls, picture flip-books, videos with playback controls etc. QTableView, QTreeView do support assigning a widget to an item but this obviously doesn’t scale to thousands of items.
At the moment we addressed these two issues with a custom HTML -> QTextLayout parser and an item delegate which bolts on support for interactive items to the existing QAbstractItemView-based view widgets. KDE has various classes to support widgets in item views and interactive features throughout its applications – all having varying states of completeness. It would be great if Qt could do this out of the box.
So yes – I’d love to be a guinea pig for a new item view framework
@Robert the two points you write should indeed be much easier to solve using existing Qt classes already; the QGraphicsTextItem for rich text and other items for more content (buttons/icons etc) is certainly something we have been thinking about and the current model should allow.
We have not actually put much time in creating such examples and I would be interested in seeing how the hold up with our current codebase so someone just has to delve in and spent some time writing those.
QtListModelInterface::itemsMoved [signal]
’nuff said.
/me applauds and wishes this would go into Qt 4.6 QAbstractItemModel, too
QtFooBar instead of QFooBar? is there a naming convention change happening (for future classes)?
@Marc
@Anon these classes are published on Labs and are not yet part of Qt. Until they become part of Qt we use a different prefix to avoid any naming collisions for people using these classes.
Hey, that are very cool news. Currently we think of a new project in our company which very likely would benefit from the next generation item views.
Have you ever thought of making the whole view-thing a graphicsitem itself? So multiple list, table or tree widgets could be used together in one graphicsscene.
E.g. if you make a “QtGraphicsListItem” (or however you want to call it) which contains the whole logic of the current QtGraphicsListView, one could easily build a convenience QtListWidgetNG which just contains a standard QGraphicsView with a single QtGraphicsListItem (the current QtGraphicsListViewItems whould then be renamed to QtGraphicsListItemItem
). Additionally this would enable the combination of multiple list, table or tree views in one and the same scene (which would be very useful for us then and maybe for others) and e.g. easily put them into QGraphicsLayouts or animate them.
So far, thats just an idea. I’ve not looked into the concept too deep, so please don’t blame me if I misunderstood something.
@Mark, yes thats a great idea
And we actually did exactly that. See http://doc.trolltech.com/itemviews-ng/src/classQtGraphicsListView.html
@Thomas
Something else I remembered. QAbstractItemView currently provides two scroll modes – scroll per item and scroll per pixel. The first can be both confusing and not attractive. The second requires measuring every item in the view – which doesn’t scale unless every item is the same size and the view can be told this. If the items are QGraphicsWidgets which have to be re-layed out whenever the QModelIndex they represent is changed this will get worse.
I’ve been wondering if there is a way to combine the advantages of both modes in a way which would work in the common case when the items are all the same size or are all similar but not exactly the same size. For example, the scrollbar range and position would be set based on the row count as in ScrollPerItem but when scrolling the view gets the height of items just above and just below the current view and uses that to do smooth scrolling as in ScrollPerPixel. In the case where items have different heights, the scrolling speed would change slightly relative to the amount of movement of the scrollbar as you scrolled up and down but I think the effect would be fairly subtle.
So, if I understand correctly, our old, carefully crafted models can go to the scrapheap if we want to use these new item views? That would be a real shame. Don’t get me wrong: I think a more flexible view implementation that allows for animation and interactive widgets is sorely needed, but I would hope we would not have to scrap our existing models to use them.
@Andre there are adaptor classes that I think takes care of letting you use existing models.
I blogged about my experiment with this code here if anyone is interested: http://kdedevelopers.org/node/3932
In a icon view it’s easy to implement indexAt() in constant time because items are laid out in a grid. To layout, you take a region and compute which item is in this region.
In QGraphicsView per se nothing is known so indexAt() is a challenge. To layout, you tell every item where its place is.
What is the situation for IconViewNG?
Imagine an IconViewNG where items are dancing around when animated but are still basically in a grid.
If you now go and have an individual item per entry, and require a relayout of every single item because the window is resized – does this take O(n) or have you played clever tricks?
Have you tested with 100,000 photos?
Have any body tried to compile itemviews-ng under QtCreator 1.0 and Windows? This mission is impossible!
Why did you public projects that can’t be build on all supported platforms by Qt? Qt since now is not cross-platform framework? I’m very disappointed. And Trolls even want to get money from customers for commercial support! But even not test projects that they are public on their site!
Why wasn’t the GraphicsView framework an extension/integration of the ModelView framework? Can’t a GraphicsView be another integrated view to a model where QModelIndex(es) are employed and synchronous events are proprogated. I have to custom wrap models at this point and I don’t understand exactly what the limitations are that prevent this. I am still learning so bare with me here
. Thank you so much for Qt!
@kirill : “I’m very disappointed”. We are sorry, but if you read more carefully the blog post it says that it is a research project. That mean no support, bugs and issues regardless if you are a customer or not. This project is not aim to be in production (because API can change anyway) and more at this point we don’t want to spend time to test all supported platforms (including exotic compiler and OS). When this framework will be release then you will have proper support, and the quality. I say it again : “This project is for early adopters”.
@Marcel: the implementation of indexAt() will have to be different depending on the how the view lays out the items. In the case of free floating items it can be a bit complex (a bsp-tree lookup is on average O(log n), for example). In other cases, like a normal one-dimensional list, it can be relatively easy.
Heuristics can also be used; for example it is likely that the coordinate you pass to indexAt() is in the visible area of the view.
If you guys are interested, I might write a separate blog entry on how the internals of the views work. In any case, the code is available for download so you can have a look yourself.
@travlr: an early prototype of the graphics view was actually implemented using the model/view framework. It turned out that representing a scene-graph using the model/view interfaces was technically possible, but not a very attractive solution. We found that a purpose build scene-graph API would be a better solution for the most common cases.
@Kirill: this is exactly why we put projects on labs; to get feedback and bug-reports. Also note that itemviews-ng is not a commercial product; it is free (both as in beer and speech).
Ah ItemviewsNg is back. Sadly i cannot compile it on windows+msvc because of inconsistent dll linkage, i guess its a problem with the exports.
Any chance that you can look into compiling on windows/msvc?
@zbenjamin: As I understand, Qt guys treat Windows+msvc as an “exotic platform”. Even Windows+QtCreator1.0 is an exotic platform (please see post from alexis.menard upper)
.
@trolls: Sorry guys, may be my previous post was a little bit tough. But I want to repeat that from my point of view – your position with ignoring Windows platform in your labs projects (Kinetic have similar problems) – is very strange. And word “strange” is very very soft description of current situation.
You want to get feedback from users? But why only from Linux (and maybe MacOSX) users?
I’m a big fun of Qt (if I shut my eyes to some qt internals (especially QGraphicsItem-related stuff hardcode implementation);-)) for many years, but currently I have some doubts…
@kirill : By “exotic platform”, i don’t include Windows+msvc. There is an issue with Windows and msvc, we will take a look on it thanks for report and sorry. But btw we accept patches as well
.
What do you mean by hardcore implementation of QGraphicsItem?
Compilation should be fixed for MSVC. It should end up in the git repository tomorrow.
@Kirill: you were blunt, so let me be blunt too: there’s no conspiracy to drop Windows. You’re being paranoid and completely unrealistic.
ItemViews-NG is a brand new research project. The two developers who are working on it are using Unix systems (Linux and Solaris actually). So it’s understandable that the first iterations will have problems compiling or working on other platforms. Windows is a casualty in this particular case. In other projects, it may be other platforms. It happens, that’s life, deal with it.
More importantly, the projects are made public so people can start reporting those issues. If you have a compilation problem, report it, preferrably with a patch. If you find something not working, report it too. If you have suggestions on how the API should be, what features and use-cases should be addressed, report it.
In other words, we appreciate all types of constructive criticism. Complaining, we don’t.
@alexis.menard I already tried to fix the problem. First thing i did was to change the QT_GUI_EXPORT into a own export define QT_ITEMVIEWNG_EXPORT, and a additional header file that defined the exports. I made it compile but had problems with QMetaObjects that were not exported. I gave up at this place and started to whine at you instead
.
Good to know that you accept patches i’ll keep that in mind.
Comments on this entry are closed.