Desktop services (was Re: A little review of kdecore & kdeui)

[Aaron J. Seigo]

On Sunday 09 April 2006 08:59, Lubos Lunak wrote:
> Dne sobota 08 duben 2006 00:37 Aaron J. Seigo napsal(a):
>  Hmm, am I the only one who remembers the session at Akademy about
> reorganizing kdelibs/kdebase and Rudi[*]? Apps not linking all of our libs
> just because they want a file dialog? Stuff like that?

yes; my question is whether that applies to full-blown KDE applications or if 
RUDI/DAPI is primarily for Qt/Gtk+/Motif/WxWidget/etc apps...

> of things. So, if Qt needs it anyway, and we're going also to provide the
> desktop service, why not simply connect them, instead of trying to handle
> us as a special case?

we wouldn't be a special case. we'd simply be calling the appropriate APIs 
already in our libraries. unless that suddenly becomes a "special case" of 
how to use an API. it's not like Qt is going to provide these services, they 
are going to be found elsewhere such as in shell scripts, in kde libs, gnome 
libs, whatever... so in the optimal (for us) case, all the logic will still 
be in our libs. accessing these things through a more complex route seems 
like it's just setting ourselves up for odd / unexpected / undesirable 
effects; it's classic KISS principle.

if a Qt app calls into KDE libs via DAPI, great. if a KDE lib calls into Qt 
which calls in KDE libs, then the potential exists for KDE libs to recurse 
back into Qt and ..... all this for what? to avoid one class in this case 
that keeps us away from the possibility of headaches that come from circular 
dependencies? yes, we can be very careful and be sure that all DAPI-called 
interfaces do not result in calls to other DAPI-backed interfaces. or we 
could just remove the need to be careful at all and guarantee success.

and personally, i'll be waiting for the first bug reports along the lines of 
"i set epiphany to be my default browser in kcontrol, but firefox keeps 
launching anyways!" because some brilliant system integrator decides to make 
DAPI use a non-KDE backend at all times on their platform.

> > i'm concerned about it working -slower-,
>
>  We've been doing this already a bit and nobody seems to have noticed.

not sure what you're talking about ... ?

> > with greater complexity
>
>  That's questionable. Increased complexity in one place, decreased
> complexity in another.

where is the complexity decreased? by having the initial calls happen 
elsewhere, in this case in Qt?

> > and with less control on our side over what actually happens
>
>  When we are actually both sides (Qt/KDE libs client-side and KDE services
> server-side)?

DAPI decouples these things, of course.

> As for other desktops, if their users would think the best 
> way to launch a browser is to do something weird, why should we spare them
> their joys?

because there are more sane ways of achieving that for KDE apps, and whenever 
something odd happens in a KDE app it's not the infrastructure that gets 
blamed it's the thing the user can see. it also means that DAPI no longer 
becomes a set of basic, least-common-denominator services but becomes, for 
what DAPI provides, the entirety of what all apps are capable of no matter 
how right their native APIs could be. this seems like a step in the wrong 
direction.

DAPI is a great hammer, but let's just use it on the nails and leave the 
screws alone, ok?

> > [two app -> whatever -> desktop API pictures]
>
>  I either don't get these two or they're wrong.

the former.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060409/aee45765/attachment.sig>