Slashdot Mirror

• Myth: KDE is more integrated than GNOME
  
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac.

• Myth: KDE is easier to use
  
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. What about application (see GNOME apps later) installation and removal: GNOME has the excellent RedCarpet by Ximian , which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase... which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post on a zealot-ridden site can reduce the result to a running joke. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system - and indeed, can co-exist except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead. Both Hewlett- Packard and Sun Microsystems have committed to using GNOME as the desktop for their Unix systems. This ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME effort is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror is a fine piece of software - it's authors deserve plently of praise - it is, however, quite unreliable and lax in its support of basic web standards compared to either Mozilla or Opera . It is also extremely slow - slower than the latest incarnations of the GNOME Nautilus filemanager/browser.

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  
  Reality: See also: Qt/TrollTech. Easily the most common wail heard by KDE developers - and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt . KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2. GNOME applications wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet ,X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade , Anjuta . All of these packages ooze quality, far outclass and are, at least, 18 months ahead of their KDE/Qt counterparts. It's not only in the area of user applications that GNOME is lightyears ahead, with the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo ), media (Gstreamer ), internationalisation (pango ). As a developement platform, GNOME 2.x is, frankly, years ahead of KDE. And what's more, it is not tied to a lowest common denominator cross-platform bloat-fest like Qt. Yet despite all this, we are still fed the lie that Qt and C++ makes development easier. Judge for yourself.

• Myth: KDE is faster and/or takes less memory than GNOME
  
  Reality: KDE is written in C++. While this is not necessarily a bad thing, it is when the programmers do not know enough to avoid certain pitfalls that can plague software projects. Stupid use of ++/-- with C++ objects; masses of unnecessary allocations and deallocations of memory, and the most cretinous of all, blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the KDE architecture and basic design.

• Myth: GNOME development is slower. KDE releases faster.
  
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the consequent problems with libraries. It bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version. Occasional releases of the entire GNOME system are done, and that's when the GNOME version number is bumped (currently it is 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  
  Reality: Qt started out as non-Free. KDE developers knew this violated the GPL and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Labyrinthine licensing nightmare.

• Myth: Most good GNOME apps are actually GTK applications.
  
  Reality: Most KDE apps, such as those from The Kompany are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

• Myth: KDE is attractive/GNOME/GTK is ugly
  
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

QPL was a Free (as defined by the FSF) license, just not GPL-compatible

The QPL was not the original licence. QPL didn't come along until 1999. The original Qt licence is very non-free - there are restrictions on even using it to create (not distribute) software, there are special restrictions if you're getting paid to develop software, and so on.

However, even with QPL the problem still exisited that a lot of KDE code was released under the GPL, and the authors hadn't explicitly allowed linking with non-GPLed code. That was RMS's concern from the QPL until until the GPL dual licencing.

Please try to get your facts straight. Five minutes with Google can keep you from looking like a fool.

Linux people do buy software. Myself, I recently bought Eagle and Qt (commercial license).

The problem is with products themselves. It is virtually out of question to buy WP into an office that is built around MS Word or StarOffice formats. CorelDraw may be good, I used it very long time ago, but Corel is dwarfed by rows and rows of Adobe products; basically Adobe Illustrator is the #1 in vector graphics, while Adobe Photoshop became a de-facto standard (and a platform) for raster images. Corel lost the market on its own, and Linux sales, targeting new customers, only reflect that.

Trolltech Releases Qt/Mac, OS X ( 15. Oct 2001 ) - Oslo, Norway - With its release of Qt/Mac, Trolltech has added Apple Macintosh to the list of platforms supported by Qt, an emerging industry standard in cross-platform software development. Application developers using Qt can now target Mac OS X with the same ease, as they are currently targeting Windows, Linux, Unix, and embedded Linux systems. Qt allows developers to create a single source tree that will run on all these major platforms.

