Back in Qt 4.4, QFileDialog was rewritten in order to help with performance issues. In addition to that a new model was designed to read the hard drive content: QFileSystemModel. The main advantage of QFileSystemModel is its thread: the model is populated asynchronously by a gatherer thread. The benefit is that the GUI is not stuck while the gatherer is reading the file system (except one case). In 4.4.x, 4.5.x, 4.6.x the focus was to mature QFileSystemModel to make it fast and stable. I think now it has reached this status and QDirModel can be easily replaced by QFileSystemModel as it provides the same features and more.

So in 4.7, QDirModel will be obsoleted and QFileSystemModel will be used in our examples. At the same time QCompleter will gain the support of QFileSystemModel. The commit is 319b0262418d74cc416a7dd1f620b54ba45bad22 and you can find it in our trunk.

Some time ago I wrote about our ideas for a new Qt widget set for QGraphicsView.
Up till now we have all been busy working on finishing Qt 4.6, so not much has happened since then.
But, it is now time to quote Hubert J. Farnsworth: “Good news, everyone!”. The Next Generation Qt Widgets project is of the ground!

Open Is The New Black

With Qt 4.6 released, we can now dedicate our time to Next Generation Qt Widgets. But we are not the only ones that will be working on this project. In addition to Qt developers, we will also have developers from INdT. And you are hereby invited to join as well!

liftoff by popofatticus on flickr

Jump Into The Fray

First, you want to clone the repository. It is also recommended that you browse the Qt wiki to get familiar with coding conventions and the contribution model. You may also want to read up on the rules. You should now be ready to join the discussions on IRC or on our mailing-list.
We are looking forward to seeing you there! Happy hacking!

So, are we in the future yet? It is 2009. Where are all the flying cars and personal jet-packs ? Surely we would all be wearing metallic outfits (complete with Employee Visualization Appendage) by now.

The Future Is A Canvas

Back in 2006 a little bit of the future arrived when QGraphicsView was introduced, we were aiming to replace our old QCanvas API with something more flexible and powerful.
It turns out that it is great for creating dynamic, smooth and animated GUIs. Over time it has become the backbone for next-generation user-interface projects like KDE’s Plasma and Qt Declarative UI.

Yet, for all its dynamic, smooth goodness, there are some missing pieces in the puzzle. People are creating full user interfaces in graphicsview, but Qt offers only the most basic widget types to help them out. In many cases it is enough to offer basic primitive types. But if you want to integrate with the platform you are running on or want to use more complex widgets, it becomes difficult.

The Shiny New Stuff

This is why we have started a research project aimed at providing a basic widget-set based on QGraphicsItem. It is a natural extension of the Next Generation Itemviews project. We will take the opportunity to look at how to improve the widget API, internal structure and how we do widget styling and theming.


HotWheels by Leap Kye on flickr

One of the lessons we have learned is that graphics hardware is generally happier when moving pixmaps around, than when drawing lines and shapes again and again. This has implications for the styling API, since our current QStyle is based around drawing complex controls imperatively. It would be better to build our widgets as a graph of (cached) primitive elements that can be transformed and updated individually if necessary.
Similarly it also makes sense to make the input regions in the widget into separate elements in that scene graph.

But, for all our fascination with the new and shiny, we should not forget that our existing widgets contain years of accumulated experience in the form of code that handles all sorts of weird and wonderful corner cases. We don’t want to go though the pain of re-discovering all these cases. It makes sense to re-use existing logic and behavioral code by moving this code into classes that can be used by both the old and the new widgets, when possible. This will also allow us to directly test and verify the internal widget logics independent of the widget front-end.

Still Kinkin’ It Old School ?

We are not forgetting our QWidget based widgets. They will get some initial benefit of better tested back-ends and hopefully some code cleanup. I also have some ideas that will drag QWidget kicking and screaming into the future, but I’ll leave those for another blog-post. Always leave the audience wanting more.

Talk To Us

Even though we are currently working full time on getting Qt 4.6 out the door, the widgets-ng repository is already public and we are already hanging out on #qt-widgets-ng on irc.freenode.net .
I will be attending the Qt Developer Days in München next week, and there will be several developers from the Qt Widgets Team attending the San Francisco event too. Feel free to discuss anything widget related (or any random topic, really) with us. See you there!

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

I figured it was time I blogged about my Creative Friday project, so here goes!

“Lieutenant. Do you intend to blast a hole in the viewer?”
- Picard to Worf in “Encounter At Farpoint”

As you may be aware of, the Qt Item Views is a set of widgets and classes that allow you to display, navigate and edit data, separating the data from the presentation (model/view).
I’ve had many discussions with customers and colleagues (and random people who just seemed to have opinions on the subject) about the item views over the years. You could say it is a hot subject.

