Desktop services (was Re: A little review of kdecore & kdeui)
thiago at kde.org
Sun Apr 9 18:45:15 BST 2006
Aaron J. Seigo wrote:
>> We've been doing this already a bit and nobody seems to have noticed.
>not sure what you're talking about ... ?
Desktop activation is handled through a DCOP call to klauncher. It's
already out-of-process. It's already done through IPC. And in KDE4, it
will be D-Bus.
DCOP is going to go. Why not use the API that we are going to implement
ourselves (e.g., DAPI)?
This would be yet another reason why DAPI should use D-Bus, since it DAPI
and our *native* calls would be the *same*. I fail to see how
yet-another-IPC-mechanism, implemented in DAPI, is advantageous. D-Bus
was *created* to solve that problem and yet, when the time comes to use
it, DAPI chose to implement its own protocol.
Please, please, switch the backend there to what we will use natively.
But back to the question at hand (rant mode off): we already are using IPC
to launch services. And not only are we implementing an IPC mechanism to
launch services for ISVs, we're recommending that they use it. Why should
we not follow our own advice? We'd be setting the example. The
alternative is to say, "here's a nice API for you to use, but we're not
using it in our own product, sorry."
At least for service activation: I don't think we should implement it for
file dialogs or print dialogs, for instance, if that's what you're
asking. We have our own visual identity: a KDE app will always look like
a KDE application.
As for your example:
>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.
Why should a KDE app behave differently than all the rest wrt to that? Ok,
the setting didn't apply, but in your scenario, KDE applications would
launch epiphany, while everything else would launch firefox.
Either way it's broken, of course.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel