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

List:       kmail-devel
Subject:    Re: [PATCH] UI abstraction proposal (partially only)
From:       Andreas Gungl <a.gungl () gmx ! de>
Date:       2003-06-03 20:43:33
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 03 June 2003 16:11, Zack Rusin wrote:
> On Tuesday 03 June 2003 13:57, Andreas Gungl wrote:
> > 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.
> [...]
> 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).

Don't get me wrong, I still understand my patch as some kind of initial 
ignition. It's okay, when the discussion in this thread leads to a clearer 
picture of what is planed for KMail. IMO it's important to define the way 
to go to be able to make other steps conformant to the far goal.

> > 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?

Well, I thought only about having an interface of choice when I start KMail 
- - working from remote using the text UI, working locally using the GUI. I 
didn't think about many concurrent applications using the core 
simultaneously.

So the conclusion out of the thread is up to now:
- - KMail should have a core which is able to manage more than one UI client.
An UI client could be another programm like KOrganizer too.
- - Currently we see DCOP as the way to go for the interaction between core 
and UI client.
- - Usually, that kind of communication uses coarse grained interfaces.
- - As I understood, the core is working singular (no parallel threads or so). 
Calls will be needed to be queued somehow. (Did I get this right?)

The requirements above make my example approach nearly obsolet. However, I 
still think, there are some more issues to be discussed. The architecture 
you prefer has some more challenges. What about session states (stateless, 
I guess), what about transactions (e.g. deleting 10 messages in one folder; 
no problem when the core is not working parallel), what about response 
times towards the UI (might be a problem when the core is not working 
parallel)?
In the office, there I'm working on a large J2EE project. There we're facing 
many of the problems which seem to be natural for architectures like 
mentioned above. We better don't underestimate them.

I'm also interested in comments from Ingo and Don, as well as from Marc, who 
is a talented pattern user ;-) and has good architectural ideas. Perhaps 
the Kroupware guys have some ideas too. I would not like to have a dialog 
only between you, Zack, and me, when the topic is so important - except 
when it will be decided to get delayed, then it was only a nice thread in 
the list archive. ;-)

Regards,
Andreas
- -- 
    ~
  ' v '
 //   \\
/(     )\  Powered by Penguin.
  ^ ' ^

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE+3Qh9VhjiFd4beU8RApx2AJ9XKvX6CXkdsEWDLzaLetYykQMDMQCgqL9U
mS4IANrfcqiAifZHEOdvOlI=
=YtuW
-----END PGP SIGNATURE-----

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