From kmail-devel Tue Jun 03 10:52:53 2003 From: Zack Rusin Date: Tue, 03 Jun 2003 10:52:53 +0000 To: kmail-devel Subject: Re: [PATCH] UI abstraction proposal (partially only)=?iso-8859-1?q? X-MARC-Message: https://marc.info/?l=kmail-devel&m=105463757404590 ?= 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