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!

Dot Categories: 

Comments

by Tom (not verified)

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 Derek Kite (not verified)

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.

Derek

by Tormak (not verified)

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.

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.

Cies.

by Ian Monroe (not verified)

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 Anonymous (not verified)

Cool!

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 Francisco (not verified)

OMG ;o)

by Nadeem Hasan (not verified)

...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 Anonymous (not verified)

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

by Debian User (not verified)

Hi,

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 Josep (not verified)

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 JohnFlux (not verified)

Neither mozilla nor OpenOffice are QT apps - so no.

by David P James (not verified)

> 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 Ariya Hidayat (not verified)

Gecko inside Konqueror ? You should check kdebindings-kmozilla

by MaxAuthority (not verified)

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 Rayiner Hashem (not verified)

Use the KDE C bindings?

by Ian Monroe (not verified)

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

by David Walser (not verified)

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 Daniel Molkentin (not verified)

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

Cheers,
Daniel

by David Walser (not verified)

Ok, thanks.

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

by Cowardly Anonymity (not verified)

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 John (not verified)

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 uga (not verified)

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 ac (not verified)

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

by uga (not verified)

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 Don Sanders (not verified)

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

http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
* 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 uga (not verified)

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 Anton Velev (not verified)

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 ac (not verified)

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 Sarang (not verified)

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 Evan (not verified)

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 Iuri Fiedoruk (not verified)

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 Kurt Pfeifle (not verified)

> 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 Iuri Fiedoruk (not verified)

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 Anton Velev (not verified)

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 Allan Sandfeld (not verified)

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 uga (not verified)

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 Kevin Krammer (not verified)

> 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 Anton Velev (not verified)

exactly

by jose (not verified)

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

-- joe

by JC (not verified)

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

by cm (not verified)

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 bangert (not verified)

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...

thanks!

by Iuri Fiedoruk (not verified)

Thank you very much!

by David Oftedal (not verified)

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?

foo_api_file_open(target_string,current_directory_string);

by no one in particular (not verified)

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

by David Oftedal (not verified)

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 (not verified)

Which xmms skin is used in those screenshots?

by Jose Hernandez (not verified)

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?