Linked by Thom Holwerda on Tue 1st Dec 2009 19:03 UTC, submitted by poundsmack
Qt 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.
Order by: Score:
KDE
by lunarcloud on Tue 1st Dec 2009 19:11 UTC
lunarcloud
Member since:
2008-04-28

This means more animated, pretty, and stable KDE releases!

Reply Score: 6

RE: KDE
by puelocesar on Tue 1st Dec 2009 19:16 UTC in reply to "KDE"
puelocesar Member since:
2008-10-30

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".

Reply Score: 3

RE[2]: KDE
by diegocg on Tue 1st Dec 2009 19:56 UTC in reply to "RE: KDE"
diegocg Member since:
2005-07-08

"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...

Reply Score: 14

RE[2]: KDE
by boldingd on Tue 1st Dec 2009 20:06 UTC in reply to "RE: KDE"
boldingd Member since:
2009-02-19

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.

Reply Score: 4

RE[3]: KDE
by vivainio on Tue 1st Dec 2009 20:47 UTC in reply to "RE[2]: KDE"
vivainio Member since:
2008-12-26

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.


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 :-).

Reply Score: 4

RE[4]: KDE
by boldingd on Tue 1st Dec 2009 21:07 UTC in reply to "RE[3]: KDE"
boldingd Member since:
2009-02-19

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.

Reply Score: 2

RE[5]: KDE
by vivainio on Tue 1st Dec 2009 21:36 UTC in reply to "RE[4]: KDE"
vivainio Member since:
2008-12-26

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.


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 ;-).

Reply Score: 5

RE[6]: KDE
by boldingd on Tue 1st Dec 2009 21:39 UTC in reply to "RE[5]: KDE"
boldingd Member since:
2009-02-19

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.

Reply Score: 2

RE[7]: KDE
by Chicken Blood on Tue 1st Dec 2009 22:22 UTC in reply to "RE[6]: KDE"
Chicken Blood Member since:
2005-12-21

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.

Reply Score: 4

RE[3]: KDE
by leos on Tue 1st Dec 2009 21:16 UTC in reply to "RE[2]: KDE"
leos Member since:
2005-09-21

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.


Normally you would insert a widget and set the layout inside that widget to get the behaviour you describe.

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).


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.

Reply Score: 5

RE[4]: KDE
by boldingd on Tue 1st Dec 2009 21:36 UTC in reply to "RE[3]: KDE"
boldingd Member since:
2009-02-19

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).

Reply Score: 2

RE[5]: KDE
by vivainio on Tue 1st Dec 2009 21:51 UTC in reply to "RE[4]: KDE"
vivainio Member since:
2008-12-26

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.


Stylesheets can come in handy for cases like this:

http://doc.trolltech.com/4.6/stylesheet-examples.html#customizing-q...

Reply Score: 4

RE[2]: KDE
by SlackerJack on Tue 1st Dec 2009 21:08 UTC in reply to "RE: KDE"
SlackerJack Member since:
2005-11-12

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).

Reply Score: 4

RE[3]: KDE
by puelocesar on Wed 2nd Dec 2009 13:20 UTC in reply to "RE[2]: KDE"
puelocesar Member since:
2008-10-30
RE[2]: KDE
by WereCatf on Wed 2nd Dec 2009 00:16 UTC in reply to "RE: KDE"
WereCatf Member since:
2006-02-15

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.

Reply Score: 4

RE[3]: KDE
by Redeeman on Wed 2nd Dec 2009 00:49 UTC in reply to "RE[2]: KDE"
Redeeman Member since:
2006-03-23


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.

"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?

Reply Score: 1

RE[4]: KDE
by WereCatf on Wed 2nd Dec 2009 03:15 UTC in reply to "RE[3]: KDE"
WereCatf Member since:
2006-02-15

"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?

Reply Score: 4

RE[5]: KDE
by lemur2 on Wed 2nd Dec 2009 03:50 UTC in reply to "RE[4]: KDE"
lemur2 Member since:
2007-02-17

"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.

Reply Score: 4

RE[6]: KDE
by boldingd on Wed 2nd Dec 2009 15:56 UTC in reply to "RE[5]: KDE"
boldingd Member since:
2009-02-19

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

Reply Score: 2

RE[4]: KDE
by Chicken Blood on Wed 2nd Dec 2009 04:13 UTC in reply to "RE[3]: KDE"
Chicken Blood Member since:
2005-12-21

"
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.

"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?
"

Oh yes, that's obviously what he is saying. What a remarkable non sequiter. What are you, twelve?

Reply Score: 2

RE[4]: KDE
by puelocesar on Wed 2nd Dec 2009 13:17 UTC in reply to "RE[3]: KDE"
puelocesar Member since:
2008-10-30

I think people on open source community should starting studying design.

http://www.smashingmagazine.com/2009/10/07/minimizing-complexity-in...

Reply Score: 0

QML
by puelocesar on Tue 1st Dec 2009 19:22 UTC
puelocesar
Member since:
2008-10-30

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 ;)

Reply Score: 1

RE: QML
by vivainio on Tue 1st Dec 2009 20:22 UTC in reply to "QML"
vivainio Member since:
2008-12-26

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.

Reply Score: 2

RE[2]: QML
by puelocesar on Wed 2nd Dec 2009 10:47 UTC in reply to "RE: QML"
puelocesar Member since:
2008-10-30

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.