Not surprising. If you are using Qt, chances are you are using the item views. And if you are using the item views, you are likely to have an opinion about them.
While using these classes you may have even form the opinion that they are not exactly the most shining example of Qt quality framework and API design. Let’s just say that there is room for improvement, lots of room!

Troi: “What happened to all the people?”
Worf: “War?”
Data: “Disease?”
Geordi: “A dissatisfied customer?”
- Troi, Worf, Data and Geordi “The Arsenal Of Freedom”

The symptoms are clear: the framework is generally too slow, unstable and the API is difficult to use. A clear case of overly complex design. But where does all this complexity stem from ?

“It’s elementary, my dear Riker. Sir.”
- Data in “Lonely Among Us”

The cause is the feature that has been both a blessing and a curse for item views.
The framework has been designed to trees, tables and lists interchangeably. You can use a list view to show a tree, a tree view to show a table and so on. A pretty cool and sometimes very useful feature.
But it also means that all parts of the framework has to work with a structure that can represent a tree, a table or a list. So, otherwise simple cases become complex because of the inherent complexity of this structure.

“Data, you all right ?”
“Yes sir, I’m fine.” [Contraction!]
“Then get rid of that damn twitch and put on the correct uniform.”
“Yes, Captain.”
- Picard and Data in “Datalore”

The cure is pretty obvious: separate the list, table and tree from each other.
This is the basis for my itemviews-ng research project. It is a complete re-design of all the components in the item views framework, with one overriding principle in mind:
Keep It Simple, Stupid!

“This is called a banana split. It’s quite possibly one of the greatest things in the universe.”
- Wesley in “Suddenly Human”

But there are more reasons to have another go at implementing item views.
Item views can’t get away with just displaying items anymore. They need to be animated, allow flick-scrolling and generally be loaded with snazzy graphical effects. Items fly in from all sides, zoom, rotate, blend or do other fancy stuff. The current item views are simply outdated.

“Can you recommend a way to counter the effect?”
“Simple. Change the gravitational constant of the universe.”
- Data and Q in “Deja Q”

The good news is that we already have something in Qt that allows us to do all this: the QGraphicsView. So it just makes sense that we use QGraphicsView and QGraphicsItem with the new item views.

As an experiment I’ve decided to implement the internals of the views as QGraphicsWidgets (called a control for now, although that name is slightly confusing). This allows you to use item views as elements in a graphics scene.
There is also a QWidget-based view (it actually inherits QGraphicsView) that wraps the control and also provides a default data model and selection manager.

For a QListViewNG you can use QListControl, QGridListControl or QPathListControl. In addition you always have the option of implementing your own custom control to get the layout and/or painting you want.

“Maybe Q did the right thing for the wrong reason.”
“How so ?”
“Well, Perhaps what we most needed was a kick in our complacency to prepare us for what lies ahead.”
- Picard and Guinan in “Q Who”

But enought talk, more rock! The code is available here:

Check it out and enjoy!

Hi there. This is my first blog post, so I guess introductions are in order; My name is Henrik Hartz, and work as a Specialist with Product Management in Troll^W Qt Software. In Product Management I do all kinds of stuff, ranging from working with requirements, specifications, product releases, meeting customers, thinking about the future of Qt, the list goes on.. Recently I’ve had the pleasure of focusing on WebKit.

WebKit is a fantastic technology. Being able to stick web content into your application is simply amazing, there’s just about anything out there you can show! And, a lot of people know HTML, so making use of this to add content to your application enables you to (ab)use your Graphic Designer buddies.

But, WebKit is so much more than just a way to show HTML in your app. You can actually do anything a browser can - and much more! Experimenting with WebKit over the last couple of months I’ve made an example that a lot of people seem to be interested in; Using WebKit to host a Google Maps component.

I wanted to show where our offices are located in the world. So, I started with a simple QStandardItemModel that would read in addresses from a txt file. In the constructor, we read in the text file - using the first field of the comma separated line as the display role, and the rest as the address stored in the UserRole;

QStringList addressLines = address.split(",");

QStandardItem *item = new QStandardItem;
this->insertRow(this->rowCount(),item);

item->setData(addressLines.takeFirst(), Qt::DisplayRole);
item->setData(addressLines.join(",").trimmed(),Qt::UserRole);

With this model in place, we simply set it on the list view of our GUI design (yeah, I like using Qt Designer - it’s fast!);

ui.treeView->setModel(new AddressModel(this));

In the GUI we’ve also placed a web view, which is pointed to a web page under our control. This page shows a Google Maps control. So here is the GUI with the address list and QtWebKit component;

