Matthias Ettrich: Integrating Qt Apps with KDE

Matthias Ettrich is proposing a new strategy for more strongly integrating Qt-only applications into KDE. It's an intriguing proposal and relevant to KDE, considering the growing number of cross-platform but Qt-only applications becoming available. The initial "not-perfect but simple" basic idea is that a small libQtKDE proxy library would invoke KDE functionality when available, or otherwise fall back to Qt functionality. This would not involve changing Qt or KDE, but would require the programmer to link against the libQtKDE wrapper. The benefits for the former Qt-only developer is that KDE functionality would be made available cheaply without giving up the Qt-only cross-platform approach. The benefits for the KDE user is that what would have otherwise been a pure Qt-only application could now potentially integrate much more strongly with KDE. Good thing or bad thing? Read on for the full details of the proposal.

From: Matthias Ettrich <[email protected]>
To: [email protected]
Subject: Qt-only KDE applications
Date: Tue, 22 Jan 2002 13:45:39 +0100
X-Mailer: KMail [version 1.3.8]

Some time ago there was a rant somewhere about the emerging number of
cross-platform Qt-only application that do not use KDE's API and thus
do not benefit from KDE's additional features on Unix. To make things
worse, those apps - although using the same core toolkit - do not integrate
much better into KDE than any other X11 application.

Qt 3.0's style plugins will improve the situation somewhat, but not
sufficiently. Here's a rough, non-complete list of features a Qt
application should be able to utilize when running on a KDE desktop:

  • Standard KDE dialogs:
    • File dialog
    • The amazing print system / printer dialog
    • Color dialog
    • Others (like the lovely about box)
  • Network transparency via KIO
  • Exporting interfaces via DCOP

    (thanks to the new way of handling signals and slots in Qt 3.0 this
    can be done with Q_OBJECT only, no need for dcopidl and

  • Access to standard icons and icon effects
  • Obey other common settings for application main windows that go
    beyond the standard QStyle specification
  • Use KDE's style hints even if qtconfig specifies something else

One suggestion was to go cross-platform with parts of KDE and to
promote KDE as cross-platform API as well.

There's another solution, which I'd like to promote here.

KDE from the perspective of a cross-platform toolkit like Qt, is
really just another platform. Just as we use the standard MS-Windows
file dialog on MS-Windows, Apple's on MacOSX, Qt should be able to use
KDE's dialog when running on top of KDE.

The main reason why this isn't so easy, is the circular dependency: Qt
uses KDE uses Qt.

However, we don't need to start with a perfect solution. If would be a
major improvement already if we could make it easy to use the above
mentioned KDE features from otherwise Qt-only applications, without
having to write/maintaining two different versions of your application

Technically, the simplest approach does not even require changing Qt or

We write another small library libQtKDE, that wraps KDE
functionality. Either there exists two binary compatible versions of
this library, one using Qt-only, one using KDE, or we make one version
of the library that dynamically loads a KDE plugin when installed.

The library contains a dummy application-class (so that it's possible
to reimplement virtual QApplication functions) which instantiates
either a QApplication or a KApplication.

In addition there are a bunch of static functions like
getOpenFileName, NetAccess::download, etc.

Later, the static functions in Qt itself (like
QFileDialog::getOpenFilename, QPrinter::setup, ...) could utilize the
extended versions, but that's a second step. We could also provide
cross-platform functions that instantiate an MSIE/ActiveX control on
MS-Windows and a KHTML/Konqueror on KDE.

An application using libQtKDE is somewhere in the middle between a standard
Qt-only application and a true KDE application using the KDE API. But this is
seeing it from the programmer's perspective. For the user, it will much
closer to a true KDE application. Just that the same binary will run without
having KDE installed - with a slightly different look and feel and less

Opinions? Do you think that would be useful at all?


by Paul Seamons (not verified)


Very Beautiful!

by Thomas Olsen (not verified)

I can only agree.

Only thing is: would a former windows programmer need to do anything extra to port a QtWin app to QtX11 and make use of the KDE standard dialogs?


by Richard Moore (not verified)

I guess that would depend on the amount of KDE support they wanted. For basic things like themes, dialogs, dcop and ioslave support I think it could be transparent as far as the app developer is concerned.


by Rumcajs (not verified)

Excellent idea, but why can't we use plugins for everything ? If there are style plugins, we can have common dialogs, printing, ..etc plugins, so we could mantain a single code ( even without any #ifdefs ) among all platforms. There should be also possible, for example, to embed KSpread in Hancom Office in the future.
Where can I find info about "the new way of handling signals and slots in Qt 3.0" ?. Can I call some slot using only its name ? how can I pass the arguments ?

by Ian Reinhart Geiser (not verified)

This may help wooo more large scale applications developers to QT and inevitably KDE. I mean right now I dont see CA, Adobe or SAP beating KDE's door down. Maby with a more integration with the Unix desktop these companies will be ready to abandon Motif for QT and see what the Unix desktop has to offer. I mean what is the worse that happens? We get more software that looks good under KDE?

-ian reinhart geiser

by Derek Kite (not verified)

How to tie in qt3 designer database app with kde3. Any pointers to information on this? I am starting a project which will track job orders for a service trade.

This would be easy and automatic for developers. However there are a few neat things in kde that wouldn't be available, such as embedding kchart, kspread etc.

Would the kio stuff make for example ssh available to an app that wants to connect to a Mysql database?


by Carbon (not verified)

I'm not entirely sure about this, but for embedding stuff like KSpread, KChart, etc, would require access to KParts, and to the specific compenents. I don't think QT really provides a version of this sort of thing by itself, so it wouldn't be a matter of mapping a QT call to a KDE call so much as allowing optional support for certain KDE features.

by David Faure (not verified)

> How to tie in qt3 designer database app with kde3

Err, using KDevelop ?
I did this last month: a kde3 app that is a database app, with all dialogs coming from qt3 designer.
Use KDevelop to generate the kde3 compiling environment, and clicking a .ui from kdevelop simply fires up qt designer.
With the .ui.h feature, it's really great (no need to inherit every dialog anymore).

If you meant: so that the app can also be a qt-only app if wanted, then
we're back to Matthias's proposal ;)

