On Tuesday 03 June 2003 00:00, Andreas Gungl wrote:
> attached you find a diff containing a first idea on how to separate
> the UI code from the processing code. It covers only the address book
> access in KMail.
> I formed an abstract class for the UI callbacks, then I inherited a
> class covering the current Gui interactions.
>
> I would like to have some comments on the patch, especially on naming
> conventions and related topics. E.g. the classes are named
> *GuiCallback, IMO it's better readable than *UiCallback, although
> text UIs are of course possible.
> There is no factory class for the callbacks yet, although one could
> be very handy later on. Perhaps somebody with a better architectural
> overview over the sources can give a hint about where and how to
> integrate such a factory (e.g. new subdir?).
>
> If there is real interest in such changes then I would try to work on
> this topic as much as my time allows. I can't make any promises for
> 3.2, but I could go step by step without breaking the application. If
> someone wants to join, you're welcome. Otherwise I've no problem to
> throw away the changes and come back later, when this issue has
> higher priority.

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.

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