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

[Lubos Lunak]

On Sunday 09 April 2006 18:38, Aaron J. Seigo wrote:
> 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...

 Primarily for those, but that doesn't necessarily mean KDE apps can't use it 
either. I don't know yet, it's probably too early to say.

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

 It's of course always possible to remove bugs by removing everything. But we 
simply do have lower parts of our stack sometimes needing higher parts, and 
some people would probably like KDE apps integrated even in their 
environment. As for the circular dependencies, I think you're overestimating.

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

 You mean the same brilliant system integrator that currently can simply patch 
KDE?

> > > 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 ... ?

 We already have lower parts of kdelibs using functionality from higher parts 
of kdelibs this way (launching from kapp via klauncher).

> > > 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?

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

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/