Keep in mind that like anything else, in software development you need the right tool for the right job. If your looking to create a cross-platform application with a mature and well supported tool-kit, then I would say look at the Qt cross-platform application framework library from Trolltech. Most people here will be most familiar with Qt as the library that KDE was built with. If you are coming from a Win32 background, Qt can be compared somewhat to MFC. Except Qt is MUCH MUCH easier to use (I've been part of a couple large projects that used MFC, so I understand it's many pitfalls). Qt is portable across Windows, Linux, and Mac. It's on version 3.0 so it's mature. It has a free evaluation version, so download it and give it a try. For Linux (I've only used the linux version so I don't know if there is a Windows version, I've never looked into it) there is a GUI IDE that makes application programming using Qt with C++ just like Visual Basic. In so far as, you drag and drop your controls onto your template app, then add event haddlers and whatnot.

Now... let's discuse my consulting fees.
Treknetix, for all your coding needs

That's your whole list.

intuitive and easy to use IDE; simplified GUI design and event handling; advanced error handling; advanced object oriented design including multiple inheritance, abstract classes, and garbage collection; full support for operator and function overloading; and portable (at compile-time) across various platforms. I have already looked at C++, Java, C++, C#, Eiffel, and even VB.net;

Let us take a look at how C++ compares.

Intuitive, easy-to-use UI, check. This is a stupid requirement for a language, though, as any reasonable language should allow your choice of UIs. I've used Visual Studio for C++ as well as emacs and, currently, KDevelop, which I like quite a lot.

Simplified GUI design and event handling. C++ does not determine how GUIs are handled but we use Qt which works very well for what we want. Visual Studio lets you do GUI design inside of it, as does Borland C++ Builder.

Advanced Error Handling. Define advanced. C++ gives you try-catch, etc. and provided you put a big of work into it, can be pretty good at error handling.

Advanced object oriented design including multiple inheritance, abstract classes, and garbage collection. Well, C++ is the language most people think of when someone says OO. That said, C++ does not have any built-in garbage collection which is in my opinion a shame. Still, you can plug in garbage collection if you want, though the URLs escape me. In my experience, this has slowed down the execution of my C++ applications considerably but that said, my applications tend to allocate and deallocate memory quite frequently.

Full support for operator and function overloading. Yes, C++ provides this.

Portable (at compile-time) across various platforms. Well, C++ is NOT, in my experience, as portable as Java is. That said, if you use a platform independent GUI library such as Qt and you are smart in how you code, you shouldn't have any great problems. Gnu Autoconf, Automake, and Libtool, published by New Riders, will help you out here.

So is C++ the language for you? That is impossible for me to say. The two major things it is missing is a GUI library (though Qt is excellent for this) and garbage collection (though this may not be a big issue). Personally, I find it easier to code in Java, mostly because Java does not allow things like multiple inheritence or operator overloading. Don't get me wrong, there is good reason to use these (and my C++ code occasionally does) but on the other hand, it can lead to much hassles. Very few projects really need multiple inheritence, for example, and MI can lead to all kinds of nasty problems. Do you really want to sink to the level of virtual inheritence, for example?

Really, though, we cannot help you out all that much more without knowing what kind of project you are working on. Your requirements seem to indicate this is not a small project. As a result, I'd advise against VB.Net, having spent a year working in VB on a project about a third of a million lines of code long. C# has potential (it is a blunted-scissors version of C++) but really isn't mature enough at the moment. Eiffel I have no experience with. Java is great in SOME circumstances but I'd hesitate to recommend it to you without more information. And then there's C++, which I have spoken about in great length here. But C++ is a tricky language to use correctly.

This article should be on some where like Linux devices

Slashdot has become a cesspit of crap "news" and a lair filled with stinky trolls. Real nerds don't use slashdot!

If Miguel hadn't moved MONO to the X11/MIT license last week, I don't think RMS would be so upset. We're talking about GNOME, the biggest GNU project since HURD being based on an API that is Non-Free-As-In-Freedom, only a portion of NET has been submitted to ECMCA. With the concern the GNU community had over KDE, this would make the GNOME community look like hippocrites (GNOME was started because KDE used to be based on QT, which was not released under GPL.)

FYI I submitted this same story about 5 hours ago. Hmmm.

It runs just fine on my Windows.

So do EXE files. Its less common OS's where more problems show up.

Eh? What are you talking about?

I'm talking about the Swing toolkit, drawing widgets on its own and not using the native platform widgets, which is fine, except those widgets look nothing like the platform's.

This makes Java client-side apps to stand out from the crowd and have their own look & feel. If you use a Gtk+, Qt, Tk, desktop where different looks and feels exist at the same time it'll seem okay. But in a 'purer' Windows, Gnome, or KDE desktop, where all widgets look the same, this is rather ugly.

Having written server software in Java for the past 3 years can't say I've really seen this. I'm still amazed by the fact that I can drop my binaries on the occasional Linux or Solaris box and it just works. It's definately more portable than anything else I've worked with. Most often portability comes down to the experience of the programmer. Java doesn't prevent a newbie from being stupid and screw up portability.

Well, just as an example, www.topcoder.com is a Sun-funded site and based mostly on Java. I'd suppose they write good Java code, not Newbie'ish, and yet their applet works in very awkward ways on different platforms. Fine on Windows, yet quite problematic on some Linuxes, throwing Null exceptions, and fine on others.
I can say I had better experience with Qt C++ code.

It's not the language thats important, its the libraries. Java has them, C# doesn't have them outside the Win32 platform.

This I can agree with. I suppose the C# port will come with the runtime and its libraries, and if not you are completely right. However, as an extension of what you say, you can view Qt as a great alternative to Java because its quite portable to most interesting platforms, and as you say, its the library that counts.

QT/Embedded supports 2D hardware acceleration and KDE/Gnome applications are just a compile away. As far as 3D goes, you're right. Why would you need 3D in when there are no games around? I've used Linux/BSD since 1996 and I've never required 3D graphics.

If you prefer to utilize the low level API's then use the MSDN from Microsoft. If you can use a toolkit I completely recommend the Qt toolkit from Trolltech. A Non-Commercial version is available for Windows but only works with Visual C++ from MS. It has support for all the important stuff including GUI, Threads, Sockets, and full Translation support. Plus if you utilize Qt your code can be recompiled on *nix, Mac, or Windows with VERY few modifications. That's just my take on it though. Best of luck.

err...
The Zaurus isnt quite open source. They dont give the hardware design etc. Simputer can be called a trylly open source handheld.

Hardware apart, even parts of the Zaurus software environment are closed. Parts of Qtopia are closed, and licensed from Trolltech. Also, the opera web browser etc are closed.
In fact, there is a project, Open Zaurus is an initiative towards a tryly open software Zaurus environment.

Basically the article is preaching that the MacOS dev tools are better, because it is easier to code GUI apps using the Mac libraries. Just a load of bull****. Similar tools can be constructed in dt using Qt. Especially the part where he says about dragging and dropping textures in VRAM. Drag-n-drop is as easy as saying 'ditto', using the Qt's built-in support for drag-n-drop. Not only that, but a Qt-based tool can be compiled in every platform that Qt exists for.

Unfortunately, by using Qt/Embedded, the Zaurus partially loses that advantage: while you can muck around with VNC, in reality, the only apps any end user can run on it are Qt/Embedded apps--Qt takes over the screen. On the Zaurus, it's Qt or nothing. Software needs to be ported. Display code needs to be rewritten. Programmers who want to program the Zaurus must spend the time to learn it and use it and build new tools for it. While that isn't hard for an experienced programmer, it still is a lot of wasted time. Note that this is different from Qt on the desktop, where, through the magic of X11, Qt apps live happily side-by-side with other apps.

There is no real reason for this. If you download the Qt/Embedded and Qtopia demo and run it, you'll see that it uses up about 9Mbytes of RAM, considerably more than an X11 server and X11 apps running, say, on the AgendaVR3. And Troll Tech's own description of Qt/Embedded claims that its resource usage ("800k to 3M", depending on configuration) is comparable to that of an X11 server (which takes around 1M in a configuration suitable for handhelds).

What Sharp should do is create an X11 server for the device and recompile their Qt-based apps to use the X11 server. Then, the Sharp will be a standard Linux PDA. The way it is, the Sharp is, for practical purposes, a very slick looking but proprietary device. And that's not what Linux systems are supposed to be about.

> QT is QPL, by the way

And also GPL.

- Arcadio

Well, GTK for Windows is available, as well as the free version of QT for Windows.

I bet a lot of other Linux apps could easily be ported to Windows, and this would probably increase Linux's popularity quite a bit. It sounds like Gnumeric uses more of gnome that just gtk, though.

you can find more screenshots here

and more info here here

this runs on top of the familiar linux distribution. and works on a compaq ipaq as well (although, not the 3800 series).

Qt is available under GPL for X11/Unix and for commercial licensing for X11/Unix, MacOS and Windows. Anyone could actually port the X11/Unix version to Windows, but noone have, AFAIK.

Or release it under a BSD license like Ogg! The codec will get more widespread use, but it will be harder to make any money from it.

Qt is available under GPL for X11/Unix and for commercial licensing for X11/Unix, MacOS and Windows. Anyone could actually port the X11/Unix version to Windows, but noone have, AFAIK.

Or release it under a BSD license like Ogg! The codec will get more widespread use, but it will be harder to make any money from it.

The real problem is the users themselves who are migrating from another operating system (typically an MS OS, although I'm sure this would apply to any other). While taking a Human Computer Interaction course not very long ago (early this year), the project we chose was to create a simple interface for the Linux lab, for new users.

Now, most users are familiar with buttons, right? Everyone who has used a modern GUI has seen and used and is familiar with buttons. So, we made a little app in QT 2.x that would have a screen with a few rows of labelled buttons. There would be categories (office apps, math and science apps, development apps, etc.), and the user could select a category and click the button of the app they wanted. You don't really get any easier than this.

The results were disturbing. Our team (made of mostly windows users) had little problem, since they had seen it in development. But almost no one else could use it! We tested on a decent number of people in the NT lab (since this was our target audience), gave them a few simple tasks (like "start a word processor"), and only a very small percentage could complete these tasks. They just couldn't handle something different.

This is the problem I see with making it "OK to be ignorant (about computers)". People can't really use a computer at all, they can only repeat a set of rote tasks to do what they want.

Using a computer isn't difficult. Understanding what is happening isn't difficult. Which OS you use, whether you have a GUI or a command line, is irrelevant. Most of the problem people have with "Linux is Difficult" stems from the fact that they only know a series of rote tasks on one platform, and these rote tasks don't work on Linux. (Even if they do, there is mental confusion simply because it isn't the platform they're used to... we tried this with GNOME and KDE as well, which are quite similar to what people here do, which is use the Start menu.) I have set up a Linux computer for my mom and sister, both of whom had no previous computer experience, and they had absolutely zero trouble using it. My dad, however, who had a deal of Windows experience, just couldn't handle it. (In fact, I had my sister edit a LaTeX document one time, just for kicks, and she picked up on the formatting codes without any explanation. She didn't get them all right, but she came very close.)

People don't like to change. They don't like to learn and adapt. But they should, even though they will make a fuss. We know they should. We are experienced, and we do know better than they. This is not an elitist attitude: we want them to learn too. (An elitist attitude would be that they are inferior and cannot, or should not, learn.) Making it OK to be ignorant is merely harmful for them and ourselves, as well.

How much Visual studio costs? lets be modest and say $500? now you know thats for only 1 platform, so if you want you app, for Unix for example - you need something like umm, this? (hint - the price is MUCH more then $1000).

So yes, if you're writing commercial applications for Windows - then you really don't need QT, and MS solution would be much cheaper.

However - if you want a multi platform solution (Linux, Solaris, IRIX, HP-UX, SCO, Mac OS X, Windows [95/98/ME/NT/2K/XP]) along with the best documents - then GTK will be thrown out by any serious developer and they'll go with QT.

Of course - IMHO QT should make what I call a "student" edition - but you'll have to write it to them. Maybe if lots of people will write to them they'll do something about it.

the apps are written using trolltechs embedded qt api or java, so if you are familiar with either and would like to participate, feel free.

This should probably be considered a "beta" release of the pda, so it's probably not quite complete enough for the average user.

From trolltech; The version that comes with qt-2 is Perl and thus as cross platform as you can probably hope for. tmakes are significantly easier to maintain directly than makefiles, configure scripts or any other beast I've looked at.

Heard of Qt non-commercial on windows?

• Not GPL compatible, not even free software. Heck, the QPL is freer than the Qt non-commercial license. This license issue is a blocker for all apps designed to link against Qt Free Edition under GNU GPL or that use libraries licensed under GNU GPL.
• The non-commercial license is not available at all on Mac OS X unless the user installs an X11 server.

Heard of Qt non-commercial on windows?

• Not GPL compatible, not even free software. Heck, the QPL is freer than the Qt non-commercial license. This license issue is a blocker for all apps designed to link against Qt Free Edition under GNU GPL or that use libraries licensed under GNU GPL.
• The non-commercial license is not available at all on Mac OS X unless the user installs an X11 server.

Here quote from that page:

The Qt Free Edition is provided under both the Q Public License ("QPL") and the GPL.

I don't see many Free Software developers rushing out to buy commercial Qt licenses so they can produce Free Software for Windows. So, basically, TrollTech would not be harmed financially, and would probably gain more users (which could mean more Commercial licenses, if some of the Free Software developers wished to make non-Free Software).

That's complete bullshit. Qt's commercial license has no clause like that

No, it's not. All the free licenses have that. non-commercial, free, educational, etc. Check the TrollTech General FAQ

Q:Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?

A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software. [emphasis added]

That, along with the FAQs, statements, etc. from Trolltech's past seem to make it clear. Go check their site yourself. Perhaps have a lawyer check the mentioned Professional and Enterprise Edition licenses and let us know if you're right and Trolltech is wrong.

Go away, troll.

I'm not trolling, just trying to point out issues with the Qt licenses. If you start with a commercial license and never want to ship shareware with it, or if you start with the proper free license of your project and keep it open-source forever, then it's not bad.

The original poster was slightly mistaken. Qt 3.0 has a few SQL enabled widgets in its new SQL module library. see trolltech.

An object-oriented database layer can be helpful though, for you weaklings, hehe.

[...]

Sorry, but you're a fucking troll.

hmmmmm....

> Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.

Huh, what FUD. Qt has nothing of the sort.

Yes it does. You should at least read the Trolltech FAQs. Check this one on their General FAQ:

Q: Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?

A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software. [emphasis added]

> And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.

No they don't. If you have a commercial license, you can sell as much properitary, close source shareware as you want. If you use free Qt, you can sell as much of open sourced shareware as you want.

Again, no you can't. Check their FAQ on that on the Qt Free FAQ or the one on their non-commercial FAQ. Basically it says that you should either go free or full commercial.

IANAL, but you need to get one to go over the license agreement carefully. Given current and past Trolltech FAQs and statements, and their interpretation of the contracts, you need to tread carefully here. Trolltech's position seems quite clear: start by paying or stay forever free/open.

> Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.

Huh, what FUD. Qt has nothing of the sort.

Yes it does. You should at least read the Trolltech FAQs. Check this one on their General FAQ:

Q: Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?

A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software. [emphasis added]

> And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.

No they don't. If you have a commercial license, you can sell as much properitary, close source shareware as you want. If you use free Qt, you can sell as much of open sourced shareware as you want.

Again, no you can't. Check their FAQ on that on the Qt Free FAQ or the one on their non-commercial FAQ. Basically it says that you should either go free or full commercial.

IANAL, but you need to get one to go over the license agreement carefully. Given current and past Trolltech FAQs and statements, and their interpretation of the contracts, you need to tread carefully here. Trolltech's position seems quite clear: start by paying or stay forever free/open.

> Qt has a very infectious license where if you at any time use a free version of Qt on your project, then you can never release your project commercially.

Huh, what FUD. Qt has nothing of the sort.

Yes it does. You should at least read the Trolltech FAQs. Check this one on their General FAQ:

Q: Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?

A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software. [emphasis added]

> And Trolltech dismisses shareware completely. They consider it to not be a viable approach, and so Qt can't be used for it.

No they don't. If you have a commercial license, you can sell as much properitary, close source shareware as you want. If you use free Qt, you can sell as much of open sourced shareware as you want.

Again, no you can't. Check their FAQ on that on the Qt Free FAQ or the one on their non-commercial FAQ. Basically it says that you should either go free or full commercial.

IANAL, but you need to get one to go over the license agreement carefully. Given current and past Trolltech FAQs and statements, and their interpretation of the contracts, you need to tread carefully here. Trolltech's position seems quite clear: start by paying or stay forever free/open.

Just remember that you only need to give your source to any entity you give the binary to. Being GPL/LGPL doesn't mean you can't use it for business use; the license is entirely transparent for apps which will only be used internally.

Actually, you cannot use the non commercial version of Qt for non free internal applications:

"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."

See their page for more details: http://www.trolltech.com/developer/download/qt-win -noncomm.html

However, their prices are quite reasonable, when you consider what you get. Qt is an excellent toolkit, and in my opinion, better than anything else available. Native support for all three major platforms with only a recompile is great. The price for one enterprise license is probably less than a developer's salary for two weeks. How long would it take you to port your application from X11 to Windows or MacOS?

it also is a cross platform development platform. So it provides cross platform facilities for many activities - file access, sockets, database access

Just MySQL and PostgreSQL, or does it also talk to common proprietary DBMS such as oracle, sybase/mssql, etc?

printing, font handling, Unicode and internationalisation

How big does a distribution have to be to include glyphs for all 50,000 or so Unicode UCS-2 characters?

preference handling, XML support including SVG, various image formats

How much of the price of a Qt license covers the Unisys royalty for a popular "various image format"?

regexps, data and time classes, multimedia classes

Multimedia as in video playback? Is Qt trying to become like the other QT?

Does it handle press/release semantics for keypresses, or just press/repeat? Does it handle joysticks (erm, "industrial control devices")? Does it handle reading mouse motion not limited by the four walls of the screen (necessary for object manipulation in a 3D environment)? Does it handle sound?

Yes, I'm getting into the domain of Allegro or SDL, but only to show that Qt isn't the be-all and end-all of application toolkits.

GTK:
GTK

QT:
QT
Excellent QT Tutorial

wxWindows:
wxWindows
wxPython

Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL

Others:
FLTK
Fox Toolkit

Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page

I needed this list for my own use. Maybe it will be of interest to you.

GTK:
GTK

QT:
QT
Excellent QT Tutorial

wxWindows:
wxWindows
wxPython

Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL

Others:
FLTK
Fox Toolkit

Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page

I needed this list for my own use. Maybe it will be of interest to you.

GTK

QT


Post Comment Lameness filter encountered. Post aborted! Reason: Don't use so many caps. It's like YELLING.

One thing I don't know is how QT works in terms of different GUI threads, but I neither know for GTK.

The Qt docs have a note on threading here. From the page: In Qt, one thread is always the event thread - that is, the thread that pulls events from the window system and dispatches them to widgets. The static method QThread::postEvent posts events from threads other than the event thread. The event thread is woken up and the event delivered from within the event thread just as a normal window system event is.

Personally, I have found that the QThread implementation is a piece of cake to work with. It's a very nice abstraction away from the syntactic ugliness of pthreads.

Overall functionality, momentum for future growth, ease of use, licensing, and pretty much anything else is relevant to our decision.

To pick up your point on licensing, Qt is either GPL or pay. So if your application will also be GPL, it's free, if your application will not be GPL you will have to pay up for Qt. GTK is LGPL AFAIK (enough acronyms for you? ;-) so that will not stand in the way of making your app non-free.

BTW, if you know C++ and want to get to know a bit about Qt, they have a pretty good tutorial online here. Just walking through the examples made me realize just how cool it is, and how much you can do in just a few lines of code.

Like every other post I have made, this will be moderated to 0...but even if one person reads it, I will be a happy man.

Here is a garbage collector for C++ which does not use threads. You just have to use a special template pointer class, and your garbage collected objects should be derived from a special object class, that contains a reference counter.

When a pointer is assigned the object, the reference counter of the object increases. When a pointer is assigned to another object, the previous object's reference counter is decreased. When it reaches 0, the object is deleted, because no pointer in the program refers to this object any more.

Here is the link to the code...as you can see it is almost 100 lines of code, heavily commented...no need for garbage collector threads or other stuff... :

C++ garbage collector

My point is that if C++ was properly used, Java/C#/VB would not be needed.

And for a very good C++ GUI toolkit, use Qt

Nokia's 9290 phone/PDA thing is soooo cool. I got to look at it at E3 earlier this year, but only at Comdex did I see it doing some actual operation. They had one playing a realvideo stream, and some others running games. This one lady had a digicam watch and she took a picture of me, then pointed the watch at the 9290 and beamed my image across. Then she displayed it on the screen and proceeded to say how she could now email it off if she wanted. Freaky!

The next cool device was the new Sharp SL-5000D PDA, running Qt/Palmtop. I saw it at Trolltech's booth. It has this fold-out keyboard thing, which is surprisingly usable. If it has a built in GSM modem, it would be a serious contender to the Nokia 9290. For me, the only reason I would choose the Sharp would be ease of programming. Instead of having to learn EPOC programming (for the Nokia) I could just use Qt.

Speaking of "just use Qt", Trolltech even had an iBook at the booth running Qt/Mac on it. Call me crazy, but I began to hack on the laptop right there for about 20 or 30 minutes. I was able to create a couple useless testing programs. Worked as advertised! Even the pulsating default buttons. This was only the second time I've laid hands on a machine running MacOS X, and I was already able to program applications for it. Hmm, maybe it will be a tough call between the Nokia and Sharp.

A few other minor things caught my eye, but these were the big ones. Overall, it wasn't as interesting as this year's E3 (which wasn't very interesting either actually). Funny thing: ATI was showing off GameCubes (I guess they make the video chipset?), and Microsoft and Sony had XBox and PS2 there as well. Perhaps they wanted it to be E3 :)

But Qt 3.0 has fairly good cross-platform threading and networking libraries, in addition to its GUI stuff. See http://doc.trolltech.com/3.0/network.html for networking docs and http://doc.trolltech.com/3.0/threads.html for threading docs. Since you're already learning the "Qt way," you might as well use it for these features too.
--JRZ

But Qt 3.0 has fairly good cross-platform threading and networking libraries, in addition to its GUI stuff. See http://doc.trolltech.com/3.0/network.html for networking docs and http://doc.trolltech.com/3.0/threads.html for threading docs. Since you're already learning the "Qt way," you might as well use it for these features too.
--JRZ

Uhhh, Qt is still at version 2.3.0 for Windows. I don't know if the changes will affect you. It's still mostly source compatible, but not 100%. Be sure to read the changes.

why not GTK/GLIB? 1.3.x is coming along quiet nicely... native windows/*nix ports... developed by the community, for the community ..not by a single company sure redhat support GTK+/Gnome, but hey dont own it.Its always been under LGPL/GPL, none of this QPL-hybrid shit.

Trolltech still fully control QT on non-linux platforms...why cant QT be open on every platform?

I'll never trust trolltech.

Have you ever tried it? Have you seen QT? Yes, the same toolkit as used in the KDE project.

Try it on for size. Browse through the excellent documentation. Do everything from GUI to XML to file and network I/O to all kinds of data containers, cross-platform. QT is probably one of the best examples of GOOD, CLEAN C++. KDE knew what they were doing when they picked it.

I do recommend testing on all environments while developing, but you should end up with one code base (maybe a few ifdef's) by using QT well, barring only serial port routines (not in QT AFAIK) for which you can code the interface into your app and create different implementations for different OS's.

Really, it doesn't have to be this hard. QT is excellent stuff, develop cleanly and you should be just fine.

(There's also the Trolltech announcement, if you are interested in some pictures.)

RMS is against the KDE project because it is based on Qt which is not a GPL application.

Yes it is.