A little review of kdecore & kdeui
kevin.krammer at gmx.at
Fri Apr 7 20:51:49 BST 2006
On Friday 07 April 2006 21:11, Aaron J. Seigo wrote:
> On Friday 07 April 2006 11:35, Kevin Krammer wrote:
> > Qt would rely on it, we have to provide it.
> which is not necessarily the same as kde libs relying on it.
Indeed. Though especially the case of the preferred application launcher might
be something that would be worthwhile.
I am thinking about a situation where a KDE application runs on a GNOME
desktop and launches the application according to GNOME settings.
Anyway, an almost optimal thing would be if Qt allowed better application
For example Qt3 on X11 pretends it is always using NAS as the backend for its
QSound API, while it actually, but very hidden, can use any implementation of
QAuServer. An application which has the possibility to do compile-time KDE
integration (e.g. Scribus) can use an aRts backend, but this option is very
likely not used anyway because nobody knows about it.
Same for KIO backend of Qt3's QUrlOperator API
It goes obviously to far to do this via plugins with all this compatability
problems, but for example this application overrideable service provider
infrastruture in Java allows KJAS to offer KIO based networking to applets
without having to hack Java library classes or similar hacks.
For the active label I could imagine something like
static bool QLabel::registerURLHandler(QObject* receiver, const char* slot)
KInstance (or whatever is central to all KDE applications) would then register
a KDE based launcher object
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel