[Kroupware] KMail als KParts-Container.

[Cornelius Schumacher]

On Wednesday 11 September 2002 12:04, Karl-Heinz Zimmer wrote:
>   On Tuesday 10 September 2002 23:32, Steffen Hansen wrote:
>   (...)
>
>   > Please note that we do not want to turn kmail into a general
>   > KParts container (like konqueror is). We basically want to
>   > "hardcode" the KOrganizer part to be loaded for certain mime-types.
>   > We dont want kmail to embed other parts that match some mimetype.

Why do you want to embed a KOrganizer part in KMail? This doesn't make much 
sense to me. The GUIs are completely different, so merging menus and toolbars 
will be only confusing. The kaplan way to integrate KMail and KOrganizer in a 
common GUI is much nicer, because it doesn't create dependencies between the 
apps.

>   > My idea for getting around the problem with source-dependencies
>   > between kmail and korg. is to do something like this:
>   >
>   > If we see a mimetype like for example text/calendar, we fire up a
>   > korganizer part, and let the KPart mechanisms take care of merging
>   > menus and toolbars. The other kinds of communication between the
>   > korg. part and kmail can be done by connection signals and slots.

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.

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.

-- 
Cornelius Schumacher <schumacher@kde.org>