GTK+ Apps Get Free Reign on KDE Technology

Integration of GTK+ applications in KDE has taken another leap forward. This has historically been a bit of a problem; the fact that Qt and GTK+ rely on different event loops was making it impossible to, for example, use dialogs from one toolkit while building the GUI in another. QtGTK is a library which integrates the Qt event loop in the Glib event loop. This makes it possible to freely use KDE dialogs, DCOP, KDE IO and other KDE technology in any GTK+ application just like they would be native. From now on, every GTK+ application can easily integrate with KDE.

A tutorial explaining how to use this library is available from developer.kde.org. Integrating existing applications is trivial, taking one function call. Just look at what Daniel did with the Beep Media Player (formerly XMMS2):

  1. KDE Directory Open
  2. KDE File Open

The library itself is available in both tar.gz and tar.bz2 format.

This is only the beginning!


This, at first, seems excellent. In theory we could now see lots of GNOME applications, particularly those for which there is no suitable KDE equivalent, integrating nicely with KDE's most important technologies, namely the kio_slaves, DCOP etc.

But one thing worries me: maintenence. Will Beep Media Player need to be patched in every release to make this work, and will someone step up to do this, to provide a KDE version? It seems that if a development team chooses GTK & GNOME, they do it because they want to use those toolkits, and so it will often require outsiders to maintain KDE versions, which could only make things far messier.

Unless, of course, in the future this thing can become standardised so that you select in KControl or some similar place to use KDE widgets in place of Gtk/GNOME ones, and it automatically applies to all applications, without needing any recompiling. But that seems unlikely.

By Tom at Fri, 2004/01/09 - 6:00am

What this makes possible is having applications use the services of the desktop under which it runs. A user is confronted with one set of standard dialogs, file open, print, etc., no matter what applications they run.

The applications could check what desktop is running, and display the appropriate dialogs.

Yes it would be more maintenance for the developers, but a huge step forward for the users. Imagine all applications using the same print dialog, no matter what framework they are based on. It's not a matter of which print dialog is better.


By Derek Kite at Fri, 2004/01/09 - 6:00am

What I think they need is an intermediate library that both KDE and GTK/Gnome apps use for things like file open's, etc. that chooses the correct dialogs depending on the environment you are in.

By Tormak at Fri, 2004/01/09 - 6:00am

You worrie about maintainance? I guess quite some distro's will hapily apply/maintain/contrib patches to GTK apps that dont have a Qt/KDE equevalent.

I'm even looking forward to distro's that will go so far in 'polishing' their desktop feel.

I don't use and will not use GNOME, I have enough speed and i like my desktop to look good. I think this effort for building bridges between Qt/KDE and other toolkits (GTK, OOo) is special, if not unique.

Hopefully GTK/GNOMEers will also put efford to 'naturalize' Qt/KDE apps, this way their desktop experience will also grow.


By cies at Fri, 2004/01/09 - 6:00am

You assume that Beep wouldn't accept a patch to have an extra KDE compile time option. As the tutorial shows, it could be done without adding much source code bulk and no binary bulk to those who don't want it. It wouldn't be that much maintain. There wouldn't need to be a fork or anything. Thank you C macros.

Gentoo users could decide which way they want it, other distros would decide for their users based on what their primary desktop is.

By Ian Monroe at Sat, 2004/01/10 - 6:00am


Now if only I could automagically use this for all binary packages of all GTK apps installed on my system... But still, it's great!

By Anonymous at Fri, 2004/01/09 - 6:00am

OMG ;o)

By Francisco at Fri, 2004/01/09 - 6:00am

...due to large black background around the globe near the top. I am using IE6 here, I don't have konqy available here at work ATM to check.

By Nadeem Hasan at Fri, 2004/01/09 - 6:00am

Time to switch to a good browser? :-) http://mozilla.org

By Anonymous at Fri, 2004/01/09 - 6:00am


this so great. I followed with interest how in context of Sodipodi that was attempted first, and this simple and general solution, great.

Now if somebody commited the patch for GIMP, will they accept it?

And using this new GTK QT theme, would it possible for KDE to offer a button like "start GTK apps with KDE look (not feel)", then it would already be complete.

Yours, Kay

By Debian User at Fri, 2004/01/09 - 6:00am

This can also be possible with all the Mozilla familly apps and other Qt apps such as Scribus or Opera and even OpenOffice.org?

This is an excellent notice for KDE users!

By Josep at Fri, 2004/01/09 - 6:00am

Neither mozilla nor OpenOffice are QT apps - so no.

By JohnFlux at Tue, 2004/01/13 - 6:00am

> Neither mozilla nor OpenOffice are QT apps - so no.

Well neither is beep... From the author's own post:

>> From now on, every GTK+ application can easily integrate with KDE.

Since Mozilla is a GTK application it stands to reason that it too could be made to integrate with KDE. And even if not Mozilla itself, then perhaps something can be done to at least integrate Gecko into Konqueror as an additional View Mode.

By David P James at Fri, 2004/03/12 - 6:00am

Gecko inside Konqueror ? You should check kdebindings-kmozilla

By Ariya Hidayat at Fri, 2004/03/12 - 6:00am

