Slashdot Mirror
Qt Opens Source Code Repositories
sobral writes "Following the announcement of the LGPL license model, since yesterday the Qt source code repositories are open to the public together with their roadmap. The contribution model is online and will enable developers from the community to submit patches through a single click process, avoiding the previous hassle of sending in signed paperwork. The code is hosted at qt.gitorious.org and an instant benefit of this launch is that Qt Software has been working together with Gitorious maintainers for the last four months to improve Gitorious and all these new features are already submitted upstream."
I hope Gnome switches to Qt one day, its so much nicer than GTK.
You must be a bit behind the times as Qt no longer emulates a native look-and-feel but uses the native widgets of the platform.
> I'm at a loss for words.
The word you're looking for is 'too'.
Max.
Symbian is dead? Having 47% of smartphone sales worldwide in Q4 2008 means you're dead? Really?
Yes - because web frontends are the silver bullet that solves all of our client-side needs. In fact, why bother having general purpose computers out side of data centres? Instead we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals. Luckily the infinite bandwidth and uninterrupted global connectivity on offer, combined with the well enforced WWW standards means that even the most complex of GUIs can be provided via the browser. Why do we even bother with proper operating systems when everything man could need from a computer can be provided via a TCP/IP stack and XULRunner?
Oh wait, because even the best web based GUIs are primitive and unresponsive compared to a well designed, well implemented local interface. With Qt it's possible to create a native GUI that runs on all major desktop platform (and even Solaris) with less effort than it takes to get even a moderately complex web interface running correctly on IE, Firefox, Safari, Chrome and Opera.
Web interfaces are excellent for simple tasks like email and feed reading; they are terrible when deployed in more complex arenas. Even when you take in to account proprietary, binary only workarounds like Flash and Silverlight.
Yeah sure...
>> Sales of Linux netbooks collapsed.
Proof? Sure lots of netbooks are Windows, but that doesn't mean sales of Linux models aren't increasing with the market segment.
>> Google is providing a standardized UI on top of Linux.
Incredibly immature project, and isn't even close to a competitor to Qt on anything but embedded.
>> Symbian is dead.
Well, there are millions of devices out there still with Symbian, but I agree it probably has little future.
>> Basically, there is very little need for a specialized UI toolkit like Qt
Qt is not a specialized UI toolkit. It is a general class library for C++ that happens to include UI classes.
>> now that there are both fewer platforms for it to run
Qt runs on more platforms now than ever before. I don't know what you're talking about. Symbian, WinCE, Windows 98 to 7, Linux (normal and embedded), and Mac (with Cocoa even). Name another platform that can do that.
>> and more mature competitors on the remaining platforms.
Like what? Each platform has their own thing, but unless you feel like implementing your interface 5 times, that's not really an option.
Nokia relicensed Qt as LGPL which makes it usable by non-GPL programs.
Do you even lift?
These aren't the 'roids you're looking for.
Qt's collection classes are API compatible with STL. So I would argue that it plays nicely already. I prefer Qt containers to STL containers because Qt's classes have been optimized. STL has some issues with performance.
[ReidNews]
qt 4.5 does have a gtk theme that uses gtk to draw the widgets. It allows me to continue using qt applications and have them match my desktop now that i no longer find kde usable as a desktop. The applications are still 1st rate.
1) replace Qt memory management with TR1::shared_ptr (or boost).
For the core purpose of Qt (GUIs), Qt's various memory models work very well. Every widget is a QObject and by default they fall into parent child releationships that include life-cycle management of your objects. Why would you want to mess up that clean model?
2) replace Qt collections with STL collections.
Another unnecessary generalization. I actually much prefer Qt's collections because A) they are implicitly shared (you can pass them around without getting deep copies) and B) they have one clean and very efficient implementation across platforms, so I don't have to worry about the memory and performance characteristics of a MSVC std::map vs a GCC std::map. Also they are much cleaner to work with and don't require hideous iterators every step of the way.
3) replace Qt threads with boost::threads.
Again, Qt threads will perform as good as native threads on each platform, something you can not guarantee with pthreads (with weaker windows support). Also, QThread and friends (QMutex, QSemaphore, QWaitCondition, QThreadStorage) are very C++ oriented and stylistically much cleaner than pthreads and even go beyond it in scope.
4) replace Qt signals and slots with boost::signals.
This is probably the most valid argument, and there is some legacy reasons why Qt had to throw a meta object compiler on top of C++ to get this to work 18 years ago. But in the mean time, that moc layer has paid off in gold. Now you the ability to get free introspection on classes of your choosing which is vital in making C++ suck less in well designed programs (i.e. can do automatic class instance serialization etc).
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In other words, Qt is a great one-stop-shop for cross platform development and I wouldn't change a single thing you listed. In fact, if you write your C++ code in stylelistic keeping with the Qt libraries, you avoid most of C++'s warts and can even enjoy the language.
As somebody who has just spent the morning trying to work out inconsistencies in wxWidgets between Windows and Linux, let me just say: shush. It's not that wxWidgets is bad, but Qt's we-are-going-to-implement-everything-ourselves-so-it-acts-the-same-on-all-platforms approach has merit.