Unifying GTK & QT Theme Engines

An anonymous reader writes "Some guy on kde-look recently released code that makes gtk apps use the current qt theme. Seems this would be a major development for unifying the 2 environments. From the URL: This GTK theme engine uses the currently selected QT style to do it's drawing. Basically, it makes your GTK apps look like QT ones. "

Just a style

[gilesjuk]

It's actually just a style that makes them both look more consistant. Unifying the API is the hardest job and I don't really want to see a unified API as it would be a bit of a mongrel. To me I think the best way forward is for either QT or KDE to die and the developers of the losing project to join the winning side.

Merging QT and KDE would be like merging Linux and one of the BSDs.

Unifying to look like what?

[Gilesx]

The only true way to unify the two DEs is to get both camps to agree on a common widget set.

I, like many other Gnome users, chose the Gnome DE because of it's professional appearance - something which I feel KDE doesn't even come close to. There is no way I'd want to replace my Gnome widgets with KDE widgets, and I'd bet the farm that KDE people would feel the same way about the reverse.

There are many half hearted, rush desktop unification jobs at the moment. Unfortunately the only way that we're ever going to see true unification is if everyone agrees to work on it simultaneously at a deeper level than just aesthetics.

How can you unify two groups of people that aren't even on the same page?

Licensing?

[IamTheRealMike]

This is interesting for sure, but what are the licensing implications of this? Can anybody tell me?

GTK is LGPLd. That means it can be used by proprietary software (and in fact, sometimes is). If I use this theme engine does that mean I can no longer run proprietary software that uses GTK because I'd be linking it with GPLd code?

Perhaps the same concept should be applied but in reverse - a Qt theme engine to use GTK. There seems to be more experience going this way too, for instance XUL is already GTK themable and it works nicely.

Okay, now...

[Janek Kozicki]

I want Mozilla and OpenOffice to use a widget set of my choice (no matter which one I choose - qt, gtk, gtk2 ....)

btw, it reminds me of wxWindows [wxwindows.org] - a set of tools that allow you to compile your programs under different OSes using native widget sets of your choice. All widget sets are supported, but the widget set is chosen during compile time.

Thank Goodness

[ParadoxDruid]

I've tried using both Gnome and KDE, and I feel like Gnome isn't as advanced as KDE, despite what some of the other people on Slashdot may feel.

For one thing, I can change the individual colors of my widgets in my theme on the fly in KDE, something that a friend of mine who has used Gnome for over 4 years says is still not possible- the theme specifices one color set.

For another- most users never change some defaults, and the default Gnome icons are UGLY. Dark and uninspired.

Something to let me use excellent programs written for GTK, but with a more QT feel is nice. I'll have to check it out.

I already use ThinGeramik, a GTK style that looks to QT ThinKeramik for it's colors and such (also on kde-look.org).

Re:ummmmm...

[plj]

"making GTK2 apps use QT" != "Unifying"
"making GTK2 apps use QT" == "How to migrate off GTK2

Don't be ridiculous. There are many applications that are built completely around GTK(2). I, for one, usually prefer KDE over Gnome, but I've always found it much harder to live completely without GTK apps that completely without QT apps.

Both are great toolkits with their own pros and cons - just use the right one for the right job.

Personally, though, the feature I'd most like to see in GTK would be the chance to move the menubars of all apps to the top of the screen like on Mac OS, just as I can do with QT apps.

Re:Licensing?

[Ianoo]

No I don't think this works at all. In the absence of repugnant EULA agreements from certain companies like Microsoft I can modify and combine software however I want on my own machine to suit my own needs. The GPL doesn't say you must make the source code available if you modify, it says you must make the source code available if you distribute. I can (and do) modify GPL and LGPL software to suit my needs on my own machine without any intention of ever redistributing these modifications, mostly because they're silly and complete messes (for example I've hacked various bits of GNOME's panel system to suit my own needs, such as removing the "Actions" menu from the Foobar).