by Shawn Gordon (not verified)

But is has to be implemented in such a way that a single library can be included with the binary, in the same way that the Qt library can be included. The challenge we always have in creating software for KDE is having to compile for every combintation of distribution and version of KDE, it is almost impossible and you have to leave people behind.

One of our goals for the last year was to create a KDE compatibility layer. As Matthias said, we rely on certain services on Windows and Mac, so if we are on Linux then why not default to KDE as the environment? We've had to build some of this from scratch already.

Qt isn't a desktop, it is a windowing toolkit. KDE provides the desktop and if there is a clean way to do what Matthias is saying, it would be awesome. We would be please to help with this project if possible.

by Evan "JabberWok... (not verified)

:: Qt isn't a desktop, it is a windowing toolkit.

Which is kinda starting to make me wonder if there should be a Qt/KDE added to the line. Like Qt/X11, Qt/Windows, Qt/OSX... KDE offers so much more in terms of standardized environment over X, that maybe it would be appropriate for a Qt that maintains portable code (a la the rest of the line), and uses "Native tools" for printing, opening files, etc.

It's similar to this concept, yes, but IMO a bit cleaner in terms of concept and probably maintainability.


by Erik Hensema (not verified)

Yes, but what would KDE use? Qt/KDE? That's impossible. So you'd have to have both Qt/X11 and Qt/KDE installed.

It meight be possible to LD_PRELOAD Qt/KDE for Qt-only apps, though.

by drawoc suomynona (not verified)

So Qt/KDE would be a (binary compatable) wrapper to Qt/X11 that replaces some of the Qt/X11 calls with native KDE calls? (which is almost what Matthias was suggesting, but not quite).

by Evan "JabberWok... (not verified)

Bingo - as I said, it's mostly different in conceptual position than actual code. It just makes it easier to decide which Qt to use - use Qt/Win for a Windows app, Qt/X11 for an X app, Qt/OSX for a Mac app, Qt/KDE for a KDE app. all using the same source, and portable across all environments and making use of the native features of each. Since KDE has features and conventions above and beyond either Qt or X, it makes sense.

