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

[Lubos Lunak]

Dne sobota 08 duben 2006 00:37 Aaron J. Seigo napsal(a):
> On Friday 07 April 2006 15:19, Thiago Macieira wrote:
> > But think about it: why shouldn't KDE applications launch the GNOME mail
> > program when run inside a GNOME environment?
>
> it should launch whatever the user uses, not the mail app of the desktop.
> that's why have settings for browser, mail and terminal apps in kde.
>
> in another branch of this thread i mentioned the common mimetype spec, and
> really i think that concept holds here: these settings could/should be
> standardized as part of an extended spec for launching apps (which is
> obviously a superset of mimetypes) or just not bothered with.
>
> if we wish to go the route of "all launching should be desktop agnostic"
> then we really ought to push all this down the stack outside of all the
> desktop envs and have a single system service that takes care of all of
> this. then we aren't recursing back into the desktop env, we aren't
> changing defaults just because the user logs into a different desktop and
> it makes it really clear where this stuff is owned.
>
> but then we'll end up with more crap written in C with lowest common
> denominator concepts because outside of any of our given silos nobody can
> make anyone those with the lowest requirements budge. and, of course, we'll
> just end up wrapping that API to make it not so out-of-place.

 Sharing things doesn't necessarily involve also sharing C crap.

> while standardizing between desktops is a good idea and making it easier
> for ISVs to write software w/out being -requierd- to pick a desktop API is
> also good, i fear that sometimes we lose sight of the reasons we do these
> things and at what cost they come.

 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?

[*] Rudi == DAPI, more or less, as far as theory goes

 Anyway, it should be rather simple. Qt needs things like launching browsers, 
because there will be people writing Qt-only apps. Even libkdecore needs 
things like launching browsers apparently, and it actually already does 
exactly this - just check all the start_service_foo() methods in 
KApplication, they don't really do anything besides telling klauncher to take 
care of it. And DAPI is just telling some desktop service to take care 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?

 As for
> i'm concerned about it working -slower-,

 We've been doing this already a bit and nobody seems to have noticed.

> with greater complexity

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

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

> [two app -> whatever -> desktop API pictures]

 I either don't get these two or they're wrong.

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