A little review of kdecore & kdeui

[Kevin Krammer]

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

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

Cheers,
Kevin

-- 
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
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060407/62273f86/attachment.sig>