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

[Thiago Macieira]

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
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060409/d0425bf4/attachment.sig>