[Kroupware] KMail als KParts-Container.

[Steffen Hansen]

* 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.

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?
 
> 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.

wkr.
-- 
Steffen Hansen

Senior Software Engineer, Klarälvdalens Datakonsult AB

email: hansen@kde.org, steffen@klaralvdalens-datakonsult.se,
       steffen@hrhansen.dk
www:   http://www.hrhansen.dk