Qt Opens Source Code Repositories 230
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."
Qt GTK (Score:5, Interesting)
I hope Gnome switches to Qt one day, its so much nicer than GTK.
QT is used on cell phones as well (Score:2, Interesting)
MATLAB on OS X won't suck now? (Score:2, Interesting)
TGI Git (Score:5, Interesting)
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 [github.com]. 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.
Re:QT Looks Like Shit (Score:4, Interesting)
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
Re:Die to unify (Score:3, Interesting)
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.
Re:The first things to do (Score:3, Interesting)
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.
Re:QT is used on cell phones as well (Score:2, Interesting)
Qt had a license exemptions for the major open-source licenses, which makes the licensing situation really confusing. Since one of the exempted license was BSD, arguably their "holey" GPL license is effectively just the LGPL license, since you can write a wrapper around the parts of Qt that you want, BSD-license it, and write a proprietary app that uses it.
On the other hand, unless you jump through these hoops, there will be perfectly fine open-source licenses that are LGPL-compatible (but not GPL compatible) that you cannot use, either because its a minor license that Qt's lawyers have not seen, or because it's too new. It took a while for Qt to be GPL3 compatible, for example.
Re:TGI Git (Score:5, Interesting)
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 [github.com]. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.
However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.
It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.
Re:Should be a followup, actually (Score:1, Interesting)
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.
Re:The first things to do (Score:3, Interesting)
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.
Re:The first things to do (Score:2, Interesting)
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".
Re:MATLAB on OS X won't suck now? (Score:3, Interesting)
Somebody mod this insightful.
There are also incompatibilities with MacOS X. It really is a lot in regards to feel to how Java was circa '98 where you have different versions of wxWidgets and on different platforms really affecting how you have to write the code so that it works right on everything. Also long ago, when they were still wxWindows, they dropped the support of wxX11 and had you use wxGTK on unix-alikes. The wxX11 code stayed so close to working, only little tweaks are needed every now and then, it is a shame that that branch went dead around 2 years ago. The reason is that you need a version of GTK+ on any box running a wxWidgets program now. I have never in recent years been able to compile a static library of what I needed of GTK+ so I could simply link it to the app. You get into real problems where wxWidgets does not work right due to the way that GTK+ was compiled or the version it is on a particular system and I have no good way around that except for gross LD_* overrides in shell scripts. Those libraries are HUGE too.
Qt: a dream platform! (Score:3, Interesting)
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?!