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.

Comments

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.

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.

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.

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.

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.

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 =)

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.

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

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.

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.

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.

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.

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

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.

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 :)

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

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?

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.