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.
I worked on the software for a Motorola unit that used Qt UI framework. What is interesting is that Moto moved away from Qt when one of their major competitors (Nokia) bought Trolltech (the company that makes Qt). Two years later they open source it, I don't quite get it...
Maybe now that QT is LGPL, Mathworks will finally transition MATLAB on OS X out of X11 and make it behave like a proper OS X app. ...One can dream....
I have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable. With the way Git works, and particularly with the implementations the hosting companies provide, it's very easy to fork a project, make the changes you want, and always have the power to commit to a remote repository that not only keeps track of all your commits but ALSO how all your commits relate back to the original forked project...
Instead of downloading someone's tarball and (maybe) emailing them a diff (or just posting your own duplicate of their source with your little changes), it's like you're making a shadow copy of a projects source, where you have all the control but no information is duplicated or lost.
Don't blame me, I voted for Baltar.
It does have a certain shitness to the look, for some reason, at least in KDE. I noticed a while back that a bug was fixed in KDE 4 that rendered stuff with too many borders -- so when a widget was inside another widget, or adjoining another widget, they would both render a border. Kind of hoped that would solve the vague cluttered/weird/awkward feel, but it's hard to tell, since KDE 4 went with the horrible Oxygen theme which could make any widget library look like crap. I suspect Qt itself can still look very nice though. I don't mind the look of Google Earth, for instance, and QtDesigner is quite nice in places at least, though simplistic, even WITH it's horrible KDE4-like colors etc.
That said, Qt is way more than than a widget look/theme. It's a very nice OO library for cross-platform GUI (and non-GUI) applications, with modern threading and event-driven programming support, etc. It's one of the few libraries that make me even consider using C++ these days, as opposed to nicer, more rapid languages like python++. I also think that, if GNOME had used a library of similar quality** and similar OO features, then the GNOME desktop, and Free Software in general, would probably be a lot more advanced at this stage.
++ Yes, I know PyQt is available
** Yes, I know that GNOME was a reponse to Qt's early licenses, and that Harmony didn't pan out
Agreed. GNOME is great and all, but I feel it could have gone (and could go) a lot further with a better underlying (and fully OO from the start) library. All the stats I've seen suggest that Qt is much faster than GTK+ (and Cairo) too. The only thing is... I'd hate to lose the GNOME look/feel (especially not in favor of the god-awful KDE4 look and feel), and more importantly, I'd hate to lose Pango. Pango is probably the best thing that ever happened in GNOME.
boost::thread has a different design concept than QThread. I would appreciate if Qt
would introduce a Functor-style API for Threads.
boost::signals doesn't work across threads (this is docuemented in the boost API).
Throwing both Qt and boost APIs together would create an ugly mess.
The only thing holding me back from totally adopting Qt was the outrageous licensing cost, not anything lacking in the toolkit itself. With it having gone to LGPL now, that is no longer an issue.
Same here. Only problem is that one of the major libraries "QtUiTools" is still only available as a static library which means if you use it then your app becomes GPL infected. It's hard not to use it if you use anything that creates GUI resources (eg. Qt Creator).
I would have preferred cheaper licensing rather than going LGPL. Something reasonable like the other major developer toolkits. $300 or so for all platforms. Their current pricing is just obnoxious. Especially for freelance developers like myself, paying nearly $3700 plus, what, $2000 or so per year for a single developer on a single platform is absolutely absurd. At that price I could buy a developer subscription with multiple licenses to practically every single product Microsoft and Apple make combined (including operating systems, databases, developer tools, the whole works). Who do they think they are? I mean shit, they're just providing a GUI API and some cross-platform helper API's.
Almost, but not quite. STL containers tend to be optimized for speed, while Qt containers are optimized for size. There is an old Qt Quarterly that discussed the implementation of Qt's containers what was quite interesting. Go online and search for it.
Don't blame me, I didn't vote for either of them!
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.
As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cause bloat and are rife with non-obvious "undefined behavior" (a byword in the C++ standard).
There are reasons why Qt does not submit to all "foundations for developing C++ code these days".
My exception safety is -fno-exceptions.
What can I say... Qt is becoming a dream platform thanks to Nokia's insight!
- a powerful language/library (C++)
- real cross-platform
- support for embedded and mobile applications (a great alternative for the difficult Symbian C++ language)
- open source and nice licence (LGPL)
- exemplar own IDE but also Eclipse/VS integration
- additional languages supported
What else could one ask?!
"Sum Ergo Cogito"