[Kroupware] KMail als KParts-Container.

[Karl-Heinz Zimmer]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo Michael,

damit Du nicht denkst, wir fragen Dich erst freundlich und machen dann
doch, was wir wollen, hier (mit CC an die Kroupware-Liste) der Plan in
Punkto KParts:

*  Wir bauen KMail so um, dass es (per KParts-Technologie[1]) den
   KOrganizer aufnehmen _kann_ - n=E4mlich speziell f=FCr die von Kroupware
   abzudeckenden F=E4lle (z.B. MIME Message mit vCal-Bestandteil, welcher
   mit KOrganizer zu bearbeiten ist).

*  Dies f=FChrt _nicht_ dazu, dass KMail nun alle m=F6glichen KParts anzieh=
t,
   sondern beschr=E4nkt sich bloss auf unsere Anforderungen hier.

*  Sollten wir uns nach Projektabschluss nicht einigen k=F6nnen, weil in
   der KMail HEAD-Entwicklung die Bedenken =FCberwiegen, werden wir unsere
   =C4nderung weinend aber brav so zur=FCckbauen, dass wir ohne KParts
   auskommen.

Es geht uns nicht darum, hier unumkehrbar Tatsachen zu schaffen, sondern
bloss, unser Ding rasch durchzuziehen: wir sind im Notfall bereit, nachher
in Absprache mit Dir/Euch eventuell noch umzubauen, aber erst m=FCssen wir
unsere sehr knappe Deadline schaffen.

Viele Gr=FC=DFe,

Karl-Heinz   (Reply-To auf Kroupware-Lste gesetzt)


[1] Das Konzept hat Steffen wie folgt formuliert:

  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.
  >
  > 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.
  >
  > 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.
  >
  > If the korganizer part doesn't load, the user probably doesn't
  > have kdepim installed at all, and we just act as "old" kmail.

=2D --=20
Karl-Heinz Zimmer, Senior Software Engineer, Klar=E4lvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.91 (GNU/Linux)

iD8DBQE9fxVLCcaVnbvggDcRAuDQAJ4wrREpzyuHC993OQi2s7cT3ZMTHACfdwtP
zOqa9Af5OMl14lm4Xis58II=3D
=3DTy+7
=2D----END PGP SIGNATURE-----