Sorry, I am not the best programmer, but the sample code seems like the FileDialogs still are C++ classes.

So how I can I use this in my gtk+ app, when I don't like/want to use C++ but C only?

By MaxAuthority at Fri, 2004/01/09 - 6:00am

Use the KDE C bindings?

By Rayiner Hashem at Fri, 2004/01/09 - 6:00am

Then I don't think this new development will help you any.

By Ian Monroe at Sat, 2004/01/10 - 6:00am

First, where can I get the patch for beep media player to use this?

Second, I see a qtgtk-0.2 at http://ktown.kde.org/~danimo/

and you linked a qtgtk-0.1.0, which is newer?

By David Walser at Fri, 2004/01/09 - 6:00am

It's in fact older, I removed it. Sorry for the fuzz.


By Daniel Molkentin at Fri, 2004/01/09 - 6:00am

Ok, thanks.

So, where's the patch to beep media player?

By David Walser at Sat, 2004/01/10 - 6:00am

Will KDE eventually be equally usable and integratable from either Qt or GTK+? Will this render the entire Qt v. GTK debate as it pertains to KDE v. GNOME utterly moot?

By Cowardly Anonymity at Fri, 2004/01/09 - 6:00am

By using KDE dialogs, does it mean that a commercial app developed with Gtk under the LGPL license have to be under the GPL license or otherwise have to buy a license from Trolltech?

By John at Fri, 2004/01/09 - 6:00am

From my understanding point, unless you buy a Qt license, whatever app that links against Qt must either be GPL or QPL compliant. GPL implies that your app must be GPL too. QPL... well http://www.trolltech.com/licenses/qpl.html =)

By Unai at Sat, 2004/01/10 - 6:00am

Please stop spreading lies. GPL does not imply your app must be GPL. Period.

By ac at Sat, 2004/01/10 - 6:00am

Ok. So I'm lying. What licenses are allowed to be linked against GPL?
I know they must be opensourced. What else? Is LGPL allowed? I guess yes, but whatever that uses the first original lib must comply with GPL too, so you're submitted to the GPL license anyway.

Now tell me, what's the difference?

By Unai at Sat, 2004/01/10 - 6:00am

The GPL FAQ may help answer your questions, and other common questions about the GPL:

* What does it mean to say that two licenses are "compatible"?
* What does it mean to say a license is "compatible with the GPL".

By Don Sanders at Sat, 2004/01/10 - 6:00am

Great, thanks! It's one of those things one always hears in discussions but nobody makes clear. Lets hope somebody will give a definite answer to the definition of "derivative" too....

By Unai at Thu, 2004/01/15 - 6:00am

I think a smart solution can be like this:
1) write a small lib - set abstract classes that are LGPL
2) use in your app GTK+ and small lib only and you are still LGPL compilant so your app can be closed source commercial
3) release a GPL licensed implementation (of your small lib) of the classes that links against Qt
3*) and of course still have the "safe" plugin is GTK implementation of your small lib

the only problem then will be with the distribution since from my understanding you cannot distribute closed source and GPL packaged together.. but however if such plugin is widely adopted (in future) and all distros distrubute such plugins you should not care... more than that users will demand such thing since they want everything integrated

By Anton Velev at Sat, 2004/01/10 - 6:00am

Please stop spreading these lies about the GPL license. YOUR APP OR LIB DOES NOT HAVE TO BE GPL LICENSED TO LINK AGAINST KDE.

So why would you have to release a separate GPL licensed implementation? Please, you have been spouting off on this issue FOREVER. It is time you EDUCATE YOURSELF on these issues.

Here is the solution for people who can think:

1) write a small lib - set abstract classes that are LGPL that load either GTK+ or Qt at runtime.

That's it. That's all. No more license bullsh*t, it works and it's legal. Your proprietary closed source app can then use KDE dialogs for free. Simple.

By ac at Sat, 2004/01/10 - 6:00am

But dosn't linking to KDE automatically link the application to Qt? If a qt link is there, then you need their commercial license to write closed-source applications right?

By Sarang at Sat, 2004/01/10 - 6:00am

In this scheme you wouldn't be linking with KDE. You'd dynamically link your application with a small library with stubs for file dialogs and stuff. This library would be LGPL or something, and would implement the file dialogs etc using GTK. No license issues there, obviously. Just a little indirection.

Now, if someone wanted the programs on their computer to use Qt dialogs instead of GTK ones, they'd write a new dynamic library which implemented the same interface but used Qt as the backend. They'd then overwrite the first dynamic library with the new one, and boom, programs would magically have Qt dialogs.

Obviously the second library would have to be GPL. But this isn't a problem--the GPL specifically allows you to do whatever the hell you want with GPL code, including linking with libraries having an incompatible license, as long as you don't distribute the result. Which you wouldn't need to do.

That's merely one way of many perfectly legal and acceptible ways to accomplish this; it probably works a little differently in real life.

And that doesn't even consider the approaches where distributing the source code is perfectly legal, but distributing a binary is not.

By Evan at Sat, 2004/01/10 - 6:00am

Man, thank you very much!

