From The Linux Foundation

Well, from my point of view Trolltech (and Qt by extension) is no more than a disturbing company.

GNOME become the defacto desktop time ago, since it is officially supported by major players in the Linux/Unix World (RedHat, IBM, Sun, Novell, Nokia, ...). And with respect to programming language support Gtk (and GNOME by extension) clearly outpaces Qt/KDE in support and libraries (Perl, Python, PHP,...).

Most important is the fact that future versions of Java will integrate with GNOME.

I don't like Java and I know it can not be considered Free Software, but the case is that Java is the first

language in use those days (Number of Java developers is bigger than the sum of C#, C++ and VB), so it's pretty clear that if we have to center in standard libraries for everyday usage we must notice Gtk/GNOME is priority number one. Qt (and KDE by extension) is not.

If we look at major linux distros we find:

RedHat: GTK/GNOME.

Novell: Qt/KDE but changing to GTK/GNOME (Novell Mono is 100% GTK/GNOME and we all

know Ximian is now part of Novell which suffice to say what their intentions are in the long term).

Debian: Neutral.

Ubuntu: GTK/GNOME.

Mandriva: (Not exactly a major player those days, but still alive) Qt/KDE. Still Mandriva installation

and management tools use Perl/GTK so a switch to GTK/GNOME could be easy in a short time.

Slackware: Not widely used those days, but just for historic reason deserve to be mentioned. Qt/KDE.

Solaris: (Not Linux, but quite similar and broadly used everywhere around). GTK/GNOME.

I we look at major software in use:

Mozilla (Firefox, ...): GTK/GNOME

Eclipse: GTK/GNOME

Evolution: GTK/GNOME

OpenOffice: "In the way" to GTK/GNOME

Java Swing: "In the way" to GTK/GNOME

NVU: GTK/GNOME

gimp: GTK (with GNOME extensions)

gimp-print: GObject, Glib (Subset of GTK)

Cairo-Lib: Neutral, but with GTK/GNOME front end. No Qt/KDE support at all.

maemo: GTK/Subset of GNOME

inkscape: GTK/GNOME

Acroread (v.7+): GTK/GNOME (probably many other Adobe apps. are comming to Linux based on GTK/GNOME)

wxWindows: GTK/GNOME.

Oracle: In the process to integrate with Mozilla technology => that is, GTK/GNOME

I think it's absurd to waste time with Qt stuff. From my point of view, Qt/KDE are plain dead.

Outside the Trolltech area of influence I see no company interested in Qt/KDE anymore. Prommoting

a second GUI library just disturbs and confuse newcommers.

Still if someone wants to use Qt it is free of doing so, but please, don't try it to be an

standard just because it favors your own interests.

(anonymous@80.58.47.42; Telefonica de Espana SAU, Red de servicios IP)

---

Remember: A desktop system is not a set of GUI applications based on a single toolkit. Rather, a desktop system is, effectively, a set of standards for desktop integration and component sharing that are implemented. The toolkit isn't necessarilly relevent. On Windows, are you required to use MFC? My first Windows programming course used Borland's OWL, instead. Both GTK and QT are also toolkits used on Windows. Is the Windows API splintering as a result? Of course not. The toolkit is not relevent.

I have two points to make:

(1) GNU/Linux Desktop standards should not include any specific toolkit (GTK, QT, etc.); It should, rather, focus on Desktop system standards; for example, the desktop component model (bonobo/kparts), a copy/paste standard, desktop icon and menu standards, etc.

(2) Most of the facts in the above note are innaccurate. All of those companies officially support both GTK and QT--and many of them support products that use both. Also, Novell is not moving SuSE to GTK/GNOME. In fact, they distribute a recently modified version of OpenOffice.org that uses KDE's file open/save desktop components (hence network, etc. transpearancy that GNOME lacks). Mandriva is profitable with strong sales--even after recent, multiple acquisitions of other companies. And, indeed, most desktop-centric distributions favor KDE--Ubuntu is unusual in this respect for basing on GNOME. And, QT does break Stallman's freedom 0 by forcing users to pay TrollTech. In fact, Stallman openly prefers licensing more akin to QT's GPL license due to its keeping software Free... which returns us to the focal point of the problem here. In fact, the GNU/Linux kernel can be argued to have the same problem, since it and QT are both licensed alike, under the GNU GPL.

Drop any mention of toolkits. It's general no issue for an application's installation process to include the required libs and lib versions for a toolkit such as KDE/QT or others. What's crucial is the sharing of Desktop system component models. GTK makes great KDE applications and QT makes fine GNOME applications. In fact, most official GNOME applications don't even use GTK. Furthermore, both systems can use each other's component models and they also share a copy/paste standard, desktop icons and start-menu standard.

Include those as the LSB Desktop standard and leave toolkit as a developer choice. You should, thereby, include a requirement that any toolkit-required libs be included in desktop software installation, if not already present (just as any non-standard libs should always be provided). This is also important because both GTK and QT (and other toolkits) tend to pump out new versions that loose binary compatibility in-between releases of the respective GNOME and KDE desktop systems.

Matthew C. Tedder (teddemc@yahoo.com)

---

I've once asked the "freedesktop" people about their choice between GNOME/GTK*, KDE/QT* and their manifesto was to stay desktop neutral. The above list for some reason does not list SuSE ( which packages both KDE and GNOME desktops. )

One of the important things "freedesktop" people agreed on was that the choice of being able to run different applications (based on different library sets) should never be removed from the user. However, they want users to conveniently exchange information between applications. IMO, Linux's major success against alternatives is providing choice (talk drivers, packages, libraries, applications, desktops - think Enlightenment too). The License criterion we work on should not decide against this element of choice (which is in fact the user's freedom).

