From kmail-devel  Sun Jul 13 23:00:57 2003
From: Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date: Sun, 13 Jul 2003 23:00:57 +0000
To: kmail-devel
Subject: Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI separation -
X-MARC-Message: https://marc.info/?l=kmail-devel&m=105813764320476
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============35637988096428264=="


--===============35637988096428264==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_qSeE/YI4jkaij8d";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_qSeE/YI4jkaij8d
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 11 July 2003 20:30, Andreas Gungl wrote:
> On Friday 11 July 2003 09:22, Don Sanders wrote:
> > Regarding the comment.
> > +// TODO - this needs effort to separate kernel and GUI
> > This issue should be resolved before the patch is committed to cvs.
> > Is it possible to use a SYNC dcop method to show a Yes/No messagebox
> > and return the result? Eventually we might be able to architect
> > KMail so that only ASYNC dcop methods are used, but I think it makes
> > sense to have a transitional period where SYNC methods are used.
>
> I've already thought about this issue, and I agree with you. It can=20
> get solved using a sync dcop call right now, but I also thought about
> a way to avoid such sync calls later. But this requires deeper changes
> in the existing codebase, I would like to concentrate on the dcop
> issue for now. I'll commit as soon as I have the TODOs eliminated.

I just returned from LinuxTag 2003 in Karlsruhe. During LinuxTag I=20
talked with Cornelius, Tobias (tokoe) and Marc about the UI separation.=20
No decisions where made but we definitely see the need to talk=20
about this some more because this is a very serious decision which will=20
have a very high impact on the future of KMail (So why Cornelius and=20
Tobias? Because they would like to use some of KMail's functionality in=20
KO resp. in KAB). Although I was at first quite enthusiastic about the=20
DCOP approach, the others don't think that using DCOP is a good idea.=20
So we really need to talk about this in a larger group. I would prefer=20
to postpone any decision until Nove Hrady where we will have the unique=20
opportunity to talk about this from face to face.

I'm very sorry, Andreas, for all the work that you put into this, but=20
please understand that we mustn't rush such a radical change into KMail=20
without giving it a lot of thought.

=46or KDE 3.2 we primarily have to concentrate on making Kontact a=20
full-featured and rock-stable Kolab client because that's what the=20
corporate users need. LinuxTag showed that a lot of people are waiting=20
for Kontact because without a working Outlook/Exchange replacement it's=20
impossible for them to even think about migrating from Windows to=20
Linux.

Regards,
Ingo


--Boundary-02=_qSeE/YI4jkaij8d
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3rc1 (GNU/Linux)

iD8DBQA/EeSqGnR+RTDgudgRAgKyAJ93f1XmUx08yzGefqAoRu4/PzdUGgCfXuCX
EXddAyxjhgGF24Knm3WeSXo=
=mwBq
-----END PGP SIGNATURE-----

--Boundary-02=_qSeE/YI4jkaij8d--

--===============35637988096428264==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

--===============35637988096428264==--