Slashdot Mirror
Novell Desktop To Standardize On Qt [updated]
Balinares writes "NewsForge reports that Novell has settled for Qt as its Linux desktop development environment, casting more light on their strategy to unify KDE and GNOME. This ought to be interesting. The prospect of using Mono to code against Qt makes me drool in advance. Maybe programming will suck no longer!" Update: 03/30 00:01 GMT by T : Sounds like that story doesn't quite hold water; Nat Friedman writes in this Slashdot comment that "We have not decided that we are standardizing on Qt for the desktop. ... We support development with a variety of toolkits, and our internal development is done using the right tool for the right problem. This includes Qt, Gtk, VCL, XUL and others, depending on the application."
I can say that there is nothing easier outside of web development. I am an old MFC programmer. I am often lost in developing Qt apps, but I am very comforatable with that because the documentation is copius cnad clear. Whats more is it is soooooooo well thought out. It makes MFC look like the crap that it is (C++ wrappers for C objects). Learning Qt is like learning to walk the right way. It's amazingly simple. I will always request that Qt be used regardless of platform in future jobs.
Now the license is different. I often wish there was a small-business or starting-business license, but this is only pertanant if you are going commercial work. for GPL work it is completely free.
Right now I'm doing some advanced work with QSA (Javascripted Qt apps) It is easy and cross platform. I can now replace a browser (and the rendering issues with a user interface file (loaded at run-time) and ECMA script code (platform indep. cause we run on various architectures with limited space, whose list may change at any time)
The Troll Tech stuff is top notch.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I personally have been hoping for a while now something like this would happen for the Linux desktop. It's going to take a corporation to step up and unify this effort in order to gain mass acceptance. I'm sure there will be some grumbling in the community, but open source is open so feel free to customize to your hearts content if you don't like it. Most people don't want to have to go to this effor though.
The only potential problem I see is Trolltech's insistance on license fees for commercial development. Not that this is any different in the Windows world, but it'd be nice to give ISVs a completely royalty free solution. I'd like to see Novell take that $50 million that IBM gave them and purchase TT outright and put Qt under a more liberal open license. The wording on the KDE Free Qt clause seems a bit unclear to me. Does Qt get automatically BSD'ed when any company buys Trolltech. What if the purchasing company doesn't make the license any more closed that currently, does that have an effect.
Anyway, I've never understood the reasons people chose to write a whole desktop environment in straight C. C++ just seems a far more natural fit. I've looked over both GNOME and KDE fairly extensively, and there is no doubt in my mind that KDE has a cleaner code base and architecture. With all the "higher level language" rumblings going on in the GNOME community, I suspect that those developers are hitting a brick wall in terms of where they want to go and what the current code is capable of becoming. That sort of thing isn't happening in the KDE world, so I think that speaks volumes.
Good luck Novell, you've got at least one supporter here.
-- Fighting mediocrity one bad post at a time.
Heh heh... Even now I can picture Balmer rubbing his fat little hands together and giggling gleefully. Micorsoft's fondest hope is that a good chunk of open source software will come to depend on mono before they play the patent card. Assurances that Microsoft would "just never do such a thing", somehow leave me unconvinced. ...and I'm sure someone will tempted to respond with the "but, but C# is a standard!" line too - don't bother, just submitting the "standard" in no way prevents Microsoft from enforcing related patents anytime they choose.
Regardless of NET's good or bad points, it's a potential legal land mine for open source that could make the SCO fiasco look postiviely quaint. Unlike SCO, Microsoft would have an actual case.
Well, it appears that it was actually SuSE, with their Trolltech connections, that took over Novell, and not the other way around.
And if we are not careful, Trolltech is going to end up controlling Linux. [We also need to consider the possibility of a backroom deal between Trolltech and Microsoft, similar to the deal between Microsoft and SCO.]
The danger, of course, is not the GPL'd version of Qt. KDE is also not a problem. Both of those are Open Source, so we don't have to worry about them, and I have no reason to talk about them.
The real danger of Trolltech is the proprietary version of Qt and the applications that depend on it.
Or, in more general terms, the danger is proprietary middleware.
Let's look at an example from history. Remember when the PC platform was open, from bottom to top? Remember when you could not only buy the hardware from any number of vendors, but there were also competing vendors for the BIOS, there was more than one windowing architecture (Gem, Geoworks, Borland's GUI libs,...), and there were dozens of development environments, and thousands of code libraries? Remember when standards were simple, when it was easy to write code to interface directly with printers, with video cards, and so on?
What happened? Microsoft introduced Windows.
After a while, Windows became an indespensible component of the PC. Applications depended on it, and hardware manufacturers had to support it. And there was only one supplier of the Windows component, namely, Microsoft.
Soon, Microsoft started using its control of Windows to make itself the winner in the applications market. And today, Microsoft (with a few accomplices) also dictates the standards for PC hardware, its BIOS, its peripherals, and its network protocols.
What was special about Windows? It was proprietary middleware!
Windows sat in the middle, in between the applications and the PC. Any applications that wanted to access PC hardware used (and became dependent on) Windows APIs. And any PC manufacturer that wanted applications had to support Windows APIs. Bill Gates once said that by controlling the APIs, he controlled the industry.
Likewise, PC users became locked in. They could replace their hardware. They could replace an application. But they couldn't replace Windows. As the PC became cheaper, Windows became more expensive, as did the Microsoft applications that Windows "encouraged" users to use.
The proprietary version of Qt is just like Windows. It is proprietary middleware. It sits between the applications and Linux. The applications that use Qt are dependent on its APIs. And if Linux wants to be able to run those applications, then it has to support Qt.
What applications are we talking about? Applications like Kylix, Hancom Office, Opera, the professional versions of Quanta and Rekall and various other TheKompany products, ATI's setup utility, Quasar Accounting, Adobe Photoshop Album, and so on. If a Linux distribution wants to be able to run those applications, then it must support the proprietary version of Qt.
So how bad is it? Has Linux been taken over by proprietary middleware, the way the PC was taken over by Windows?
In other words, Have we reached the point where the proprietary version of Qt, with its single supplier, is an indedpensible component of Linux?
If this article is correct, and Novell is standardizing on Qt as the foundation of its desktop and development environment, then things are very bad.
Others have also argued that it has become almost impossible to have Linux without proprietary Qt...
In their paper Conquering the Enterprise Desktop, a group of developers argued that Bruce Perens' UserLinux would have trouble succeeding, unless it included the Qt Library in its basic install. Were those developers just talking about the GPL'd version of Qt? No, as shown by these statements: