[Kroupware] KMail als KParts-Container.

[Cornelius Schumacher]

On Wednesday 11 September 2002 16:08, Steffen Hansen wrote:
> * Cornelius Schumacher <schumacher@kde.org> [Sep 11. 2002 13:10]:
> > Which menus and toolbars would you merge and where would you show the
> > KOrganizer GUI? For processing text/calendar objects you actually don't
> > need a GUI. You just have to make sure that the content of the calendar
> > object is decoded/decrypted/whatever and passed to the iMIP interface of
> > KOrganizer.
>
> Normal KParts menu/toolbar merging. And the korganizer part would appear
> where the khtml part is normally shown in the gui. Maybe the folderview
> above it should be hidden while korganizer is shown.

So you would use the KOrganizer part only for previewing the calendar object 
in a single mail or would it show the complete calendar after processing the 
iMIP message?

> But we are very much open for other solutions and good ideas, so the
> iMIP interface sounds interesting. Where would I find information about
> that? Is it powerful enough for showing large amounts of vCal data
> around?

The low-level interface is in korganizer/mailscheduler.*. The GUI is in 
korganizer/incomingdialog.*. KMail puts the messages into a special directory 
and KOrganizer then fetches them from there. It shows a list of incoming iMIP 
messages in a dialog and the user can accept or reject them. It would be nice 
to automate the accepting, e.g. for a list of known sources, maybe 
authenticated by a valid signature or something like that. This functionality 
would need some support from the KMail side to pass the required information.

> > It would be a much cleaner solution to make a small plugin for KMail
> > which is able to process certain mimetypes and passes the information
> > then to the seperate KOrganizer instance. You would need a generic plugin
> > interface in KMail for plugins which get called for mimetypes specified
> > by the plugin and get the information from the corresponding object after
> > the KMail specific processing. The Korganizer specific stuff would then
> > be encapsulated in the plugin and KMail wouldn't have any dependencies on
> > KOrganizer.
> >
> > >   > This can be done safely because we _know_ that we are talking to a
> > >   > korganizer part, and signals/slots don't give us any source-
> > >   > dependencies.
> > >   > For safety, we can even put a special "marker-slot" into the
> > >   > korg. part, and check for that to see if we talk to a Kroupware
> > >   > capable korganizer.
> >
> > This sounds extremly ugly. You will lose all type and function signature
> > checking the compiler does. This makes debugging a much harder job than
> > it should be.
>
> This is no different than connecting any two QObjects with
> signals/slots -- you dont see the type errors before runtime. If korg.
> already has a welldefined interface for the things we need, it might not
> even be nessecary to connect additional signals/slots.

In my experience delaying error checking to runtime is asking for trouble. 
Debugging signal/slots problems is no fun.

What about my suggestion with the plugin interface? This would keep KMail 
clean from dependencies on KOrganizer.

-- 
Cornelius Schumacher <schumacher@kde.org>