Desktop services (was Re: A little review of kdecore & kdeui)
Aaron J. Seigo
aseigo at kde.org
Sun Apr 9 17:38:25 BST 2006
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
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
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.
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel