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

List:       kmail-devel
Subject:    Re: [PATCH] ClientInterface (next try)
From:       Andreas Gungl <Andreas.Gungl () osp-dd ! de>
Date:       2003-07-28 9:00:11
[Download RAW message or body]

Am Montag, 28. Juli 2003 00:55 schrieb Ingo Klöcker:
> On Sunday 27 July 2003 00:16, Andreas Gungl wrote:
> > Hi,
> >
> > as discussed long enough on this list, this time I tried to use an
> > approach to separate only existing core and UI code. Those who
> > reviewed my last patch will have it easy to compare to this one. I
> > used kmsender as an example again. And again two issues are open (the
> > interactive messagebox and the password dialog). Both require
> > significantly more work, so before I continue I better ask about your
> > opinions now.
> > Special hotspots are:
> > - Is my choosen way of handling the strings for the UI okay?
> > - I used direct calls to the KMClientInterface's methods. I believe
> > that this is appropriate for the moment. If necessary we can switch
> > to signals/slots later.
>
> Are those calls necessary at all? Wouldn't it be much better, i. e.
> cleaner and easier to implement, if the core methods would simply
> return an error code. And then the UI code would display an appropriate
> message box.

Hi Ingo, 

Perhaps you're right. I did it this way because I can work only on display 
related code right now and change the involved logic later. Also, I'm not 
sure how we should solve the problem, that often a simple return code is 
not enough to be able to display the appropriate information to the user. 
E.g. if you need to know the transport protocol for which the sending 
failed - how do you want to transfer that information to the client? You 
might ask the core after you've got the error / return code. But this might 
work only in non-parallel environments.

I just want to let you know that I see this problem too. My approach is to 
use a QStringList to transport those pieces of information to the client. 
If there is another good idea to improve the current implementation, I'm 
willing to change it immediately.

> The progress info probably has to be implemented with back-calls. But
> all those call-backs just to display an error message might be
> overkill.
>
> The two open issues could maybe also easily be solved by returning an
> error code and letting the UI code ask for the user's decision or the
> password.

I agree.

Andreas

_______________________________________________
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]