[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 6:54:00
[Download RAW message or body]

Am Dienstag, 3. Juni 2003 00:36 schrieb Zack Rusin:
> Hi, well this is probably the most desired of our goals for the
> not-so-near future, but definitely not the way you're doing it. The way
> you're doing it, has pretty much no appeal as the gui is still a
> compile time dependency therefore nothing changes except the fact that
> there's another level of method calls.
> The patch you presented gain us nothing. The idea is that we need to
> seperate core from gui but not as a compile option, but a run-time one.
> Meaning one core is running and you can have twenty gui's for it
> running. One in a terminal, one in a remote X session, one in a local X
> session etc.

Hi Zack,

as I wrote I've no problem to discard this little piece of work. However 
your criticism is not very informative in the sence of how to do it, except 
that you mention compile time independency.

What kind of communication do you want to use between kernel and UI? (You 
need one to prevent compile time dependencies, or would you like to load 
libs dynamicly?)
What are in your opinion the necessary steps to reach the final goal? Do you 
plan a big step made by some developers working through some nights to 
split logic and UI?
I would prefer little steps (like building a mosaic picture) which are 
possible along the normal release cycles. For example, my patch is no big 
deal (as you've stated correctly), but it separates UI code and logic in 
different classes. This makes further refactoring easier, because then you 
can focus mostly on the UI related classes. And you have some kind of 
callbacks ready no matter what kind of calls/communication you'll use 
later.

Can you try to draw a "big picture" how to continue best. I'm interested in 
your and other's opinions about the way to go, and I think, the discussion 
could bring some light on this issue.

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]