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

[David Faure]

On Monday 15 December 2003 23:26, Waldo Bastian wrote:
> On Mon December 15 2003 22:16, Ingo Klöcker wrote:
> > 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.

I tried this approach, and the problem is the parsing of arguments... 
The set of arguments used by kmail is different from the set of arguments used by kontact.
I see that in your kontact.patch you basically gave kontact the same arguments as kmail.
But this doesn't scale up. In theory one should also be able to run "korganizer <file>"
and get that file opened in kontact's korganizerpart, if kontact is running.
Or just "korganizer" or "kmail" should bring kontact to front (and even better would be
to switch to that part, that's another problem).

For "kmail <address>" and "korganizer <file>" to work when kontact is running, I'd 
need a way to reset everything in KCmdLineArgs and give it a new set of options 
(e.g. the kmail options definition when "dcop kontact kmail newInstance" is called,
and the korganizer options definition when "dcop kontact korganizer newInstance" is called).


Attached is my current patch, which uses korganizer as a first step - for kmail I'll need
to integrate your refactoring of the cmdline-options-handling, of course.
In theory, typing "korganizer" should bring up the kontact window (even if the korganizer
part isn't loaded - that's why I create the dcopobject in the plugin, which is always loaded).

But the loadAppArgs fails since the command-line definition doesn't match the one
that was used by the saveAppArgs in the original (kmail/korganizer) process.
How can I "reset" the options definition in KCmdLineArgs?

The  KCmdLineArgs::addCmdLineOptions call in loadCommandLineOptions
fails due to assert(parsed==false). I guess I need a method that tells KCmdLineArgs
that I want to restart from scratch - forget about everything done before, here's
a new set of options definitions, and then I call loadAppArgs to 'parse' the actual
options.

> > > 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?
> 
> From what I understand (but I could be wrong here):
> 
> A) If kaddressbook hasn't been loaded yet, and you call
> startServiceByDesktopName("kaddressbook") it will start an external
> addressbook. (Why do you think that kontact would load the part and bring it
> to the front??)

Such code should be ported to KDCOPServiceStarter, so that kontact gets a chance
to load the part itself. I might have a look at that later on, for now I want to fix
the "kmail foo at kde.org" problem.

PS: Your patch includes an unrelated kiosk change for kmtransport.cpp  

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: df_kontact.patch
Type: text/x-diff
Size: 4021 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040104/7f9fcb96/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: korganizer.diff
Type: text/x-diff
Size: 1607 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040104/7f9fcb96/attachment.diff>