It's really fundimentally the same idea, just placed differently in a more sensible and easier to comprehend position, especially for companies that just want to use Qt for its "real" reason - a cross platform windowing library.


by the mathematican ?! (not verified)

Isn't it really Qt/X11, Qt/Kdeembedded, Qt/KDE/X11, Qt/OSX/X11.

According to some kind of mathemtical logic folloes:

a) Using a wrapper:
MyXQtKDEApplication = X11 (Qt (KDE(myCode)))
MyXQtWrapperApplication = X11 (Qt (Wrapper (myCode)))

If we now assume:
MyXQtKDEApplication = MyXQtWrapperApplication

This results in :
X11 (Qt (KDE(myCode))) = X11 (Qt(Wrapper(myCode)))
Qt (KDE(myCode)) = Qt(Wrapper(myCode))
and thus if we would assume komutativity of X11 and Qt(*):
KDE (myCode) = Wrapper(myCode)

Thus in words, if we assume any KDE application would behave same as a Qt application with a wrapper, then the KDE must be the wrapper itself.

And if the KDE application behaves differently than the Application using the wrapper, then follows the KDE behaviour is not the wrapper behaviour, even if it has KDE the same interfaces to mycode as the Wrapper.

(*) if inherriage would be komutative, which it probably is not

b) Not using a wrapper, but Qt directly:

MyXQtKDEApplication = X11 (Qt (KDE(myCode)))
MyXQtApplication = X11 (Qt (myCode))

If we now assume:
MyXQtKDEApplication = MyXQtApplication

This results in :
X11 (Qt (KDE(myCode))) = X11 (Qt(myCode))

and thus if we would assume komutativity of X11 and Qt(*):
Qt (KDE(myCode)) = Qt(myCode)
KDE(myCode) = myCode

Thus in words, if we assume any KDE application would behave same as a Qt application, then the KDE must do nothing.

And if the KDE application behaves differently than the Application using qt directly, then follows the KDE, even if it has the same interfaces to mycode than Qt.

(*) if inherriage would be komutative, which it probably is not

Comments ?

by David Johnson (not verified)

Interesting, but...

...isn't this merely slapping the KDE look-and-feel on top of Qt apps? A guess for some people this would be a good thing, but from my perspective it's just superficial fluff.

This sounds more like a way to get KDE applications available as Qt-only apps, then the other way around. So give me an example. Show me the benefits to a Qt-only application, like LinCVS, by using this new library.

by Rumcajs (not verified)

You could open in the file dialog, or print four pages ( at least ) on a single sheet or maybe even display manuals using konqueror.

by Justin (not verified)

KIO is not superficial fluff. Did you read the entire post? :)

by Shawn Gordon (not verified)

In our Rekall product, if you were to use something like this, you wouet simple things like themes being consistant, printer services,cut & paste ability. Now from your perspective this is probably no big deal unless you run into it as a problem. For us it make it easier for us to make a Qt app interoperate with KDE. This is a situation really. It makes direct KDE support very simple for people creating Qt apps, which brings more apps to the desktop, which brings more people, which brings more critical mass, etc., etc.

think big picture here.

by David Joham (not verified)

With my AOL-Like Me Too on the side of this being a really good idea. I for one would love Shawn's applications to integrate better with my desktop.


by Thorsten Schnebeck (not verified)

Qt strength is that as a programmer you only have to learn one API for different plattforms. In terms of Windows/MFC I would say that is A Good Thing. But for KDE it is not. KDE is an open source project. One of its goals is to make the best desktop environment for Unix/Linux. Its focused on the integration of the whole stuff - not on publishing single apps. You need people wanting to learn the KDE-API.
If you have a KDE compatibility layer in Qt why (as an app-programmer) do you want to learn the additional KDE-API?

So, this does not sound like a win-win situation. KDE will lost future core programmers.
IMHO the right way is to have KDE core libs for other plattforms, too - maybe this can only be done if Qt is GPL/QPL for all free software on all platforms. Then we can say to a e.g. Windows user: Hey, look at this nice application: If you want to run it in a complete enviroment: Leave your plattform and come on over here.



by Mattias Dahlberg (not verified)