This doesn’t do much on it’s own - so we promote the QWebView class to a custom component “Map”, defined by map.h in Qt Designer. This component has some additional services that allow us to update the map, specifically;

void geoCode(const QString &address);

What we want is to update the map based on the entries in the list view when they are clicked. We do this in a slot method connected to the clicked signal of my view. Here we can access the data of the item being clicked, extract the address and ask the map component to geo-code it;

void MainWindow::showItem(const QModelIndex &idx)
{
ui.map->geoCode( idx.data( Qt::UserRole).toString() );
}

The geoCode method will use QtWebKit’s capability of calling JavaScript functions in the web environment. Here we’ll use the Google Maps API to get Google to return a coordinate of the specified address in CSV format, using the asynchronous QNetworkAccessManager::get(const QNetworkRequest &request) API;

void Map::geoCode(const QString &address)
{
QString requestStr( tr("http://maps.google.com/maps/geo?q=%1&output=%2&key=%3")
.arg(address)
.arg("csv")
.arg("GOOGLE_MAPS_KEY") );

manager->get( QNetworkRequest(requestStr) );
}

In another method connected to the QNetworkManager::finished(QNetworkReply*) signal, we parse out the coordinate returned in CSV format from Google, and pass it to a method which updates the map component appropriately;

void Map::loadCoordinates()
{
QStringList scriptStr;
scriptStr
< < "var map = new GMap2(document.getElementById(\"map\"));"
< < "var bounds = new GLatLngBounds;"
< < "var markers = [];"
< < "map.setCenter( new GLatLng(0,0),1 );";

int num=-1;
foreach( QPointF point, coordinates ) {
scriptStr < < QString("markers[%1] = new GMarker(new GLatLng(%2, %3));")
.arg(++num)
.arg(point.x())
.arg(point.y());
}

scriptStr
< < "for( var i=0; i<markers.length; ++i ) {"
< < " bounds.extend(markers[i].getPoint());"
< < " map.addOverlay(markers[i]);"
< < "}"
< < "map.setCenter(bounds.getCenter());";

this->page()->mainFrame()->evaluateJavaScript( scriptStr.join("\n") );
}

In the final call, we tell QtWebKit to evaluate the JavaScript we have synthesized, and the web view updates with the appropriate location;

The snippets shown here are simplified to some extent, but you can find the complete source code here. Please remember to put the HTML for the map component on a server you control - and replace the GOOGLE_MAPS_KEY with your own key (you need to register and bind to a domain for it to work) in both map.cpp and index.html.

Enjoy!

History in a web browser has a number of challenges that make it a good demonstration of Qt’s model/view. The history is used in the url completer, the history dialog, the history menu and lastly by WebKit itself for determining if you have been somewhere before. And just to add to the mix it need to be able to scale. A year of history could easily be 20,000+ entries. The History component of the demo browser is more advanced then the examples in Qt and shows off some more the cool aspects of model/view and it has been suggested to me that writing up a little description of how it works might be useful to some developers looking to use model/view in their own applications.

I have spent time working on item view and know it pretty well (I put together the Modeltest and ItemView Tips) so the history component of the demo browser was fun to write. The source code for all the classes can be found in demos/browser/history*.

The first class is the history manager who’s data structure is optimized for history, not for dealing with item views. The class loads and stores the history, emits signals when there is a new entry or one is removed and that is about it. This class should be able to stand on its own if it was pulled out and used without itemview. I wanted to keep the memory usage down as much as possible. For 20K entries it was only using around 10MB of ram when I was done.

On top of the HistoryManager is the first model, a QAbstractTableModel (HistoryModel) who’s only job is to wrap the history model. It doesn’t do anything other then implementing functions such as rowCount(), flags(), and data(), matching up the itemview functionality with the corresponding functionality in the history model.

On top of that is a QAbstractProxyModel (HistoryFilterModel) who job it is to filter out duplicates. Looking at browsers I noticed that if you visit a link twice the browsers always hide everything, but the most recent visit. A hash is used to determine if a link has been visited along with the most recent location of the visit. This model has a convenience function that is used by WebKit to determine if a link has been visited.

On top of HistoryFilterModel is another QAbstractProxyModel (CompleterModel) that adds a new row for every entry stripping the front of the url so the completer can complete on “http://trolltech.com” or “trolltech.com”. This model is used by the QCompleter in the url line edit.

For the history menu and the history dialog the browser wants to display a tree based structure where each top level node is a Date with history entries for that date as the children. So on top of HistoryFilterModel I wrote a new QAbstractProxyModel (HistoryTreeModel) that converted the table into a tree. Converting the table into a tree was a little tricky, but the modeltest was very useful for detecting problems.

