From kmail-devel  Sun Jul 20 12:58:57 2003
From: Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date: Sun, 20 Jul 2003 12:58: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=105870602422098
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============42930888536398548=="


--===============42930888536398548==
Content-Type: multipart/signed;
  protocol="application/pgp-signature";
  micalg=pgp-sha1;
  boundary="Boundary-02=_SIpG/9LSobidjba";
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


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

On Sunday 20 July 2003 00:28, Andreas Gungl wrote:
> As I have thought a lot about the separation and as I've dealt with
> DCOP, I want to make a suggestion from which I do hope that it's a
> good chance to reach a consensus.
> We should start without DCOP but use the current C++ and (where
> usefull) Signal/Slot mechanisms. This is to
> - avoid a lot of work writing the DCOP related code for streaming the
> data and handling errors in the DCOP layer
> - simplify debugging in this early stage of the separation process
> - avoid unnecessary risk in the 3.2 release in which the separation
> will certainly not be finished.

Since we have to remove all UI code from the kernel before we can think=20
about a separation, I think this is a good first mile stone.

> Even without DCOP we'll have to decide a lot of details. Let's say
> you have the following (pseudo) code somewhere in the core:
> deep_in_core_function()
> {
>   do(something);
>   miss_some_data;
>   okay =3D open_password_dialog(i18n("user information"));
>   if (okay) {
>     do_my_work();
>     Messagebox("i18n("everything okay"));
>   }
>   else
>     finish();
> }
> IMO the function has to be rewritten to have return codes (others may
> prefer exceptions) to signal that an user interaction is needed
> outside the kernel code. So the function should not return "true" or
> "false" but "done", "failed", "password_needed_retry_possible".

Definitely.

> Second, it's not a good style to keep UI relevant information like
> the text for the messagebox in the core. It was easy to program it
> this way in the beginning, but if you want a consequent separation,
> then the text belongs in the UI code.

Agreed.

> Doing this little bit of refactoring will be a lot of work even
> without DCOP. You should also keep in mind, that a good separation
> simplifies the introduction of DCOP when we find out that it's really
> needed. It could be done in a very short time then. And it could be
> done at any time.
>
> But currently it would make sense to concentrate on code like the
> pseudo code above. Resolving some of such code for 3.2 is a realistic
> goal and might help to clean up the application and to prepare the
> way for further changes or enhancements. OTOH this way allow us to go
> with little steps. It's not something which is done better in one
> step like a
> "KPartification". And these little steps are why I would like to work
> on it. I cannot guarantee to have time to make big changes in one
> rush as sometimes needed for the Kolab related work. But I can do one
> small improvement after another.
>
> I hope, that you can accept this suggestion. In this case I would try
> to provide another patch. Otherwise I'll wait for a decision in NH.

At least I think this is a very good suggestion. As this cleaning up is=20
completely independent from whatever we decide about the separation=20
Andreas can start to work on this without having to wait until we=20
finally come up with a decision concerning a separation of core/UI.

Regards,
Ingo


--Boundary-02=_SIpG/9LSobidjba
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/GpISGnR+RTDgudgRAn4cAJ4z8GzcKdbjoiRhJjOA8N11SbwpZwCfVRQ1
veOVKIcfDqlb1BN8OvUcexA=
=uz9p
-----END PGP SIGNATURE-----

--Boundary-02=_SIpG/9LSobidjba--

--===============42930888536398548==
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

--===============42930888536398548==--