I'm using Delphi/Kylix, so this sounds like a great idea to me. But I assume Borland needs to migrate CLX to QT3 first though.

by Andi (not verified)

KDE is a powerful Open Source graphical desktop environment for _Unix_ workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of the _Unix_ operating system.


by Julien Olivier (not verified)

And why not make it a great multi-platform environment now ?

by Julien Olivier (not verified)

I don't really know KDE API but I'm thinking of one thing:

Why wouldn't KDE use QT-only applications, using libQtKDE to make the integration ? Only KDE-specific applications (dcop, kioslaves...) sould use the KDE API.

So, most of the work would be made into libQtKDE and app developpers wouldn't have to worry about KDE Api. If each app is written in QT and uses libQtKDE, there will be no difference between "native" KDE apps and simple QT apps since libQtKDE would act the same way on them.

But, for it to be really efficient, libQtKDE needs to be VERY powerful. It needs to emulate 100% of KDE functionalities through QT.
And QT needs to be modified to integrate more KDE-like functionalities so-that QT-only apps using libQtKDE don't lose some capabilities they had with KDE API.

Just my 2¢ (or 0.02¤ if you prefer).

by Watermind (not verified)

1. The simbol (¢) is dolar cents, and not to be used with Euro.
2. The decimal separator is comma (,). The dot (.) is the thousands separator
3. And I'm pretty sure the Euro symbol (¤), should come before the quantity money.

Example: ¤2.340,50
Am I right?
I hope new KDE versions do get the Kontrol Centre->Personalization settings correct for countries using the Euro :-)

by Julien Olivier (not verified)

1.What is the symbol for Euro cent ?
2.I'm a programmer :) I always use "." instead of ",". But I think you're right.
3.In France, I've always seen prices written like this: "34,99 ¤". In Germany, I saw both "¤34,99" and "34,99 ¤". I don't which is right... maybe there's no rule...

by Watermind (not verified)

I don't think there is a a symbol for Euro cent.
I'm a programmer too ;-)
I've seen it both ways here in Portugal too, and I do hope there is a rule. It's the same (currency) unit, everybody should write it the same way.

Now read this fast!

by someone (not verified)

> I hope new KDE versions do get the Kontrol Centre->Personalization settings correct for countries using the Euro :-)

by Bryan Feeney (not verified)

Arghh! No, don't do that to me! In the English speaking world it's the totally opposite way around - a comma for thousands and a point for the decimal separator. I just couldn't survive like that. Frankly though I don't think it matters how it's written, so long as it's the same value. We're different countries with different languages and cultures, and we should write it our own way. So long as you use the symbol people can work out the rest for themselves.

That said I'm gutted about the cent thing. It's the only part of the currency I thought I'd got working! If I hit the AltGr-4 in KDE I just get a ? - the same key combination gets me a ¤ in most GTK/Gnome apps. I'm using the enGB locale (I can't find an enIE for KDE, and the standard IE is in Irish and seems to be incomplete).

by Watermind (not verified)

The *english speaking world* is the opposite way around! :-)
And of course you could live like that, changing is easy ;-)
About the ¤ in KDE, you need to be using iso8859-15, and I had to change the var LANG to [email protected] - in suse all I had to do was change it in YaST2 RC-editor - I don't know whether [email protected] works or not... but I don't think so... I know SuSE mentioned something about it in the euro how-to.

I type the ¤ using AltGr-E

by syn (not verified)

> But, for it to be really efficient, libQtKDE needs to be VERY powerful. It needs to emulate 100% of KDE functionalities through QT.

It doesn't really have to be powerful at all. Remember that libqtkde would just call the appropriate functions within kdelibs and it's component libs.

>And QT needs to be modified to integrate more KDE-like functionalities so-that QT-only apps using libQtKDE don't lose some capabilities they had with KDE API.

Well, not really. This lib would be targetted to apps that do not use the KDE API anyways, so without the lib, they would not have any of the capablities that the KDE API provides (without getting it from elsewhere or doing it themselves, that is).

by Benjamin C Meyer (not verified)