The end-user/consumer always has the option to choose a "free" alternative or a "non-free" alternative. In the case of the latter, we may just provide guidelines and expect the maintainers of the "non-free" alternative to put the effort to be compliant. This has been discussed over emails addressing licensing. Lastly, the final criterion should come from a legal team who would neutrally draft the criterion.

SunilBeta - 13:52 28-Sep-2005 (GMT)

Stallman's definition of Open Source involves 4 promises, numbered 0 through 3. They are...

0) The freedom to run the program, for any purpose.

1) The freedom to study how the program works, and adapt it to your needs.

Access to the source code is a precondition for this.

2) The freedom to redistribute copies so you can help your neighbor.

3) The freedom to improve the program, and release your improvements to the public,

so that the whole community benefits.

Access to the source code is a precondition for this.

You can put any words you like on it, but if these promises are not kept by linuxbase, then the effort becomes irrelevant.

The Qt License breaks promise 0 by requiring fees to Trolltech under certain unnatural conditions. As long as it breaks that promise, Qt and by extension KDE should be excluded from consideration in the LSB effort. In time, both Qt and KDE will die a natural and deserved death.

Phil Stone (linuxbase@bibletime.com)

---

Phil: You are wrong. Qt is free to run, for any purpose, like any GPL software. Qt is licensed under a choice (user/developer choice) of GPL, QPL or proprietary. Therefore, it is free software. BTW, the free software foundation seems to recomend the GPL over the LGPL:

http://www.gnu.org/licenses/why-not-lgpl.html

The FSF holds no restrictions to Qt. More evidence:

http://www.ofb.biz/modules.php?name=News&file=print&sid=260

And to (anonymous@80.58.47.42; Telefonica de Espana SAU, Red de servicios IP):

The LSB objective is not to pick favorites. there is plenty of demand for Qt, even if you personally don't use it. And the new criteria does not take any options away from you, using Qt is not required.

amadeo (amadeo@imap-mail.com)

---

This discussion seems to me unworldly. KDE is the No1 Desktop in europe and almost all desktop-centric distributions use it. Hence there is need for it and it is already a standard. IMHO would the exclusion of Qt/KDE-libs be the same like Microsofts bundling IE with Windows: the killing of an unbeloved competitor by creating a de facto-standard. (and ignoring the fact, that KDE is widly used) Choosing Gnome over KDE would take choice from users - for many tasks only the Gnome-flavoured application would remain - and that is not in all cases the best one availible. There are many important apps based on Qt/KDE (K3b, amaroK, Scribus, Skype,KDevelop, etc.) and it surely would not desireable for users to relinquish them. Lets stop that childish flamewars and look for a solution the majority of users will benefit from.

heiko (heiko.braun@web.de)

---

As an ISV we want all distributions to have both the QT/KDE libraries and the GTK/GNOME libraries installed by default (and in a version that we know we support - but that is the purpose of the LSB anyways). Ideally, support for both in a number of different development languages/environments would be included as well although this may be too much to ask currently. We want to provide our users a "native" look and feel under both KDE and GNOME. Eliminating QT from the Desktop LSB hurts ISVs that feel that a great UI is important. Of course you can always write a GTK app and have it run under KDE if KDE is the desktop the user happens to prefer. Many apps are like this and many distros rely on GTK apps under KDE. I don't think this will ever bring Linux apps to parity with Windows or Mac apps with this approach however.

jon (jwalker@versora.com)