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