Reply Score: 1

RE: QML
by CodeMonkey on Wed 2nd Dec 2009 17:02 UTC in reply to "QML"
CodeMonkey Member since:
2005-09-22

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?

Reply Score: 2

RE[2]: QML
by vivainio on Wed 2nd Dec 2009 17:16 UTC in reply to "RE: QML"
vivainio Member since:
2008-12-26

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

Reply Score: 3

PySide or PyQt support in Creator
by FunkyELF on Tue 1st Dec 2009 19:45 UTC
FunkyELF
Member since:
2006-07-26

So for PySide support we'd have to wait for a stable release of PySide, but why not get PyQt support in Creator?

Reply Score: 2

vivainio Member since:
2008-12-26

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.

Reply Score: 2

lemur2 Member since:
2007-02-17

So for PySide support we'd have to wait for a stable release of PySide, but why not get PyQt support in Creator?


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?

Reply Score: 2

A few typos...
by Zifre on Wed 2nd Dec 2009 00:05 UTC
Zifre
Member since:
2009-10-04

Sorry to nitpick, but this article has more (very obvious) typos than any OSNews articles I have ever seen:

operatig -> operating
Meamo -> Maemo

Reply Score: 1

lemur2
Member since:
2007-02-17

http://arstechnica.com/open-source/news/2009/12/qt-gets-cuter-46-br...

Community:

Nokia relicensed Qt under the more permissive Lesser General Public License (LGPL) and moved all active development to public source code repositories in an effort to encourage broader community participation in the development process.

The more inclusive development model has succeeded in boosting involvement. Nokia says that Qt 4.6 is the first major release of the toolkit to include a significant amount of code contributed by the third-party developers. In a post made today at the official Qt blog, Nokia expressed appreciation to the community for the role it played in building the new version of the toolkit.

"When we opened Qt up for easier contributions back in May we were unsure what to expect. Would anyone care? Would anyone contribute?" wrote Qt spokesperson Aron Kozak. "Well we are extremely pleased to say that indeed you did contribute. We have received roughly 500 contributions for Qt and Qt Creator since we launched this initiative, and of those, around half made it into the 4.6 release."


Performance & QtScript:
Performance optimization work on Qt is also an important ongoing effort. One of the most important changes in that area for Qt 4.6 is the adoption of WebKit's extremely fast JSCore engine for QtScript, the ECMAScript-based scripting language that Qt provides for application extension. QtScript used to have its own interpreter implementation, but now it can benefit from the performance advantage of having JSCore's JIT backends. This dramatically increases QtScript execution speed, as demonstrated in standard benchmarks. At the recent Maemo Summit, I learned that Nokia funded the development of a JSCore JIT backend for ARM, which means that these performance optimizations will even be available on mobile devices.

Another exciting improvement for WebKit integration in 4.6 is the availability of a new DOM access API that is modeled after the popular JQuery library. You can use CSS selectors to iterate over nodes in an HTML document. A small but very nice addition is the new clearMemoryCaches method for the QWebSettings class, which will make it possible to mitigate the massive memory overhead that typically comes with using an HTML renderer in a desktop or mobile application.

Reply Score: 4

remote displays?
by bnolsen on Wed 2nd Dec 2009 05:02 UTC
bnolsen
Member since:
2006-01-06

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.

Reply Score: 3

RE: remote displays?
by Tuxie on Wed 2nd Dec 2009 07:27 UTC in reply to "remote displays?"
Tuxie Member since:
2009-04-22

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.

Reply Score: 4

RE[2]: remote displays?
by bnolsen on Wed 2nd Dec 2009 13:36 UTC in reply to "RE: remote displays?"
bnolsen Member since:
2006-01-06

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.

Reply Score: 2

RE[3]: remote displays?
by vivainio on Wed 2nd Dec 2009 15:29 UTC in reply to "RE[2]: remote displays?"
vivainio Member since:
2008-12-26

QT's problem: excessive chatting chatting between the server and client because of all the QGraphicsView stuff.


You don't need to use QGraphicsView.

Plasma does, so you'll get the hit, but your application certainly doesn't need to.

Reply Score: 3

Re: VxWorks
by OSGuy on Wed 2nd Dec 2009 10:44 UTC
OSGuy
Member since:
2006-01-01

. 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

Reply Score: 2

RE: Re: VxWorks
by gnottage on Wed 2nd Dec 2009 12:24 UTC in reply to "Re: VxWorks"
gnottage Member since:
2009-12-02

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?.


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.

Reply Score: 2

RE: Re: VxWorks
by harryF on Wed 2nd Dec 2009 12:44 UTC in reply to "Re: VxWorks"
harryF Member since:
2005-07-06

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.

Reply Score: 2

QtRuby? KDE4.4?
by hibridmatthias on Wed 2nd Dec 2009 14:39 UTC
hibridmatthias
Member since:
2007-04-11

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?

Reply Score: 1

RE: QtRuby? KDE4.4?
by Richard Dale on Wed 2nd Dec 2009 14:59 UTC in reply to "QtRuby? KDE4.4?"
Richard Dale Member since:
2005-07-22

Does this mean we are going to have to rebuild Qt4-QtRuby again from scratch?


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.

How is this going to affect KDE 4.4?


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.

Reply Score: 4