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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)
From:       Andreas Gungl <Andreas.Gungl () osp-dd ! de>
Date:       2003-06-03 11:57:28
[Download RAW message or body]

Am Dienstag, 3. Juni 2003 12:53 schrieb Zack Rusin:
> On Tuesday 03 June 2003 09:45, Cornelius Schumacher wrote:
> > With changes like the ones from Andreas you are free to choose, if
> > you make the gui a compile-time or a run-time dependency. By using an
> > abstract class interface to access the GUI you can move a concrete
> > GUI implementation into a module loaded at run-time.
>
> It can't be run-time, unless you want to invent another plugin
> mechanism. All gui's would have to be implemented right in KMail
> sources. Furthermore every app which intended to use the core for
> whatever reason would have to implement a huge number of interfaces, to
> just get for example a number of emails in a folder.

Zack, I can follow your argumentation. See comments below.

> Now the question how to do it is a little more complicated. Personally I
> like the way Outlook does it - meaning that the gui asks the core for
> some specific info and the core just sends the data. So for me DCOP
> communication. I've been testing this a bit with geiseri (Ian). The
> problem was that DCOP communication is not concurent and it blocks
> waiting for the prior request to finish. The speed of individual
> transactions is definitely fast enough (besides geiseri is optimizing
> the hell out of it, including some "communication over shmem" patches).
> And that would be _my_ ideal solution. Having the core running and apps
> just requesting the data they need would be ideal. That would be
> complete abstraction, where apps that KMail core had no idea about
> could request the same data the official KMail gui could.
> So that's the way I see it :)

That still doesn't answer the question how to get there. I see my example as 
a proposal for how to separate logic and UI in a first step. That doesn't 
prevent anyone from any further steps. In the opposite, I believe this 
makes the next steps easier.

If I understand correctly then you don't want such a fine grained coupling 
of UI and logic as I did. Well, in this small piece are a lot of callbacks 
when the code for the logic remains mainly untouched (except for the 
function calls). Instead, if you want to have better abstraction (coarse 
grained coupling), then you'll also have a lot more work with the logic. In 
my example, this would mean to define much finer return codes (e.g. 
enumerations) for the methods which trigger any UI interaction. The return 
codes need to get passed some layers (in the call stack) upward, so that 
the UI "shell" can react appropriate. Did you think about that, resp. is 
this what you intend?

Regards,
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]