Submitted by Nokia has released the latest version of its cross-platform toolkit Qt, version 4.6. As usual, it comes with a whole slew of improvements and new features, and this time, they even added a new platform into the mix.
The improvements in Qt 4.6 can be summed up as more platforms, more eye candy, more fingers, and more horsepower. Qt 4.6 adds support for the Symbian platform, and obviously also gains support for Mac OS X 10.6 Snow Leopard and Windows 7. In addition, community support is available for the real-time operatig systems QNX and VxWorks. Meamo 5 is on the way, with its second technology preview released today.
Eye candy-wise, Qt 4.6 gets the Animation Framework, which includes “intuitive state machine functionality”, as well as new graphical effects such as opacity, drop shadows, glow, and filtering. Qt 4.6 also comes with multitouch support, providing the ability to, among other things, flick and scroll kinetically.
As far as performance goes, the Qt GraphicsView rendering algorithm has been rewritten, but 4.6 also receives a new OpenGL paint engine, WebKit, 2D vector graphic support using OpenVG, and new DirectFB support.
“Qt 4.6 marks an exciting time for developers, regardless of their target form factor or platform,” said Sebastian Nystr~APm, Vice President, Application Services and Frameworks at Nokia, “Developers can easily create visually appealing and web-connected applications for desktops or devices, including targeting the hundreds of millions of Symbian and Maemo-based devices. The community will enjoy using Qt’s intuitive programming interface to quickly create powerful, appealing applications.”
You can get Qt from its website.
This means more animated, pretty, and stable KDE releases!
Man how I wanted an elegant desktop environment written in Qt. It’s kind of sad liking Gnome but hating Gtk, and loving Qt and hating KDE mentality of “complex is good” or “if doesn’t have 451 buttons it isn’t good”.
“if doesn’t have 451 buttons it isn’t good”.
You seem to be talking about a different KDE than the one I’m using…
I actually like GTK. In my limited experience, in GTK, more typing is involved, but things make more sense and it’s easier to get things right. In particular, I like how containers (that provide layouts) are widgets themselves, meaning that you can put a complex layout with multiple widgets in it anywhere that you could put a single widget. That’s not true in Qt (at least, not without a little extra work): there, layouts are a separate entity from widgets. This bit me recently trying to create a push-button in Qt that could accommodate arbitrary child widgets and layouts: that’s just there in GTK, but I had to sub-class QFrame in Qt and override the mouseReleaseEvent (which got the job done, save for the minor quibble that the result doesn’t look like a normal QPushButton).
Having said that, Qt is probably a much easier toolkit to use, and C++ facilities are pretty handy for adding new functionality to widgets. It kinda makes me want to try gtkmm.
I think you may be misunderstanding something here. You can instantiate a QWidget (not subclass, just instantiate), set a layout on it, then add your child widgets there. The resulting QWidget can be used as you would use the layout object in Gtk, i.e. you can add it as a “single” widget to a place that accepts a single widget (e.g. another layout).
You can find 2 source snippets that do just this here:
http://qt.nokia.com/doc/4.6/layout.html#laying-out-widgets-in-code
Of course you could trivially create your QVBoxWidget that does what you want (i.e. avoid the single setLayout call), but I think you’ll agree that it wouldn’t really help things :-).
While that is true, something about that approach just doesn’t sit with me: I find treating containers as widgets to be more… elegant and orthogonal, I suppose. I think that model is just more elegant and flexible, and is easier for me to keep track of and reason about.
QWidgets are containers are widgets. The layout (given by setLayout) just specifies how they should be sorted inside the container.
I don’t know if either way is better/worse than the other. I guess the Gtk way involves one moving part less, but the difference is negligible (i.e. I feel like we are bikeshedding here ;-).
No disagreement! I don’t think that Qt is doing anything wrong by having Layouts and Widgets be separate things, I just like the gtk way better, and find it more intuitive. It’s entirely a question of personal preference.
Qt 3.x series did support widgets that were both containers and layouts. They dropped the design because developers were finding it confusing and unnecessary.
Normally you would insert a widget and set the layout inside that widget to get the behaviour you describe.
I’m curious why you wanted this? A huge button with arbitrary widgets inside? How would that even work if those widget should interact with input? Push buttons accept images and text, I don’t think you should be putting other widgets inside one.
Heh, well, partly because we didn’t want them to look like QPushButtons: we just wanted images you could click on, without the border or background-gradient. (So, when I complained that they “didn’t look like QPushButtons,” what I guess I should have said was, “most of QFrame’s borders where too ugly to use.”) Also, for whatever reason, when I used QPushButtons, they didn’t size themselves properly (I think: they didn’t show up, and my theory at the time was that they where requesting a zero size allocation, for some reason).
Stylesheets can come in handy for cases like this:
http://doc.trolltech.com/4.6/stylesheet-examples.html#customizing-q…
At least you can customise it, unlike another DE I could mention, which removes customisation on just about every release.
I’d rather customise and disable what you want than virtually no custimsation at all(an OS and DE come to mind).
Just read this: http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in…
Man how I wanted an elegant desktop environment written in Qt. It’s kind of sad liking Gnome but hating Gtk, and loving Qt and hating KDE mentality of “complex is good” or “if doesn’t have 451 buttons it isn’t good”
Darn. Couldn’t have said it much better myself; I love how smooth the animations are in KDE and how much more advanced Qt feels compared to GTK+, but I just really hate how every KDE app includes a gazillion menu entries, buttons, layouts, heck, they seem to be stuffing the whole kitchen sink in there, too.
Oh well, this isn’t a KDE thread though. Good thing to see Qt getting improvements, might be worth learning to use it myself too someday.
“i dont use this feature so nobody else should!”
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away…
this is what you are saying, you do realize this?
“i dont use this feature so nobody else should!”
on a related note, i just really hate how everyone stuffs the world with their children(aka you), which i cant use for anything.. please.. have them go away…
this is what you are saying, you do realize this?
Nope, it’s not. To copycat you, I could just as well state: “on a related note, i just really hate how no one ever has enough stuff with them all time time, i really need first aid kit, full toolbox, kitchen sink, vacuum cleaner, 12 different screwdrivers, canister of gasoline and a toolshed with me every time i do something as simple as drink coffee”
Exaggerating things is fun, isn’t it? Oh, and it _clearly_ makes my post look mature and well-presented, doesn’t it?
Point of philosophy here: I like to have a toolshed. It could well include a “first aid kit, full toolbox, kitchen sink, vacuum cleaner, 12 different screwdrivers and canister of gasoline”.
If I want to drink a cup of coffee, I don’t go into the toolshed to do so.
That does not mean that I don’t want a toolshed at all. I’m not one to just drink coffee all the time.
The problem isn’t just having a tool-shed or not, it’s how well-organized the tool-shed is, and how easy it is to find the tool you want at any given time. It’s fine to have lots of advanced and powerful features, but they need to be presented in such a way that the application remains easy to use in the likely-more-common simple use cases. Advanced features shouldn’t be in the way.
That, I suppose, is my biggest problem with KDE. All that complexity might not be a bad thing in and of itself but. typically, I find that the abundance of options and features are not managed well, which can make it difficult to get into KDE (and KDE apps) and start using them for simple tasks. I really dread having to wade through four or five long, similarly-named option panels trying to find the one setting that I actually want; that happens to me a lot, when I try to use KDE.
Edited 2009-12-02 16:00 UTC
Oh yes, that’s obviously what he is saying. What a remarkable non sequiter. What are you, twelve?
I think people on open source community should starting studying design.
http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in…
Too bad QML wasn’t ready yet for this release. When they finish it we will have a killer tool for developing more interactive user interfaces. Hell, even designers can program in QML
My (quite limited) experience with QML is that it’s easier to get blingy UI’s (with lots of animations etc), but for doing simple things just using Qt “normally” (C++/python, QWidgets, normal layouts…) is much easier.
This is because QML provides a lower level access to the dynamic state of the UI, whereas with the classical Qt style you can just slap an UI together with a Qt Designer. The UI won’t be quite as appealing, though.
Of course we are still to see how the UI designer for QML will be like; it might be as easy as using Qt Designer currently is.
Well actually I was said that a designer tool for QML is on the works. Indeed, if you think about it, it matches perfectly with vector graphics tools IMO.
From the looks of it, QML is to QT what XAML is to .NET and WPF. Disregarding the “.NET sUxX0Rz” mentality, as I believe most languages and platforms have their own merits, would this a fair comparison?
Not really. XAML is more like the classical .ui file format that is emitted by Qt Creator. QML files contain behavior as well as presentation.
You can basically write your whole UI-heavy program as a set of QML files (which can contain javascript), event handlers and all.
Check out
http://kenneth.christiansen.googlepages.com/DUI.html
So for PySide support we’d have to wait for a stable release of PySide, but why not get PyQt support in Creator?
The benefits of using Qt Creator (esp. autocomplete) are greatly diminished when writing Python (or other dynamic languages).
OTOH, I can see some real benefit of providing entry-level python support (syntax highlight, autoindent, source navigation and possibly scintilla level autocomplete) in Qt Creator. Qt Creator has a plugin system, it’s probably just a matter of someone picking up the slack and starting to build the support (which should be possible for people outside Nokia as well).
Frankly, I think it’s just a matter of time before it happens.
I thought that PySide and PyQt both had the same API. Doesn’t that in turn mean that support for one is support for the other?
Sorry to nitpick, but this article has more (very obvious) typos than any OSAlert articles I have ever seen:
operatig -> operating
Meamo -> Maemo
http://arstechnica.com/open-source/news/2009/12/qt-gets-cuter-46-br…
Community:
Performance & QtScript:
Did they fix rendering speed for running X remotely or for running remote terminal sessions on windows? This all started with qt4. Maybe one of these decades that will be dealt with.
AFAIK that’s because of the default theme being more complex. Change to a minimal theme without gradients, pixmaps and effects and it should be as fast as Qt 3.
A much better option is to use NX instead of plain old remote X or VNC though. It’s so much faster it’s not even in the same league.
Well, bringing up an image chip from a 4MP camera, selecting some lines and point measurements results in saturating a gigabit connection for .5s or longer bursts (~40mb/s). Doing the same thing in a fltk program I get acceptable performamce over a 1/4 T1 line internet connection (only image navigation is slow,measuring is faster). QT’s problem: excessive chatting chatting between the server and client because of all the QGraphicsView stuff. Note this is a also problem with windows remote terminal.
Running vnc (or rdesktop) does help with this because all the composting is done on the server only and screen updates are transferred.
The easy answer has been to not use Qt but any number of non over engineered toolkits. Comments from customers is that the non qt stuff feels amazingly faster. And build management is much easier.
You don’t need to use QGraphicsView.
Plasma does, so you’ll get the hit, but your application certainly doesn’t need to.
. In addition, community support is available for the real-time operating systems QNX and VxWorks.
I am confused, what is that supposed to mean? Isn’t VxWorks for embedded systems only? I am not aware of a VxWorks with a GUI. Excuse my ignorance but can someone please clarify this?.
Edited 2009-12-02 10:45 UTC
VxWorks can have a GUI. Not every VxWorks system will have one, but it’s possible. IMHO it’s a good move to have QT available to embedded systems.
There are several X11 versions for VxWorks, and you can always use Qt Embedded, which comes with its own windowing system + compositing window manager, independent of X11.
This leaves me with 2 questions open to discussion:
Does this mean we are going to have to rebuild Qt4-QtRuby again from scratch?
How is this going to affect KDE 4.4?
Yes, you may not need to recompile QtRuby when changing to Qt 4.6, but it wouldn’t do any harm. It would certainly be a good idea to regenerate and rebuild the smoke bindings libraries that QtRuby uses.
Well as KDE 4.4 depends on Qt 4.6, and so it means that in can actually be released
As far as QtRuby is concerned, the big change for the KDE 4.4 release will be that the Smoke libraries will be generated with Arno Rehn’s C++ based generator, instead of the perl one that previous releases used.
Also the Smoke libs for Qt 4.6 and the corresponding Ruby extensions will be split up so that there is one per Qt module – ie one qtcore, qtgui, qtnetwork etc instead of everything being in a single ‘qtruby4’ extension. That will mean if you only want to write a ruby app using QtCore stuff it won’t pull in all the Gui classes.