Even that I was in favor of KDE being GPL even if you could not link agains it, your explanation is very welcome and I even think it should be printed in the main page or at least on some FAQs well visible, because there is a lot of FUD because of this GPL/KDE thing.
Thanks again.

By Iuri Fiedoruk at Sat, 2004/01/10 - 6:00am

> there is a lot of FUD because of this GPL/KDE thing

You are right. The FUD is spread by top level representatives of KDE opponents. It then trickles down to the rank and file of the community at large, because some friends are repeating it.

One effective way to counter FUD, is if more people at the grassroots level know the facts. If they speak up in every forum: as soon as they notice another grassroot friend to thoughtlessly repeat bits of it, they should calmly, friendly and backed up with facts and links counter any FUD with facts, figures and arguments.

By Kurt Pfeifle at Sat, 2004/01/10 - 6:00am

Very well said.
I used to use the kompany as a example that comercial software can be done using KDE libraries, but some time ago they started using more QT-only so I stopped using it. But knowing that you can write a little "wrapper" library to make possible writing non-GPL software for KDE (that is more or less that the kompany did) in such a well explained way is a great news that should be spread the most we can.

(I'm writing a article for a brazilian site about this just now)

By Iuri Fiedoruk at Sat, 2004/01/10 - 6:00am

AC, i think you should educate yourself by reading some news on the itnernet and the licenses.

You know very well that whatever that is deriviated from GPL licensed soft must be GPL (except for Kernel and some other system libs).. anyway .. i think you can make your conlusion now.
The question that John asked is for a commercial (i guess also closed source) app that is GTK written, and he wants to use KDE file dialog without messing with GPL.
Of course (only if this QtGTK thing is not GPLd already) one may pay a some money to buy a commercial Qt license.

I understand the question that John asked (comm GTK app + KDE filedialog) and hope my suggestion will be useful for his solution.

PS: btw why don't you stay strong after your name, but trying to show the world you are MEN in the same time with unknown identity???

By Anton Velev at Sat, 2004/01/10 - 6:00am

To things:
1. What commercial applications use GTK? It just doesnt make sense to use an inferior but free toolkit when you are already paying for development.
2. The KDE dialogs could by dynamically loaded, that way the application is not derivative, only the library, and the library could be LGPL.

By Allan Sandfeld at Sun, 2004/01/11 - 6:00am

Did you read the definition given by Linus for "derivative"? There was quite a bit of discussion. That part of the license may indeed be the most tricky point. Lets hope GPL v3 will make these points clear :)

By Unai at Thu, 2004/01/15 - 6:00am

> the only problem then will be with the distribution since from my understanding you cannot distribute closed source and GPL packaged together.

No problem. The application vendor can distribute with the GTK implementation but the Linux distributor can distribute the Qt implementation.

By Kevin Krammer at Sat, 2004/01/10 - 6:00am


By Anton Velev at Sat, 2004/01/10 - 6:00am

dude, i like this. anyone knows why this happened that late? thanks anyways.

-- joe

By jose marin at Fri, 2004/01/09 - 6:00am

You should post this info on the gnome.org news section ;)

By JC at Fri, 2004/01/09 - 6:00am

As soon as this technology is *stable* I think this should really be done!
It's the most easy and natural for the original author/maintainer of a software to implement and maintain this option.

But to do that the authors must know about it!

By cm at Sat, 2004/01/10 - 6:00am

Qouting from http://www.gnome.org/bounties/

> Welcome to the first-ever open source desktop bounty hunt!
> The goal of this contest is to help improve the level of integration between
> some of the core components of the Linux desktop.
> Our specific aim is to improve the experience of collaboration in the
> desktop environment. We believe that communicating and working with other
> people is not simply a function of a single application that sits in a
> rectangular window on your screen ? Evolution or Outlook, for example ? but
> one of the primary functions of a computer. Therefore, collaboration should
> be a first-class element of the user experience. In other words, it should
> be really easy for a GNOME user to talk to, share with, and work with their
> friends.

this is a good candidate IMHO...


By bangert at Sat, 2004/01/10 - 6:00am

Thank you very much!

By Iuri Fiedoruk at Sat, 2004/01/10 - 6:00am

So this File Open... Is it simpler to use than its GTK+ 2 equivalent? That's really all that matters to me. I mean, is it so impossible to create a function that just gets a filename and doesn't require you to set up anything else?


By David Oftedal at Sat, 2004/01/10 - 6:00am

Yes it really is that simple. Did you read the tutorial before posting?

By no one in particular at Sun, 2004/01/11 - 6:00am

Yeah, I read the tutorial, but it seemed to be more about the library and not the file open? OK, never mind then.

By David Oftedal at Sun, 2004/01/11 - 6:00am

Which xmms skin is used in those screenshots?

By David at Sun, 2004/01/11 - 6:00am

Are these pics real?
I am on a quest to find a single patch for QtGtk for popular GTK apps and have yet to find any. I began patching Gimp2 myself but have run into so many problems, I'm not sure I'll continue to try, as I have other priorities.

This is great, but where are the working patches?

By Jose Hernandez at Thu, 2004/08/19 - 5:00am