We Have Liftoff!

Published Thursday December 10th, 2009
15 Comments on We Have Liftoff!
Posted in Graphics Items, Graphics View, Itemviews, KDE, Qt

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
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! ๐Ÿ™‚

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

Posted in Graphics Items, Graphics View, Itemviews, KDE, Qt


bastibense says:

Can’t wait to see a replacement for the over-engineered Q*ItemViews and models.
They are a pain to use, especially QAbstractItemModel::parent(). ๐Ÿ˜‰

mbm says:

The ItemviewsNG project is now part of Next Gen. Widgets. You can check it out here: git://gitorious.org/qt-labs/itemviews-ng.git

Chakie says:

Yes, I humbly bow to the person (nay, coder demigod) that can create a tree model without copying the “Simple tree model” example and without going mad in the process.

Rich says:

The code tree is a branch off the main Qt, any chance you could highlight the parts to look at to see what you’re working on?

mbm says:

Most of the work will be done in src/gui/graphicswidgets, src/gui/controls and src/gui/widgets.

Nils says:

So are you going to factor out most of the Q*Widget logic to Controller classes and provide a (complete?) set of QWidget/QGraphicsWidget based implementations? QLineEdit seems to be the first class that went through this conversion.

I hope in the long run (maybe with 4.7) QGraphicsProxyWidget will no longer be needed for most common widgets (it doesn’t work very well with any widgets that have popups anyway).

Will all those QGraphicsWidgets be available from QML? What about styling (native L&F, CSS)?

Thiago Macieira says:

@Nils: you seem to have captured the essence of the project.

We want to do all of what you’re suggesting: to have all of the widgets available “natively” in Graphics View, to have them accessible from QML and to have native styling.

As for CSS, we’re probably just going to ditch that in favour of QML.

Nils says:

The styling issue is something that I have some problems with in QML. We usually try to separate logic from styling. With QML you describe both.

IMHO it would be useful to find a bridge between QML and CSS styling. Something like a binding to CSS properties. With this you could still modify the design without touching the QML.

Or is there a clever way to split QML files to have one containing the logic/animation/etc. and a second one to play the CSS role (that can easily be exchanged)?

mbm says:

The idea is that you can use QML to describe how you want your components to look (and behave) in the style, even for a single component. This will hopefully be flexible enough that you won’t need CSS.

Nils says:

@mbm: I’m not a QML expert, so please correct me if I’m wrong: Consider something like the QML Flicker demo. This is a rather large application written in plain QML. That’s cool. Now if I wanted to change the background color of that application, I’d have to modify a QML file that contains a lot of stuff I’m (as a Designer) probably not interested in. What would be the most elegant way to find a good separation here?

webersin says:

Yes, I humbly bow to the person (nay, coder demigod) that can create a tree model without copying the โ€œSimple tree modelโ€ example and without going mad in the process.

Tomas says:

@mbm: Even though you could mix styling into QML, for any non-trivial application I think this would be a bad idea. I see the situation as entirely analogous to HTML where although you can inline the style with your code, what you really want is separate reusable and shared stylesheets. I think this would allow you for instance to ship the same app to multiple devices with most of the platform, device and theme deltas contained in separate CSS files.

In fact I think QML and CSS would be a perfect match, just not the current static way Qt applies CSS to widgets. You need something much more dynamic, where CSS attributes map to QObject properties of a style container and are automatically applied unless explicitly overridden in QML.

Nils says:

@tomas: That’s exactly my opinion, too.

mbm says:

@Nils, @Thomas
The idea is that you _could_ use QML to describe how components like buttons or combobox should look and behave. That description will then be used when instantiating the component.
This description would be separate from your application UI code (which could also be QML), which uses the components.
I don’t think the idea of using CSS is a bad one. It does look like a good fit, and we should certainly consider it or at least leave an opening for others to add support for it if they want. This is still research, so we will have to see. ๐Ÿ™‚

sigger says:

Not only are there incompatible look and feel specifiers (CSS, QStyle), I have found that CSS slows the UI down a bit. For us, the ideal would be the ability to specify the default look and feel at the application level (which we do via CSS), modify the app level L&F characteristics programmatically and modify instance L&F characteristics. We have to do a lot of dancing around to get at some of the L&F elements (eg reclassing *Styled classes).

I recognize that this is an API in signifiant flux, but an approach that gives access to all elements and provides for app level defaults as well as instance overrides would be greatly appreciated.

Commenting closed.

Get started today with Qt Download now