[Dev] User interface

[Eric Gerlach]

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

(Crossposting to design, as this particular issue carries into the
design aspects too)

At 10:50 AM 28/10/02 -0800, you wrote:
 >-> At 05:00 PM 26/10/02 -0700, Nimret Sandhu wrote:
 >-> >ok .. i think this thread has gone on long enuf. pls refer to my
 >-> >earlier
 >-> >proposal about implementing a soap based data model and different
 >-> >views/controllers in different languages ( as long as they
 >support
 >-> >soap).
 >-> >
 >-> >that should make all camps happy +)
 >->
 >-> Okay, I haven't posted to this dev list yet (I've been on design
 >for a
 >-> few days now).  I have to throw my voice behind Nimret here.  With
 >a
 >-> proper Model/Controller/View design, the user interface should be
 >-> trivial to implement in XUL, wxWindows, or even native widgets.
 >SOAP
 >-> or no, this is the way to go, IMHO.
 >
 >"Trivial" usually means "I don't have to think about writing it" ;).

Or it means that I forgot to add the word "comparatively" before
"trivial".  That's what I get for writing emails at 3AM.  Mea culpa.
:)

 >I'm a big fan of the RAD approach, so I'm more interested in finding
 >out
 >what the various ideas are then arguing about which widget set to
 >use.
 >As several people have pointed out, it's not particularly difficult
 >to
 >swap out widget sets or UIs once you have the basic idea and the
 >internal
 >machinery worked out.

That depends on how it's designed.  Widget sets don't have all the
same features.  It's unfortunately not a matter of replacing calls
with one with calls to the other.  It's also fairly easy to, if you
use the MFC widget set, wire your UI directly to your backend.  This
may make it very hard to swap out your widgets in the end.

However, choosing the proper design, above and beyond just a newtork
and storage layer API (to half reply to Kevin Altis) can make this a
lot easier.  This article:
http://www.cs.indiana.edu/~cbaray/projects/mvc.html seems to be a very
good introduction to MVC (I only skimmed it to make sure it had the
essential elements) and what would a design pattern be without an
entry in the Portland Pattern Repository:
http://c2.com/cgi-bin/wiki?ModelViewController

If you read those, especially the first one, you can see how a good
Model/View/Controller architecture would work in being able to design
multiple user interfaces quickly.  This is more than just swapping out
widget sets.  This way you can take full advantage of any RAD design
tool, for instance, because you only have to wire it to a known,
specific interface.

Many applications like Chandler are starting to move towards this
model because it greatly increases portablity.  GnuCash, for instance
explicitly states on their website
(http://www.linas.org/linux/gnucash/projects.html#arch) that not
having used MVC is a problem, and is a direction they have to move if
they want to port to other widget sets like KDE or Windows.  This
sounds like exactly what Chandler should be doing from day one.

Cheers,

Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQE9vZmynuiuBLkZNokRAh1uAKDsxrQKN8Ni+0893hmnFW2UjmfkCQCg2VM1
vDtb/lUA4BUUax+KQ2KEArc=
=bTSi
-----END PGP SIGNATURE-----