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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)=?iso-8859-1?q?
From:       Don Sanders <sanders () kde ! org>
Date:       2003-06-04 8:59:21
[Download RAW message or body]

On Tuesday 03 June 2003 20:52, Zack Rusin wrote:
> 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.
>
> > > 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.
> >
> > Really? I don't think it gains us much being able to run twenty
> > KMail GUIs for the same core. I would be much more interested in
> > a KMail core which can be used by other applications to handle
> > mails without the need to run the KMail GUI. To abstract
> > interaction of the core and the GUI, like the patch from Andreas
> > intended to do, seems just the right way to achieve that.
>
> Like I said above, unless you'll have another plugin mechanism
> every app which would intend to use the core would have put its
> implementation in KMail source tree. 

I agree this is a valid criticism of the patch, but I think it can be 
solved be defining a universal KMail UiCallback DCOP interface, 
requiring all Ui processes to register an object of this type with 
KMail (the server process) and have KMail (the server process) use 
this UiCallback instead of attempting to directly interact with the 
user.

Initially the UiCallback probably only needs a few methods for showing 
errors, warnings and progress info.

Don.

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