Before putting the HistoryTreeModel into the dialog I wrapped it one last time with a QSortFilterProxyModel so that the user can do on the fly searching. The searching (really filtering) is very fast. This is put into the HistoryDialog that has a EditTreeView which is a normal QTreeView, but with added support for the delete key to remove one row from the model.

On top of the HistoryTreeModel there is another QAbstractProxyModel (HistoryMenuModel) that slightly modifies the tree moving the most recent history entries inside of the root rather the first date folder. To do the mapping I translate each node in the tree all the way up to the table and back again to convert to the source index. This class was just a big pain to code and took a solid day to do. Looking back adding a hack to the menu rather then writing this class seems like a reasonable option given the effort.

Both history and bookmarks show up in the top level menu so I wrote a subclass of QMenu (ModelMenu) which can take a QAbstractItemModel and on the fly the ModelMenu will populate it with actions from the model. This is pretty straight forward and works very well.

Overall the History classes show off how you can use item view to to write some pretty cool stuff that scales too. History’s classes contains a wrapper, some classes that filter out items, some classes that add new entires, modify or even move items around and lastly some views the present the data in very different ways.

Using my inkscape skills (or lack of) here is a diagram of the classes to help make better sense of the relationships.

It all started as a small feature request - Adding style sheet support for Item views. I quickly found out that our default delegate, QItemDelegate, doesn’t use QStyle the way it is supposed to. Jens had faced the same problem when trying to provide native look and feel for Vista and ended up writing his own delegate. This is quite a limitation because currently authors of custom QStyles can customize the look of everything in Qt except item views.

So was born QStyledItemDelegate - The default delegate for Item views starting 4.4. To let that sink in - all our views now delegate painting to QStyledItemDelegate instead of QItemDelegate. QStyledItemDelegate prompty plays its part by delegating everything to QStyle The cool thing is that this delegate uses the QStyle to determine the sizeHint, the layout of the text, indicators and icon. And of course, it paints everything through QStyle. Complete control to QStyle.

Jens has already incorporated this new feature into QWindowsVistaStyle. So, by default, your views will look all fancy in 4.4 like below:

We are unsure about how selection in table view must be handled. We are open to suggestions:

On other platforms, they should exactly like before. If you had written your own delegate using QItemDelegate, it is completely unaffected by this change. If having to write a custom QStyle or a custom delegate sounds daunting, just use style sheets. Try something like this,

QTreeView::item {
    border: 1px solid #d9d9d9;
    border-top-color: transparent;
    border-bottom-color: transparent;
}

QTreeView::item:hover {
    background: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 #e7effd, stop: 1 #cbdaf1);
    border: 1px solid #bfcde4;
}

QTreeView::item:selected {
    border: 1px solid #567dbc;
}

QTreeView::item:selected:active{
    background: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 #6ea1f1, stop: 1 #567dbc);
}

QTreeView::item:selected:!active {
    background: qlineargradient(x1: 0, y1: 0, x2: 0, y2: 1, stop: 0 #6b9be8, stop: 1 #577fbf);
}

Here’s how it looks:

See Customizing QTreeView, Customizing QListView for more information.

We merged the new delegate into our main branch last week, so if use the latest snapshots, you already have it. If you have any specific requirements to styling of tree widgets, list views and tables in mind and are wondering if it is possible now using the new delegate, please leave behind a note!

Qt has a pretty nice architecture for doing MVC (Model/View/Controller) and being in the Qt Jambi team we wanted make Qt Jambi have access to all this. Unfortunatly we rather quickly ran into 2 big issues:

So based on this we sat down and looked at ways to come up with a way to keep the QModelIndices on the C++ side for the performance critical parts and to improve the programming joy that is hierarchical data models. This basically led us QTreeModel, a subclass of QAbstractItemModel, which provides 3 virtual functions:

public Object child(Object parent, int index)
public int childCount(Object parent)
public Object data(Object value, int role)

As you can see we removed all the QModelIndex from the API, hid the parent() function and introduced the childCount() and child() functions for querying the structure and the data() function for querying the value.

The data function also has convenience overloads like:

public String text(Object value)
public QIcon icon(Object value)

For querying the most used data roles.

To interoperate with the rest of the Itemviews framework we also provide mapping functions between QModelIndex and java.lang.Objects which is needed to interact with things like selections, collapsing/expanding, etc.

public Object indexToValue(QModelIndex index)
public QModelIndex valueToIndex(Object value)

I have a little demo app that shows many of the different API aspects here and
here, such as dynamically adding and changing nodes. Unfortunatly, this stuff is partially based on the in-house version of Jambi so you can’t run the first link just yet, but at least it gives you some insight into how easy it is to write tree models in Jambi now. The second link, is shipped as part of the current Qt Jambi beta.

Who knows… maybe some of this will sneak its way back into Qt / C++ too someday