[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: ClientInterface (was Re: Fwd: [PATCH] kernel / UI separation -
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-07-20 12:58:57
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
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 = 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 
completely independent from whatever we decide about the separation 
Andreas can start to work on this without having to wait until we 
finally come up with a decision concerning a separation of core/UI.

Regards,
Ingo


[Attachment #5 (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]