Ok first off before even commenting on the idea I would like to loudly complain about the kde about box. It has several issues that need to be addressed. (I am referring to the standard one that everyone uses, not the far and few between custom ones) The about is made up of 3 tabs, 2 of which I have major qualms about. In Authors tab lists information about the authors, but does it is such a way that it becomes too long. I can't recall a single about about (using the kde about box) that could hold all of the developers info. One possible change would be to have the e-mail placed next to the name of the person. There are many different ideas of how to re-arrange it, but you get the idea. Next, the License agreement tab, why can't wrap around be used? Either turn it on or for default gpl and lgpl format it to fit the default kdeabout size. Maybe these issues are why not even all of the kde apps use the kde about *cough* utilities *cough*.

Ok, lets talk about this QT/KDE lib. First off I am glad that this discussion is being had. It is something that has been brewing for a long time and needs to be talked about.

Is a qt/kde lib a good thing? With this qt/kde library developers would then think that it is ok to stick entirly to qt and never move to kde. Right from that alone it would cause more hurt then help. Also it is presuming that TrollTech will be releasing a non-commercial windows 3.0 license. Who says they have to? Who says they have to release 3.1. (just go and try to get the mac version...) If anything the non-commercial package is probably hurting them financially in the market that they are making money mostly in (windows duh) and if I was in the marketing department I would certently (sp?) dangle "free" old versions of qt-windows for people to try out. Ok, but for the argument we are going to assume that they will continue to release non-commercial packages for if they didn't then this whole lib would be for not.

Let us now look at the alternative. This alternative it to clean up kdelibs so that it will port on windows (and mac?). We are not talking about the kdebase, but kdelibs. This will require the code to be gone over and cleaned up to be more compliant etc which will also practicly be a code review. Doing this will be worth its weight in gold. You want to know why? Because then all of the little qt-only developers will then see that they can get all of the kde functionality (not just the stuff in the qt/kdelib) and still have cross platform compatibility. They will then care more about kde, help out with it etc. Heck with kdelibs ported someone might port kdebase! How cool would it be to have the kde desktop on windows? Porting kdebase would be more work, but something that can be done. Trolltech did most of the work with abstracting qt and it only makes sense to try to get kdelibs for windows first. I am surprised that someone hasn't tried already. And I hear that person in the back who says kde-cygwin is here. Here I am laughing back at you. Tell any average person that you have to install an "emulator" to run the app and they will almost laugh at you too. cygwin is not the answer. Qt runs natively on windows so why can't kdelibs? Also we would also be relying on 2 other sources (qt and cygwin) for portability. Having it be as simply as a recompile is a much better solution.

What do we see in every other story? Some dude asking the developers to speed up the apps. Adding another library is not the way to do that! Just think if we had this lib so that the windows users could run kde apps. I can just see the 10 million posts asking why is "kde" slow for them. Doesn't matter that it is qt only they saw some kde thing somewhere...

Back in the day developers wrote qt only apps because more people would install qt apps the kde apps (yah people are morons). Now the license issues is just about forgotten and more and more people are using kde. So it is time to port to kde right? Wrong, along the way qt dangled this little cross compatibility thing in our faces. Our little linux app suddenly was usable on our friends, parents, girlfriends parents, etc machines. Granted we didn't get much of any developer support from windows users (can you please add this huge ass feature for free, yesterday? Oh and thanks for the app! -anon user), but having your mom run your little xyz app on her work machine and her pride when she can show everyone (even if she never uses it) was worth it. So why should I port my app to kde? I could try ifdefing all over, but doing that will only make things worse.

