Table View with Qt Quick

Published Thursday May 26th, 2011
31 Comments on Table View with Qt Quick
Posted in Labs, Qt, Qt Quick, Uncategorized

If you have been using Qt Quick on the desktop, chances are that you have already run into the limitations of ListView. ListView gives you a convenient way to represent a basic flickable list of items. But most desktop applications need more than that to present things like play-lists and albums. I realised that this was a big limitation for the Qt Quick Desktop Components, so I wanted to see how feasible it would be to add this functionality on top of ListView.

The result is TableView. And it looks like this:

Here is a short video showing it in action. I also made some screenshots from other platforms: mac, windows, and kde. Regular mac users might notice that I moved the header column to actually sit above the scroll bar. (edit: added video recorded on a mac)

It is designed to work well with the existing models supported by Qt Quick such as ListModel and XmlListModel. But since the one-dimensional ListModel doesn’t have a concept of columns, we need to provide a mapping between columns and properties. So the model for the view above looks like this:

ListModel {
    id: dataModel
    ListElement { title:"Image title";  credit:"some author";  source:"http:/..." }
    ListElement { title:"Another title";  credit:"some author";  source:"http:/..." }

And to create a table view:

TableView {
    model: dataModel
    TableColumn {
        property: "title"
        caption: "Title"
        width: 120
    TableColumn {
        property: "credit"
        caption: "Credit"
        width: 120
    TableColumn {
        property: "source"
        caption: "Image source"
        width: 200

Note that the ordering and width properties provide only the initial configuration of the view. The user is free to resize or re-arrange columns. At first sight, mapping only a single property per column might look like a limitation. However, if you need more than one property per item, you can simply use a nested ListElement:

ListElement { firstColumn: ListElement { description: "Bananas"; color: "yellow" } }

By default the TableView will provide a plain delegate with basic elided text items in each cell.
However, where Qt Quick really shine is in how easy it is to customize. This is currently possible by overriding the rowDelegate, itemDelegate and headerDelegate. So for instance if you need a very basic editable item delegate you can do something like this:

    TextInput {
        text: itemValue
        onAccepted: model.setProperty(rowIndex, itemProperty, text)

This might not be the solution for everything yet. Known limitations include limited keyboard navigation and lack of multiple selection. Aside from that, all of this works rather well on top of any regular Qt 4.7 build so you can start playing with it today by cloning this repository:

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Labs, Qt, Qt Quick, Uncategorized


Serhiy says:

Thank you. This looks really nice.

But there is one thing I don’t understand. Will these desktop components be the part of Qt 5?
I mean we already know than QML will be major part of Qt 5. But what about components? How about components for different platform (mobile and desktop)? Will they be a part of Qt? Will they be a separate modules you can add to Qt? Or will they be just in git and you can grab them and use them if you want.

I will be greatly appreciated if you can comment on this.

anonymous says:

Looks fine, but qml “widgets” are too slow. For example, add 5000 elements to ListModel and see 100% cpu usage.

ListModel {
id: largeModel
Component.onCompleted: {
for (var i=0 ; i0.5 ? “Male” : “Female”})

anonymous says:

Link to modified example:

Fazer says:

Your approach to creating TableView seems very wrong. Specifying columns that are duplicated in the model makes it dependent on it. What if someone wants to use different models with the same table view?

Also, does it work with QAbstractTableModel subclasses?

Jens Bache-Wiig says:

Serhiy: That is still an open question. As you know, we are developing Qt 5 in the open so what you see right now is what we have. The components are completely usable with both Qt Quick 4.7, 4.8 and the current 5.0 builds. (with its own scenegraph branch) I still think QWidget will be important to desktop users and perhaps still the most common path. That said, we are working to make it viable to use Qt Quick increasingly on the desktop.

anonymous: That currently affects using the scrollbar. Try scrolling using mouse or keyboard and you will see that it performs quite well. Keep in mind that this is ongoing research. There is nothing inherently slow about qml “widgets” itself.

Alex says:

Hi Jens.

I just scratched the surface (I tried your included examples, but haven’t done anything of my own). To me, it’s in a pretty good shape. When do you expect that this will be merged with the other Qt Components repo? From the QTCOMPONENTS-200 bug, it seems that the basic shared API is almost done. I wonder how likely is that you release some technical preview of Qt Components that is more or less stable in the API (without any promises), even if the style is not native. To start learning you don’t care much about how it looks if you know that it will look great over time.

IMHO it would be better for Qt Quick adoption if you release some sort of working Button, Slider, Checkbox, and so on. It’s better than writing your own, and would require less porting to a final Qt Components. Quick is great, but I find a boring chore writing my own basic UI elements when I know some exist and work.

Thank you.

Jens Bache-Wiig says:

Fazer: Keep in mind that this is _limited_ by what is provided in Qt 4.7. If you see any other mappings to make this work within the limits of ListModel, feel free to suggest one. I am sure there are other ways to achieve it. The priority was to make the API QML-like and let you bind directly to header column properties such as visible, width, etc. Declaring them in the item itself makes this convenient.

We are looking into how to improve the item views for Qt 5 and supporting QAbstractTableModel directly is certainly an option. I will definately look into this.

Ali says:

Hello Jens,

Thanks for this entry.
You might remember our discussion on how to bind a list created in C++ to a TableView. I’ve tried nearly everything for like a day and wasn’t able to make it work.
If it is possible at all it would be great if you’d add it to this post.

Also on another note:
How about a bugtracker for the desktop-components?
I found something going wrong with images on OSX (when deploying) but am not able to fix it myself right now.
So I’d at least like to report it somewhere.

jstaniek says:

Hello Jens,
Thanks for sharing this work in progress. Believe or not but just yesterday I had a small related discussion. I am about to port from Kexi Table view widget ( from Qt3Support for Qt 4. It’s so big and complex that I left this task as the very last item. It is expected that the table view contains a lot of data, sometimes more than spreadsheets, have custom delegates for viewing and editing, supports column sorting and row filtering. And the model view is database-oriented with asynchronous data loading. My question is, regarding performance, whether stay with Qt Graphics View like the original Plasma or look at QML/QtDeclarative. I definitely would like to avoid QScrollArea. The target is desktop usage, while only stripped-down version of this widget would be used on mobile devices.

zbenjamin says:

Hello Jens,

great work, but its really only the beginning. In the end we need real TableModels, or better real ItemModels (QAbstractItemModel) in QML. Good to see some progress in that part.

Jens Bache-Wiig says:

Alex: Sounds like a good idea. At least providing a “stable” branch on the repository. But what prevents you from using the widgets that reside in my branch in your project as opposed to creating your own? Components such as this view is clearly useful for many cases already but there are a lot of performance and API alternatives I would like to try out before settings things in stone.

Ali: I just implemented and added an example showing how to wrap a QDirModel into a QML view. The trick is to expose properties by setting RoleNames.
You can already report bugs at Just make sure to mark it as a “Qt Components” bug with “Desktop” as sub module.

Jens Bache-Wiig says:

For the moment I would stick to your original plan unless you also want to take part in actually developing a complete solution for Qt Quick. As you can see from this post there are yet many unanswered questions. The Table View I presented above actually has more in common with QTreeView than QTableView. There is no solution available for a complete QTableView in Qt Quick at the moment and if performance is a concern, I would consider a more static approach. I do wonder why you cannot simply port your application from Qt 3 by using a regular QTableWidget though.

zbenjamin: Yes. I completely agree. I just wanted to provide a simple solution for many of the common desktop use cases that Qt Quick does not cover at the moment. I do not expect that all of the old model or view concepts will be transferred into the Qt Quick world. Keep in mind that the performance of a static C++ view will probably always be faster than a view that dynamically create animating and complex objects on the fly. It is trading performance for flexibility. So I personally don’t expect pure Qt Quick views and models will cover _all_ possible cases in the foreseeable future.

Oliver Knoll says:


first off, your work is really appreciated to make QML actually “usable” on desktops (for “ordinary desktop applications” with such “uncool” requirements such as toolbars, menubars, table views, gl widgets, …).

I am following the blogs about Qt 5/QML with great interest, but I have still *very* mixed feelings towards QML. Statements like “The performance is not great [on top of Mesa], but I seem to recall a mail in my inbox where somebody had already ran the QML Scene Graph on llvmpipe with quite good performance, but no personal experience.” (response from Gunnar in blog “Thoughts about Qt 5” are simply not good enough!

My main concern however is the general approach: WHY IS EVERYONE SO KEEN ON EDITING XML FILES? Why would one want to mix application logic across different domains, such as C++, JavaScript and XML? At least that is my impression when I read about “declarative UI design is so great!”.

Now great effort is put in actually bringing the same functionality (“widgets”) back to Qt 5 with those “QML desktop components” (so nothing really gained here in functionality, just what we alread had, just slower, except you have some horse-power and battery-draining OpenGL graphic card with a well-behaving driver under the hood).

And what is the gain? A few flashy and blinking widgets, easier to animate, eye-candy everywhere…

Yes, I agree, for embedded/mobile devices with simple “5 screen”-apps it totally makes sense to have something like “fixed-size layouts”, with a few buttons and scrolling areas, and I always thought “Yes, having QML on the desktop to do some flashy apps would not harm to have as an optional ADD-ON to Qt…

But now I understand the entire GUI rendering stack is forced upon a resource-hungry QML rendering stack, requiring a JavaScript interpreter.

So again I ask: what was wrong with the traditional QWidget approach? It was blazing fast to setup a basic main window within Qt Designer, I never had to touch the generated *.ui files, connecting to the GUI elements with signals/slots (auto-connect feature – nice 🙂 was very intuitive and type-safe (I wonder how this topic of type-safety is treated in JavaScript?), the generated code was compiled C++.

And doing GUI design “in C++” was very intuitive, thanks to a great Qt API! Why would I want to “outsource” that into JavaScript or “QML custom components”?

And even someone complained about the Qt layout management to be “broken” I think it is one of the best and most intuitive (when compared to these terrible “Card Layout” and “North-West-South-East”-layouts in Swing, for instance).

And I am very convinced that if an application has to look “shiny with shaded dialogs”, then this is the task of the desktop manager, NOT the application! You want some custom-looking buttons? Use CSS! Or the (admitedly very complex) QStyle and company. Or simply let the underlying desktop manager decide how to render buttons.

Just my opinion, but I think I share this – as a developer and user – with many other developers.

So you you really think you can bring down a simple Qt 5 Hello World application to under 10 MByte (on Windows: QtCore + QtGui were I think total around 8 MB in Qt 4.7), not to mention the memory footprint? And be AT LEAST as fast as with Qt 4.0 (to be fair, there was initially also a great performance regression in Qt 4.0, when compared to Qt 3.x).

I certainly hope so! And given the fact that you did a great job with Qt 4.x with regards to performance, there is certainly hope that in an upcoming Qt 5.2 or so we can actually start using Qt on the desktop – again 😉

But when I hear statements like “Use QWebKit” (how many extra MB was that DLL again?!) to render simple SVG images, this really gives me the impression that goals have changed within the Qt community.

I hope I am very wrong though…

Good to hear that there are other developments such as support for C++11 are going on 🙂

Cheers, Oliver

Mindset says:

@Oliver – yes, the goals have changed. Qt is now being positioned as an embedded/mobile toolkit first, desktop second. It was the other way around for Qt4. It’s where the world appears to be heading too.

All your concerns regarding Qt/Desktop with Qt5 are completely valid (like the size of the binary) but the Qt devs don’t really care since they have no experience writing and bundling apps and don’t listen to advise from those who do. Qt widget are not going away anywhere but no development will happen to make new widgets. The whole effort of QML on desktop is pointless just as you pointed out but again the Qt devs would rather spend time on this than make new widgets (heck, they are lots of widgets that are simply not part of Qt yet).

Jens Bache-Wiig says:


I don’t think this is the right forum for your post. It belongs on That said, I will respond as well as I can. The important thing to remember is that this project does _not_ aim to replace QWidget and all its derivatives. It aims to make some of those use cases possible also through Qt Quick. Widgets are still the best and only solution for full scale desktop applications.

I am however simply a Qt developer that really enjoy working with Qt Quick. I started this project because of that enthusiasm using my own research budget and spare time and I was amazed at how fast I could re-create a more or less complete widget set in a couple of months using Qt Quick. As a bonus effect, being the maintainer of most platform styling code in Qt, I got to try out how QStyle works when you integrate to it as a third party. This has given me ideas for Qt5 improvements that go well beyond Qt Quick. Most of the code of this project is still based on QStyle and improvements I did on styling still directly affect the traditional widgets.

But as it stands QWidgets are simply not enough for the increasingly important mobile and tablet space. And with the investments we are doing in Tooling on the QML side, I think people would like to at least have the possibility of using the same tools when moving between mobile and desktop applications. At the moment you might not see the benefits but I am confident they will become more obvious as Qt Quick matures. Keep in mind that widgets such as shiny color pickers, animated listviews and calendars are easily embeddable within regular widget based applications. The fact that they are much faster to develop in Qt Quick only means you get access to these things faster.

Oliver Knoll says:

Hello Jens,

Yes, I am very well aware that the Qt 5 feeback list is the place to discuss these matters, and I will join this list shortly.

I must also admit that my posting was a bit too exagerated in some respects in that I am also very much aware that the QWidget API will not disappear too soon. And from what I understand if one wants to stick to C++ the UML files can still be used just as the traditional *.ui files, no JavaScript has to be touched or XML files needed to be edited manually (that’s what the new UML designer will to, IIRC).

Anyway, I just wanted to express my general concern that the development goes towards “shiny PowerPoint-ready(tm) widgets” (well you know what I mean), and this now also affects the performance of QWidgets, because as it seems they are rendered on top of he “QML rendering stack” as “legacy widgets”, with the long-term goal in mind to make them finally disappear completely (whether that’s realistic or not).

So: a lot of effort from the Trolls (I hope you don’t mind me using this old-fashioned term 😉 is now “bound” to QML development, which affects the “remaining desktop developers”, in that QWidgets are marked as “done”, and other important areas such as XML processing, SQL or SVG to name a few don’t get any love either.

Don’t get me wrong: I think the work – and also to a great deal research you do! – is very interesting and for sure I’ll have another closer look at QML in the near future! But so far I expected QML to live “in parallel” to the rest of Qt, but with the announcement that the whole rendering stack is now replaced, requiring OpenGL ES support to get (hopefully the same) performance (goodbye VirtualBox!) as we have now etc., and the explained goal to completely deprecate and replace the QWidget approach… THAT’S what worries me!

“But as it stands QWidgets are simply not enough for the increasingly important mobile and tablet space.” Well, I totally agree here, and given the mobile background that totally makes sense to develop into this area. And to have the same possibilities on a desktop, why not!

“The fact that they [shiny widgets] are much faster to develop in Qt Quick only means you get access to these things faster.”

For my use cases – creating main windows, toolbars, enabling/disabling menu entries, input fields, OpenGL widgets, QGraphicViews – I am blazing fast with Qt Designer! Most of the times I spent re-arranging text fields, adjust the layout… and I DON’T want to do this by hand, read: edit XML files! That’s what made Qt so strong, and a clean separation of UI code and application logic (still in C++, with all it’s type-safety, confort of Qt signals/slots).

Now you promise we will have the same C++ confort with QML, and for now I just have to believe you in this point. But when I looked at the QML demos back in Qt 4.6/7 I was really put of my all these UI elements – and how they behave! – spread all over QML files, JavaScript, C++… agreed, for “app-like” applications that might work, complexity can be managed. And I was impressed how easy it was to download photos from flickr and animate them.

But then again: the applications I do I spent 90% in application logic and about 10% in GUI logic (and I really mean just the part “how the GUI looks like, not the behaviour how it should react on mouse clicks etc).

Now you are saying with QML I could speed up those 10% by say 100%, so entire application development time goes down to 95%. Hmmm… and I am totally not a fan of “custom-looking” applications either (as you might have read about my “evaluation” of Lightroom on qt-interest… it is *features* that count in the end!).

But despite my sceptism: I am really curious how things go forward with Qt 5! You guys do a great job, and if that means I have to change my mind-set (also about how future applications are used ;), then so be it! I just request: make it faster, with less resources used! 🙂

Cheers, Oliver

Oliver Knoll says:

Oh, and one more thing: I really appreciate the way you – Nokia Qt Team aka “Trolls” – take up concerns from the community and react to them by openly present your point of view and tell us “That’s were we are aiming”! You did that in the past and you do this now, so I am confident that things will rock’n’roll also in the future! It’s good to hear that there are still enthusiasts such as you working on these new technologies!

Cheers, Oliver

Very nice Jens – more love for the desktop! <3

Zeno Albisser says:

Hi Oliver,

you mentioned quite a few thoughts that you most likely share with a lot of people around the globe or even with people from our own office. I joined Jens’ effort quite recently. The main reason for me to help him pushing his visions forward is, that i want to be able to write awesome desktop applications also in future. I am personally not a real graphics guy and i usually do not really care about the very latest most shiny look and effects. But i definitely care about simplicity, flexibility and also performance.
By all the effort that is now put into Qt Quick it seems totally vital to me to benefit from all this amazing work also on the desktop. And exactly this is what motivates me the most. Of course the concept is quite different from traditional widgets and a lot of things are simply not there yet. But for the first time it is now really possible to write desktop applications using QML.
I am personally a big fan of Qt Widgets and i don’t want to loose these either. But at the same time i am absolutely convinced of the approach that we have with Qt Quick, especially for the desktop where we can afford some memory and some graphics power.

hunt0r says:

I dont understand why so many people dont like to create desktop apps with QML. I am sure there will be a rich Set of Desktop QML Elements available for Qt 5 so I see no point why QML should be only for Moble apps.

The main problem of the Qt Widgets API is that it is slow. That is because of the QPainter style Rendering. It does not allow to use Hardware Acceleration of modern Hardware effecently. The QML Scengraph project has shown how fast a more Declarative approach can be. Thats why declarative UI design is good not because it is easy but because it can be accelerated.

@Oliver have you tried to use CSS to tyle Qt widgets. They are slow as hell comperd to even non accelerated QML at the moment.
About the layout management the Qt layout system is not bad but I like the anchor based layout of QML more.
And the “simple and intuitive” Widget API. Have you ever tried to do a more comlicated things with the Item views like having a Scrollbar or so in every item. Thats a pain in the ass compared to QML.

And Why are so many people concernd about the size of a “Hello World” application? Until now I havent seen any useful Hello World Application but many that have much more code so that the Code Size of the Framewok is irrelevant.

Jason says:

Echoing a few other comments:
1. This is _REALLY_ nice and solves a lot of problems I have had trying to make existing table do flashier things. Thanks!!
2. Let’s make it work with existing model views. Please?
3. At a minimum this should scale to many thousands of items, esp. as this is positioned as a desktop component. Browser-based solutions can almost as far these days, WPF definitely can. Maybe this would be partly solved by (2)?

Jens Bache-Wiig says:

Jason: Yes. And thanks for bringing the discussion back on topic 🙂 I did add an example showing how you can use QDirModel with a proxy model exposing roles to QML. But performance is probably _the_ most important thing to solve right now. It is obvious that the scrolling performance needs to improve a lot for large views.

Max says:

Nice work, Jens!

But I have a big question. How can i prepare my upcoming desktop applications for this / Qt5. I’ve developed a lot for embedded devices in Qt Quick in the past. So for me (who write not much desktop applications) it’s a pretty nice feature to use the same techniques on desktop and embedded devices. 🙂

Jason says:

Thanks Jens – great to hear this is on your radar. This is exactly the kind of work I need to employ QML on the desktop in a big way (which I’m dying to do). I’m looking forward with much anticipation to see where your efforts lead!

JubiluM says:

@Jens Bache-Wiig:
“But as it stands QWidgets are simply not enough for the increasingly important mobile and tablet space. And with the investments we are doing in Tooling on the QML side, I think people would like to at least have the possibility of using the same tools when moving between mobile and desktop applications.”

Are not enough? Well it’s (mostly) native widgets under the hood in almost every platform, isn’t it? Mobile and tablet space are an important space of it-industry, but as that is true, desktops aren’t going anywhere either. They also evolve and systems like Qt (widget) will have to adapt to those changes. You will find a huge amount of still alive Qt desktop applications (some of still depending to Qt3 support) and developers who love and appreciate the robustness of the platform.

I’ve seen similar processes earlier and one had to be blind not to see current process being a question of little by little deprecating the “secondary” system. So desktop developers are being forced to use system that naturally isn’t the best fit for desktop development. Or can we even count on the desktop support int the future, even by QML?

@Oliver Knoll:
“For my use cases – creating main windows, toolbars, enabling/disabling menu entries, input fields, OpenGL widgets, QGraphicViews – I am blazing fast with Qt Designer! Most of the times I spent re-arranging text fields, adjust the layout… and I DON’T want to do this by hand, read: edit XML files! That’s what made Qt so strong, and a clean separation of UI code and application logic (still in C++, with all it’s type-safety, confort of Qt signals/slots).”

Well said. Plus how comfortable it is to use own enhanced widgets, inherited from Q…, with Qt Designer by Promote to – feature. Is there even concept similar to inheritance if you use QML….in a sense of extending the functionality of something given and being able to use it cross projects?

I think that re-inventing the wheel is one of the useless forms of software development….unless there is a good reason for it. Reproducing the whole widget-based stack (I expect that only a minor part of the existing will ever get ported) is something wild and doesn’t make sense in any other way than to offer functionality needed by QML-programmers. And it’s ok, Qt Quick/QML is very interesting and seems to fit the purpose of mobile/desktop development perfect. But abandoning the “traditional” Qt will be pure insanity…..

But enough lessons learned from the past…best to avoid using any 3rd party related stuff in application logic. Do just the ui if possible. Even though Qt-containers, strings etc. would ease one’s life on application code, you’ll be in trouble if a nasty decision is being made by the developers of the toolkit. Just standards compliant C++ code and you’ll be fine for years to come. Also, exploring and learning another toolkit as a hobby will cover your back.

Anyways, I respect the honest communication efforts from Qt, without fearing quite harsh criticism on our behalf every now and then :).

JubiluM says:

“seems to fit the purpose of mobile/desktop ”

should have been:

“seems to fit the purpose of mobile/tablet “

Jens Bache-Wiig says:

Max: There is not much you need to prepare for. Just design your application with a pluggable UI in mind the same way you would develop a mobile application with Qt Quick. For the time being you will still have to create the QMainWindow part using actions and menus but we are investigating how this could be done all on the QML side. Possibly by having a separate QML runtime for desktop apps.

To those concerned about scrolling performance on large models:
I tried it out on the latest build of Qt 5. The scrolling performance still needs more work but it is well beyond usable.
Here is a video I made showing the view scrolling 1 million items in a list model using the latest Qt5 (with Qt Quick 1, so it should be roughly the same as on 4.8)

qtnext says:

it seems good … for me QML can be a very good advance for desktop … but we need :
1)- for now, we need table, tree view …. it’s for now a nightmare to simulate treeview with multiple list view …
2)- a common interface for model (now there is qabstactitemmodel, listmodel, xmllistmodel, … and they don’t have a public C++ interface ) and the possibility to implement easily a new kind of qml item like a custom pathview, listview, ….
3)- a working qt creator qml designer : it’s far from stable, slow, crash, and when embedding qml components, you don’t always see the components item in the designer …. so 80% of the time I need to set position of relative items by hand in text editor ….

Hi Jens Bache-Wiig,

Great work here. I’ve been using QWidget(s) / QLayout(s) for a few years. I can understand people willing to keep the old model.

But I think QML has proven to be powerful especially since it’s coupled with C++ QObject(s).

Now that I’m using Qt Quick I see no reason to go back.
Spending time to make it really usable on desktop is a strong priority from my perspective.

PS: I am also experiencing slowness using my custom QML ScrollBar and large models.

It seems that this will be fixed in 4.8 ? I guess somebody optimized the Flickable item ?


Jens Bache-Wiig says:

Benjamin Arnaud:
I am glad you like it and completely agree with you. I was afraid nobody would be positive 🙂 I just compiled and tested with the Qt 4.8 tech preview and can confirm that the scrolling performance for large models is indeed better. (i.e the model size above a certain threshold does not matter). Not sure exactly which fixes apply though.

JubiluM says:

@Jens Bache-Wiig:
“…I was afraid nobody would be positive…”

No fear, you/Qt have/has a lot of friends :)! Hard criticism you sometimes see here just proves that people are passionate about Qt. Straight feedback from developers’ side might also help you see things and views that you wouldn’t have thought of.

Commenting closed.

Get started today with Qt Download now