[PATCH] BR57204 mailto: urls don't work when kontact is running.

[Ingo Klöcker]

On Monday 15 December 2003 21:57, Waldo Bastian wrote:
> On Mon December 15 2003 21:18, Ingo Klöcker wrote:
> > > * KMail command line options may not get translated correctly.
> >
> > Okay, this will fix the KMail case. Any idea what we should do when
> > we want to call KAddressBook from KMail (e.g. if the user selects
> > Open in Addressbook from the context menu for email addresses?
> > Currently we use startServiceByDesktopName("kaddressbook") which
> > starts KAddressBook externally if the address book part hasn't been
> > loaded yet in Kontact and in case the address book part has already
> > been loaded nothing happens (except for the startup notification
> > which blinks until it times out). Both is wrong because in both
> > cases the Contacts part should be brought to the front in Kontact.
> > The second case can easily be fixed by first checking if we can
> > contact kaddressbook via DCOP. But what about the first case? Will
> > a similar solution as the one for kmail also work for kaddressbook?
>
> Yes, create a "kaddressbook" DCOPObject that provides a newInstance()
> method, similar to the one I added for KMail.
>
> However, I think you need a bit more than that, because with that
> alone you will get inconsistent behavior depending on whether kontact
> has loaded kaddressbook already or not.

I don't understand. In both cases the Contacts part would be brought to 
front. Which inconsistent behavior do you mean?

> I can think of two ways to solve that:
> 1) Load kaddressbook when starting kontact

That won't happen. It was already hard to swallow for Cornelius that 
kmail is always loaded when starting kontact. But in the future we just 
want to load the parts that are really needed. So no assumptions about 
already loaded parts can be made.

> 2) Intercept calls to start kaddressbook somehow
>
[snip]
>
> Oh, and my patch assumes that kontact always loads the kmail part. If
> the kmail part is not loaded after startup, command line arguments
> will not be processed. I am not sure if that assumption is valid in
> all cases.

For now this assumption is valid.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031215/5f994ae2/attachment.sig>