Hence if I take commercial GTK applications and GPL'd GTK applications and commercial QT applications and GPL'd QT applications and install them on my own machine, I can install whatever the heck I like to change and/or modify their behaviours at runtime. This themeing engine doesn't have licensing issues at all.

Also worth checking out...

[Anonymous Coward]

Is SodiPodi [sodipodi.com], the famous vector image editor. It is a GTK program that uses the KDE file and print dialogs.

Re:Widget Mania

[Sleepy]

>Call me crazy, but I'm glad we've got a choice of desktop environments.

Except for a few "journalists" and controversial posters, I would bet that most people agree.

>Not to knock the KDE folks, but I happen to prefer GNOME. If desktops were to somehow "unify," and that meant all we had left was KDE, I'd be more than a bit peeved.

KDE will never be the dominant desktop. No offense to anyone pro-KDE. By the time this all works out, we'll have a KDE and GNOME that is so different from today's that we will not remember what the API wars were about.

Wrappers, unification API's, and freedesktop.org are bringing the two sides together where it makes sense. It makes sense in a LOT of places that aren't talking yet, but I say in time it will work out.

I'd LOVE to see KDE and GNOME use "common API's" for file dialogs. Why the hell NOT? An application should just say "file_dialog_common()" and then the user/desktop/distro settings determine WHO draws it. It doesn't matter. Desktop-specific features are EXTENSIONS. Granted, a lot of people thought GTK 2.2 and 2.4 file dialog was sub-optimal. Hopefully in the future with GTK 2.6, there will be some interest in at least standardizing the function calls, if not the actual code itself.

People won't shut up about which API "rules" until much of what the API's provide has been turned into a commodity, as in this example. The revolution will not be televised. ;-)

Re:Thank Goodness

[IamTheRealMike]

That feature has been discussed a few times by the Gnome team I think, but the general consensus is that nobody cares enough to actually implement it. You can change the colours in GTK, but there is no UI for it because the theme picking stuff is already complex enough without loads of stuff for "color themes" as well.

Personally I don't find it to be an issue, but whatever floats your boat....

Re:Just a style

[arvindn]

If you want a unified API, look no farther than wxwindows [wxwindows.org].

It has backends for qt, gtk, ms-windows etc. Trouble with it is that it adds an extra layer of complexity for the programmer and dependency for the end user.

I've heard for years...

[halivar]

I have heard for years (How many? Almost ten? Might be wrong) that KDE was going to come to a "dead end" because of (inster one: non-GPL, strict-GPL-non-commercial, closed development, pact with the devil, etc.), and that Gnome would eventually dominate due to its keeping with the "true spirit" of the FOSS movement.

I'm still waiting.

Re:Widget Mania

[Anonymous Coward]

NEW! Revised and updated!

$Revision: 1.38 $ $Date: 2004/1/2 11:34:23 $

The State Of KDE

We have seen a lot of important news regarding the KDE project over recent weeks, so it is worth pausing to consider the ramifications.

Let us start with the recent acquisition of SUSE by Novell. SUSE was the biggest Linux distributor (though still dwarfed by Red Hat) to use KDE as its default desktop. SUSE has, for many years, neglected to package the GNOME desktop properly or even do basic Q&A... much to the delight of KDE fanatics. Now, however, Novell has purchased the SUSE Linux distribution and Ximian, a company best known for the producing the most polished and professional desktop available for Linux (GNOME-based). The obvious conclusion to be drawn from these actions is that KDE is about to lose its main commercial support.

Let us take a look at some of the reasons why this is so:

