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?”
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.”
– 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”
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!