[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:       Zack Rusin <zack () kde ! org>
Date:       2003-06-03 10:52:53
[Download RAW message or body]

?=
Date: Tue, 3 Jun 2003 12:52:00 +0200
User-Agent: KMail/1.5.9
References: <200306030001.35127@gungl-dd.de> <200306030036.15600.zack@kde.org> \
                <200306030945.50912.schumacher@kde.org>
In-Reply-To: <200306030945.50912.schumacher@kde.org>
X-KMail-Link-Message: 142474854
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200306031252.01234.zack@kde.org>
Status: RO
X-Status: Q
X-KMail-EncryptionState:  
X-KMail-SignatureState:  
X-KMail-MDN-Sent:  

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. There are four I can think of currently with most 
probably third-party coming (by third-party I mean the ones not in KDE 
CVS ). IMHO it's already too many to host all of them in the tree. 
Interaction of other apps with the core would often be only limited to 
very simple things, e.g. getting calendaring info, number of emails, 
new emails, some attachment... Implementing whole gui to get one set of 
info is pretty silly. What's more, the interfaces don't bring us closer 
to interact with other apps in a way we would like. For example: let's 
say I don't have a running KDE GUI for KMail but only Kontact summary 
page which uses the core and some other part (from quite a few) which 
needs some kind of a resource from the KMail core - we are stuck. 
Of course, I'm bound to hear "to get that small amount of info all you 
need is reimplement one interface" and here's a the problem - every 
single interfaces would have to have a factory with a run-time creation 
and probably caching of previous interfaces. The factories would have 
to a lot more advanced managing then just creation - hiding, showing, 
moving. Just imagine how hard would it be to follow the code then.
So again, the interfaces do not bring us any further to a true 
abstraction of the core from the gui. Andreas patch looks nice, but it 
doges the most crucial aspect of that idea and that's managing of those 
interfaces.
The problem abstraction of the core from the gui would try to solve is 
an ease of access for other apps to the data KMail is storing and, at 
least in my opinion, not inability to write GTK+ frontend for KMail. 
Andreas interfaces do not solve the first, but the latter. 
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 :)

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