Desktop services (was Re: A little review of kdecore & kdeui)
l.lunak at suse.cz
Sun Apr 9 15:59:31 BST 2006
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?
> 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
> 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
> [two app -> whatever -> desktop API pictures]
I either don't get these two or they're wrong.
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/
More information about the kde-core-devel