If we make this library then we will be like Microsoft in just applying a layer over hacks rather then fixing the real problems (think 16 bit days). What is worse is the fact that all of this new code means new bugs. Tightening, cleaning house and removing old code is better then adding new items if possible. In QT 3.0 there is a settings class called QSettings. It does something very similar to KConfig... Is the kde group going to drop KConfig and use QSettings? No (correct me if I am wrong), should it? Yes. Why? Because it is just another splinter, another layer, another level of confusion. Developers do not need the anoyance of deciding which one to choose. (re-read this paragraph with your own personal k* vs q* class annoyance) If I could honestly choose I would say that a lot of the duplication that KDElibs does should be ripped out and given to Trolltech to incorporate into QT as a gift of thanks for all of the free work they have done in qt. Heck this would remove a layer of virtual functions and make all kde apps just that little bit more faster, haha! (and even if we couldn't do that for legal reason fazing out the kde class should be the next option) If this qt/kde lib were to be made then we should ditch the kdelib. Why you ask? Because the point of this is to give applications a very similar look at feel, but if there are two different libs kdelibs and qt/kdelibs then there will always be differences no matter how hard we try.

Lets talk about new developer. How about commercial developers? They all only use qt and don't even think about using kde. Now if the kdelibs were cross compilable then they would link to them and simply distribute both libs. (back to the 2 libs issue, but nonless) There are some developers who have qt and kde apps with ifdefs, but it is time consuming, anoying and creates messy code. Even then they choose to use the qt class over the kde one every time just to make their job easier. This means that their app doesn't look exactly like other kde apps. Small, but in the end it shows. Remember Corel? Remember how they had some dude go around and make everyone clean up their apps to act the same? Remember how just yesterday you read about that _again_ in some magazine as a reason why kde comes off so clean? If this library solves that completely why would we need kdelib, why not break apart kdelibs into a cross platform section and another part that is for "kde apps"? Oh wait, but then developers wouldn't use the "kde apps" library which is were we are right now. The library is only a temporary solution to the problem.

Adding yet another layer will do kde little good. Heck when I read this story my first though was hey I can now port my kde app *from* kde to qt and use this little lib for the fun gui stuff. Course I would rip out a lot of extra kde functionality, but I get to compile on windows! I am sure that I am not the only developer who thought this before even finishing the title of the article. This library wont convice any qt developer to port their app over to kde, if anything it will stall them even longer if not forever. This only hurts kde users. I am willing to bet anyone that the qt/kdelib will cause more apps to be written qt only then kde only. Granted it may make the kde desktop larger, but it will only cause in the end someone porting kdelibs. The kde group has to either merge their kde code in qt (give it to them?) or make sure that the kdelibs works everywhere that the qtlibs work to stop this compitition of which library to compile for.

What we are really talking about is a replacement for kdelibs, but then we are back to where we started aren't we?

I vote to either a) make kdelibs cross compilable or b) Donate kdelib code to trolltech/etc and begin to faze out kdelibs in favor of qtlibs or something like that. Maybe Trolltech will include the kdelibs into the QTlib if we ask them nicely so then anyone who downloads the qtlib will get both. :) Choice B is probably the harder to do of the two (rewriting it all? contacting all of the authors? setting up so that patches in the future are signed over to trolltech?, etc), but in the long run will benefit *everyone* much better then any hack. KDE was ment to be a desktop envoirment, not a core widget lib (although we did start making one at one point) And for those that don't want to give up their code to trolltech you can remind them that as long as trolltech is around it will go into the GPL version of the code along with their own commercial version. I hate people that complain about the gpl qt code and how they can't sell their own little apps without giving away the source. They want to use something for free and make money off it. They sound like my friends who sell crappy windows shareware using a warzed version of vc++ and still complain. Maybe this is what should be the target for KDE4.0 The removal of the classes that are extensions of what QT already has and only have classes that QT doesn't have. Maybe have someone at trolltech who will add the core widget stuff that kde needs to QT. KDE is about the desktop and not the widget set.

-Benjamin Meyer

P.S. I am sure that someone out there will pick apart some little sentence in the middle of this in an attempt to flame me back. Before you do *please* think first if what I really meant and get across sloppily at 2am and then make constructive critizim on that not my horrible english spelling skills. Oh and don't bother repyling to my rants for I will ignore you, they are offtopic.

P.P.S Can someone that is allowed post my response to the kde-core list? Thanks.

by Julien Olivier (not verified)


I couldn't agree more with you !

Maybe because I'm an app developper and not a kde-core developper.

There is only one thing that I'd like to comment:

>> Maybe this is what should be the target for KDE4.0 The removal of the classes that are extensions of what QT already has and only have classes that QT doesn't have.

If what you say (Plan B) happens, every single developper in the world will write QT-only applications. That's obvious.
So now the problem is: why developping classes that fit only in KDE and not in QT ? Nobody will use them anyway !