• GNOME has always been the commercial desktop of choice. It has long been focussed on getting the basics right and building from there... as opposed to the KDE Project, which is entirely aimed at pleasing the slashdot peanut gallery with pointless eye-candy. KDE features are thrown into the mix with little or no regard for usability, or even good taste. The end result is disasterous, as can be seen by anyone unforunate enough to be forced into using it.
• KDE is extremely expensive to develop for, unless you intend to produce GPL software. TrollTech, the owners of KDE and Qt, license the X11 version of their Qt toolkit under the GPL. This forces anyone wanting to develop applications built on top of Qt and KDE to be either (L)GPL licensed, or pay for a TrollTech Qt commercial license; costing $3000* for every developer working on the application (per annum.) -- 10 developers: $30,000, and that is just to license the toolkit. No extra development tools and such... just the right to use it. You may find this difficult to believe, but developing for KDE is more expensive than developing for Microsoft Windows!
  
  * The $3000 figure is just for Linux. If you want to develop for the Mac, Linux and Windows the amount reaches a staggering $6000 per developer.
• TrollTech is also vulnerable to takeover by companies hostile to Free software and good corporate lawyers who can blow holes in the laughable FreeQt agreements.
• Qt/KDE's lack of accessiblity. Accessiblity is vital feature for a modern desktop. A desktop cannot be sold to the U.S. government unless it supports the features necessary for disabled users to make full use of it. The lack of said feature effectively cuts it off from the biggest software purchaser of all. GNOME has spent the last 18 months and more doing the ground-work and developing/polishing the accessiblity of the GNOME desktop (thanks to the fine work of Sun engineers). KDE has spent the time making *fake* translucent menus to help make impressive screenshots. Over the next few months you can expect increasing numbers of near-orgasmic announcements of weak accessiblity support from the KDE project, as the full extent of their folly and just how far they are behind GNOME finally becomes obvious to them. The end result will be, as with all KDE features, half-assed and broken -- designed only to function as a marketing feature tick-box filler. Note: The KDE project has begun announcing FULL accessiblity support thanks to using GNOME/GTK code in the form of ATK, however (and as usual) the KDE developers are being disingenuous. Accessiblity is more than just toolkit support (and even this is only at proof of concept stage for KDE), it requires work to ensure that all aspects of the desktop are accessible, including auditing applications and (especially) custom widgets, themes and fundamentally changing the thought processes of developers. Not to mention the tools needed for an accessible desktop, such as screen-readers, intelligent magnifiers which communicate with ATK, focus trackers and on-screen keyboards capable of full access

Re:KDE vs Gnome, battle of philosophy

[Findus Krispy]

I find it always funny that KDE supporters list re-use of existing libraries as a big minus point in Gnome, as if it is a bad point to re-use and adopt none-Gnoome supporting libraries,

Actually both communities are correct in their approach -- both are refreshingly pragmatic.

If you have a toolkit available to you as good as Qt, which makes re-use *very* simple, then you may very well realise that it would be easier to re-write existing functionality for that framework, rather than having to create a new framework yourself.

On the other hand, if you had no such library in the first place, you would see that it would be easier to re-use the myriad of existing software, and develop/grow a library that explicitly enables that.

Both approaches are equally valid given the differing starting positions of their projects.

I find the KDE community extremely vicious against everything not KDE, ...

No, niether the KDE or Gnome communities are vicious, it's just the fringe lunatics that pretend to represent these communities that talks all this crap. And they mostly do it here on Slashdot.

If you do some development, or just subscribe to the lists, you'll see exactly what I mean. Lot's of nice people just having fun developing quality code. Hurrah for Gnome and KDE!

Unification

[be-fan]

Its interesting how people ar deriding this sort of "look-based" unification. The truth is that "look-based" unification has worked just fine for Microsoft. I use a mostly KDE desktop, and only once in a while do I have to start a GTK app. The same thing is probably true for GNOME people --- they only have to start a non-GNOME app on occasion. If you use MS Office, you're automatically using at least two toolkits on a Windows desktop. Windows has many toolkits that major apps use on a regular basis. Its nearly impossible to run a normal Windows desktop without regularly encountering at least a few.

Now, why do Windows users think their desktop is so unified, when in practice, *NIX desktops are really more unified? Because Windows toolkits look kinda the same! Windows's "unified look and feel" is based entirely on unification of themes, rather than on any real technical unification.