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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)
From:       Zack Rusin <zack () kde ! org>
Date:       2003-06-03 14:11:18
[Download RAW message or body]

On Tuesday 03 June 2003 13:57, Andreas Gungl wrote:
> > 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 :)
>
> That still doesn't answer the question how to get there. I see my
> example as a proposal for how to separate logic and UI in a first
> step. That doesn't prevent anyone from any further steps. In the
> opposite, I believe this makes the next steps easier.

Well, these are completely two different approaches and there's 
definitely more than one correct way of achieving the goal. 
I'm not sure I understand how you see the next step. You mean implement 
the interfaces with DCOP implementation? If so then why not do it in 
the first place? By doing it your way, we'll be reimplementing a lot of 
dcop and adding a lot of useless stuff. Like for example, lets say my 
app wants to get some simple info from the core, I definitely won't 
want to implement all interfaces, I'll want to get the info from DCOP, 
but if KMail GUI is already running then I can't do that. So we'll have 
to add classes that change the interfaces independently of each other. 
So that while one for folder "kde-cvs" runns with KDE GUI 
implementation (so that KMail KDE GUI won't dissapear or stop working), 
the other one for "WorkCalendaring" runs over DCOP. That is incredibly 
complex. And which interface would take precedence? Lets say I start 
KMail as KDE GUI to view my emails and I have KOrganizer already 
running. KOrganizer already communicated with KMail over DCOP to get 
its info. So we're switching the interfaces we need to the KDE GUI to 
display the KMail window, KOrganizer asks for data as we're switching, 
KMail can't handle the request. What's more - because the interfaces 
has been switched to KDE GUI, KMail don't even see the request and will 
never respond to KOrganizer. KOrganizer code has to have a timeout on 
request after which it will send a request to KMail to switch 
interfaces to DCOP, but if KMail is busy working with the user it will 
take a while, after a while core sends a message to KOrganizer that 
it's ready. KOrganizer issues the original request one more time. In 
the same moment the person viewing the email changes folders, GUI does 
nothing because the KMail core is running over DCOP. To solve that we'd 
have register all interfaces and propagate each event to every one, so 
that they all keep working. 
Therefore your way couldn't work. Each call has to be made on a factory 
that holds all the interfaces and calls the method in each one of the 
interfaces so that every interface gets the events, instead of directly 
on the interfaces. The huge problem that of course introduces is the 
huge amount of completely useless method calls (most interfaces would 
only be interested in a certain event and not the ones others were 
asking for). To solve that you have to map requests from interfaces so 
that each interface gets only the requests it was interested in.
There's so many problems here, that with this approach a timeframe of 
KDE 4.0 seems mightely optimistic. Pretty much everything could go 
wrong. Now imagine if instead of all that you have one core that 
propagates the events through dcop. How much simpler would that be? No 
indirect calls. Error? DCOP emits error signal. New message? DCOP emits 
where and when. Who catches those signals? Who cares. Interested apps 
connect and we're done. GUI issues a dcop call to get the list of 
folders - displays them, - queries message list - displays them (this 
is already prettu much possible, look at the classes I added lately). 

> If I understand correctly then you don't want such a fine grained
> coupling of UI and logic as I did. Well, in this small piece are a
> lot of callbacks when the code for the logic remains mainly untouched
> (except for the function calls). Instead, if you want to have better
> abstraction (coarse grained coupling), then you'll also have a lot
> more work with the logic. In my example, this would mean to define
> much finer return codes (e.g. enumerations) for the methods which
> trigger any UI interaction. The return codes need to get passed some
> layers (in the call stack) upward, so that the UI "shell" can react
> appropriate. Did you think about that, resp. is this what you intend?

Well, ideally I wouldn't want to have any gui code in the core just DCOP 
calls to everything that should be GUI presented.
In the example above you mention return codes also note all the stuff I 
added above. Some of that stuff DCOP already solved and the rest dcop 
only implementation wouldn't need. So to get it right we'd have to 
reimplement a good deal of DCOP in KMail and then have to add a DCOP 
interfaces to get it working with other apps. 
So although your way might seem neat it simply would make the KMail the 
most complex app the world has ever seen and we would end up with every 
app using the dcop interface anyway, so why bother?

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]