I think that if things go that way (which I expect), KDE specific classes should be used only in KDE Desktop specific apps: kdesktop, kicker...
But, in fact, what is in KDE that couldn't be proted to Windows or Mac (and thus, integrated into QT) ?

Another question (not a flame, I swear): If QT includes all the KDE stuff, won't it be slower that before at a point that all QT-only apps will lose performance ?

However, I know that including KDE classes into QT would be a VERY huge work but that would really be a great step for linux (not only KDE). That could also give a good idea to gtk-gnome developpers to merge everything in one portable lib too.

by Benjamin C Meyer (not verified)

Ok, Maybe I should have put B first and then A. I am not saying that we have to intigrate KDElibs into QT simply that was one crazy possiblity. Making the kdelibs cross-platform compilable is the closest things to a good solution I can think of at this early in the morning. The only problem with it is that it will take some time and some time is not now and people want things now rather then right.


by Bojan (not verified)

I couldn't agree more with Benjamin C. Meyer's posts.

by Benjamin C Meyer (not verified)

Ok, had some coffee

The cause of the problem (developers/companies sticking to qt and not using kde's core libs) stems from the fact that they wish to port to windows.

The reason why kde wont benefit from a "qtkdelib" is that for most of the application developers, having the file dialog the same as kde is all that matters, having the default select clicking in a treelist be double click isn't. It is the little thing, icons, focus etc that will through off the user as they move from kde application to qt application whom will look similar, but behave differently.

What I fear is that open source developers will stick to Qt simply so that they can compile their app on windows sacrificing any features kde could add to them. Thus makeing the kde desktop "broken" (like how netscape has a different copy paste sceme then every other app in unix. It is "broken" to most first year cs students here at school until they figure it out).

The kdelibs encompass many things. A set number of them, KApplication, KTextView, etc are little more then small additions to Qt widget so that they can better incorperate into the desktop. These core widget specific items are what make up the look and feel of the application (default double clicking in a treelist for example) Putting these classes in a seperate library that can compile on windows will allow commercial/noncommercial developers to use them. On the windows side KFileDialog etc would simply pass right to the QFileDialog (and windows file dialog) while on the unix side it would have our kde file dialog. Then when these apps are combined with kde they will behave similarly with the rest of the desktop. Then when these application wish to add kde specific library functionality (kspell for example) there are only a few ifdefs that are easy to manage rather then the nightmare of hundreds of little ifdefs surrounding kapp and qapp. These new ifdef additions do not effect the ui, but only effect the feature fill of the app.

Having a simply small ui library concisting of all of the KAction, etc classes that was cross-compilable with windows would allow people not to worry about which library to base the application on and simply the kde one. They would then feel more at home when wanted to add more specific kde features on the unix side. And even if they didn't add any specific kde features it would still work and feel right along with kde.

The problem is developers and companies not wishing to utilize kdelibs simply because they wish to cross-port. Lets remove that problem for them.

-Benjamin Meyer

by Rumcajs (not verified)

If there are volunteers to do such port, please reply to this mail. I'm sure that we have thousands of them soon and I'm sure that you, Benjamin, already started the port on MacOS/X. Hey, why we have to work on some small hack for a month or two, when we could have redesigned/rewrited KDE API just in a few years and surely all commercial companies wil be using it instead of Qt, no doubt. I'm sure that our KDE developers didn't clean the API and it had been you to tell them to do it.

by Benjamin C Meyer (not verified)

I am confused, was this a flame? The above post was simply saying that to get qt apps to look similar to kde apps they need the kde ui stuff so we should remove that from the kdelibs into its own lib so that it can be used on windows, linux and mac. That would be cleaner then a libqtkde


by Rumcajs (not verified)

I was joking, of course.
It is easy to say but hard to do. I think that it isn't as simple and would require much efforts and time, ( how many have we developers, packagers and testers, which have both MacOS and Linux. ) I see also no advantages over libqtkde. Instead of Qt available on a few platforms ( kde, x11, win, mac ), you proposed KDE libs available for a few platforms ( qt, win, mac ).

by Benjamin C Meyer (not verified)

The advantage is that the applications will behave the same.


by David Johnson (not verified)

Port KDE to Qt? I'll help. I fully agree with Ben's proposal. Take all the KDE widgets and dialogs and put them in Qt. Trolltech would have to do most of the work, but I would be more than happy to take an app or two and rip out the ifdef spaghetti.

by Benjamin C Meyer (not verified)

The widget stuff barely require much of a port for they are all generally very simply with a few items to clean up. Giving them to Tolltech wouldn't solve the problems, but makeing the widgets into their own lib would help. FOr that lib would be cross-compatible.


by David Johnson (not verified)

99.99% agreement. The 0.01% disagreement comes because I think there is a significant number of developers who choose Qt-only because it imposes fewer dependencies on the enduser.

But I couldn't agree more on your overall assessment. Too much stuff in kdelibs is merely window dressing for Qt. Way back in history it made sense. KDE was an application framework while Qt was just a gui toolkit. But now Qt *is* an application framework. Let the KDE libraries provide only what Qt does not provide. Keep KIO, kparts, etc., but throw out the KDE dialogs, widgets, etc.

I don't use GNOME, and I think they made some bad mistakes. But they do one thing right. They have only one widget toolkit, GTK+. For the most part, GNOME is not a layer on top of GTK+, but non-GUI stuff to complete an application framework. This is why GTK-only apps integrate so well with GNOME, because GTK-only apps have nothing to fight.

There is no reason in the world for KDE to have its own file dialog, color dialog, toolbar, etc.

by Benjamin C Meyer (not verified)

KDE's File, color, toolbar etc are good and shouldn't be dropped the problem stems from little things. We shouldn't through away all of the extensions that we have made to Qt, but make it so that people want to use those extensions. Having them inside of a non-cross platform compatable class is not that way.


by Neil Stevens (not verified)

It's *all* needed, the kdelibs, to make a KDE app.

As for making kdelibs portable, it'll happen. kde-cygwin is a start, but not the end.

Rik keeps saying he likes it, and gradually sells more and more people on the idea (even me), and eventually someone's going to code it. :-)

by Neil Stevens (not verified)

As for the about box, send a patch.

As for KConfig, KDE isn't going to drop it in favor of a class that does far less.

As for donating kdelibs to Trolltech, Trolltech already can use kdelibs as much as they want. It's free software. They just can't make proprietary versions of the LGPL parts. Don't blame KDE because Trolltech will use only software they can make non-free on Windows and MacOS.

As for making your app available to friends: If you want to code for Windows, code for Windows and accept the consequences of certain facilities not being available. Or, rather, your friends have chosen their OS, and they have to live with it.

by Jeff Brubaker (not verified)

Could it be possible so gnome/gtk apps could use it to? They could benefit greatly from the kioslaves and the kdeprint mechanism.

by coba (not verified)

they can already use the kdeprint mechanism, all they have to do is use kprinter as printcommand instead of lp

by Iuri Fiedoruk (not verified)

I think this would be great.
We need REALLY BATTER integration between apps made with gtk and qt.
If they could support drag-and-drop, bahave the same way and look the
same way, it would be like if gtk apps where qt and vice-verse depending on what enviroement you where running (kde or gnome or other).
I know this would be difficult, but in a XML age we are now, I don't see this as impossible, and woud make much more easy to use *nix, nas all apps would bahave as the desktop asks them to do.

by Kevin Krammer (not verified)

While I really like the idea to have Qt apps using advanced KDE technolgy like KIO, I am afraid that the construction of a second X11 like platform will create bad echo from the Linux/Unix user community.

Right now you can use a Qt app on GNOME or with just a windowmanager without loosing functionality.

So, while we know that actually the KDE users get an enhanced verion of the app, GNOME users might feel they get a light version.

Moreover, a user using both environments, might feel he/she is "forced" to use KDE if he/she wants the real stuff.

Perhaps this could be avoided by defaulting to Qt only and use KDE enhancements only when asked to do so.
(by commandline switch or configuration item).
An example for this behaviour is licq's Qt GUI. By default it wil work the same on all Desktops, but it can be, if the users decides so, be enhanced for KDE use (at compile time ony AFAIK)