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."
Re:Should be a followup, actually (Score:4, Insightful)
Re:Should be a followup, actually (Score:5, Insightful)
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.
Re:I'm at a loss for words. (Score:5, Insightful)
Re:Die to unify (Score:2, Insightful)
The first things to do (Score:5, Insightful)
1) replace Qt memory management with TR1::shared_ptr (or boost).
2) replace Qt collections with STL collections.
3) replace Qt threads with boost::threads.
4) replace Qt signals and slots with boost::signals.
In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.
Re:Should be a followup, actually (Score:4, Insightful)
You have to understand the "ABC is dying/dead" mentality.
It doesn't matter how much market share you have, only that your market share is decreasing and some smaller technology which they favor has an increasing market share.
IE is dying because Firefox use is increasing in the market and IE is declining.
Unix is dying because Linux is growing and Unix is not.
It doesn't matter that at the rate of decline it would take 20 or more years for whatever it is to die. Or that the decline may be arrested. Saying something is dying is usually misinformed or more likely spreading FUD to hasten the decline.
Old technology with 80% market share drops down to 79% marketshare and new cool technology jumps up from 2% to 3% market share and old technology is declared dying. Here's a perfect example [cnet.com].
Re:The first things to do (Score:5, Insightful)
Re:Die to unify (Score:5, Insightful)
Just to clarify :
Nokia acquired TrollTech.
Nokia then decided to license QT under the LGPL, it wasn't a decision made by TrollTech while they were still independent
Re:The first things to do (Score:3, Insightful)
But then again. (only) You know your own usage scenario, data types and platform. That knowledge can probably offer some profound short cuts and optimizations.
Re:The first things to do (Score:5, Insightful)
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.
Re:MATLAB on OS X won't suck now? (Score:5, Insightful)
Re:The first things to do (Score:2, Insightful)
not a troll (Score:5, Insightful)
What reactionaries are modding this "troll"? It's a perfectly valid comment, for anyone who has actually sat down and compared the libraries. Also, it's a perfectly reasonable issue to consider, now that both desktops' core libraries share common licenses and have essentially become interchangeable. Yes, that interchange would involve hard work, which may lead reactionaries to reject it, but what progress doesn't involve hard work? It would at least be nice to see a study of some GNOME app re-implemented in Qt, and what the pros/cons are. I know for a fact that at least a few apps have have been ported from GNOME to Qt (Qt3, though, I think), and probably some have been ported the other way too. Even just those historical cases with Qt3, the case study would be interesting.
Re:Die to unify (Score:5, Insightful)
Interested rewrite of history. But it's not true. GNOME didn't drive Trolltech to open source Qt, KDE did. GNOME wasn't (and still is not) using Qt, so why should have Trolltech cared about their whines? It was KDE developers advocating for real open source that did it.
Re:Should be a followup, actually (Score:5, Insightful)
The problem is deployment and support. As much as Javascript is a pain, non-standard HTML support in IE is a pain, and a million other headaches come with a website, in many ways it's far less headache than supporting a
There's certainly a wide range of applications that will always remain fat client only. But the terminal-server model makes a lot of sense from the support perspective for many applications.
Re:QT Looks Like Shit (Score:3, Insightful)
Kubuntu is not a decent version of KDE. Or KDE really sucks.
If they put half the time into kubuntu that they put into ubuntu it could become a great operating system.
Re:Should be a followup, actually (Score:2, Insightful)
Websites cannot be definitely superior and unusable in certain situations. As it is they are not definitely superior as anything that can be done on a website can be done using a local client. However not everything that a local client can do is possible on a website (unless you start using embedded applications and turning the web page in to a local client within a web browser frame).
I also take issue with the implication that all local clients are fat clients. It's perfectly possible to have a system with a thin, locally hosted GUI and a much larger server backend. You can even use HTTP to communicate between the two. The use of a local GUI in such situations gives you (the software designer/programmer) much more control over the user experience. Your well-crafted UI isn't going to fall apart because a user has decided to use Chrome or the latest version of Safari has introduced a rendering bug.
To repeat my original post: web interfaces have their place but they are not a replacement for properly implemented local GUIs. For something that is relatively simple and for which the zero installation benefit of the web outweighs the downsides, an HTML/Flash/Javascript interface is the way to go. That not withstanding, the functionality available to the local GUI designer is a superset of that available to the web designer. The local GUI isn't limited to HTTP as a transport mechanism. The local GUI isn't subject to vagaries of browser "standards" compliance and to crash briefly back on topic; there is no web UI toolkit that approaches Qt for ease of use, cleanness of interface or cross platform functionality.
Re:Should be a followup, actually (Score:3, Insightful)
None of those run on as many platforms as Qt does. And all of them look out of place on all the platforms they run on (except for SWT, which looks ok on Windows and Gnome, but runs badly on Linux).
Re:QT Looks Like Shit (Score:1, Insightful)
Sory we can't make every one happy, we worked very hard in Oxygen to make it pretty and usable, many people find it so, and it was the qt software that made it possible.
The fact that you find it ugly, it is compensated by the fact that many, many, others dont.
Its not a finished joob I think it will never be but we do our best, and I think its a fantastic start.
Yours Nuno Pinheiro Oxygen coordinator