[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt-only KDE applications
From:       Shawn Gordon <shawn () thekompany ! com>
Date:       2002-01-22 14:56:06
[Download RAW message or body]

This has obviously been an issue for us, and at the moment we are also 
using all Qt3.  With Rekall we have our build system set up to produce both 
Qt and KDE versions (I'm not exactly sure how Mike has this set up, but 
it's there) and our objective for the last year has been to have our Qt 
apps behave like KDE apps when running under KDE - to that end we even did 
some work on it to see what it was going to take.  Our basic assumption is 
that if they are running on linux, then they should be running under KDE, 
but there are still people who use our stuff under Gnome or with no window 
manager.

So the short answer is: yes, this would be very useful for us and make our 
lives much easier.

Shawn

At 04:45 AM 1/22/2002, you wrote:
>Hi,
>
>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
>         friends)
>
>- 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
>code.
>
>Technical, the simplest approach does not even require changing Qt or
>KDE:
>
>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
>functionality.
>
>
>Opinions? Do you think that would be useful at all?
>
>
>Matthias


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
949-713-3276


[prev in list] [next in list] [prev in thread] [next in thread]