🚀 go-pugleaf

In article <4937@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
>We are also looking for a window toolkit for user interfaces.  The
>primary feature we are looking for is the ability to quickly develop
>complex applications. We have used an internally developed package
>that lets you interactively lay out panels with buttons, sliders,
>etc. Unfortunately, this isn't adequate.
>
>We *Would* like an interactive, object oriented environment.
>
>We would also like to have a somewhat portable window system,
>running on common workstations. (Sun, Apollo, DEC, HP, Symbolics).

It seems to me that asking your window manager to supply all this
is a bit much. As I see it, when people say "portable" they really
mean that they do not have to re-write the code in order to get
it from one system to another. The objective of the requirement
of portability is one of cost --- the lower the better.

However, if you are writing your application such that it depends on
the tools of a particular window manager, you are effectively
reducing your portability rather dramatically. In addition, you
may be setting yourself up for "look and feel" problems from the
point of view that your product does not have a "perceivable market
difference".

One of the ways around this is to add a layer of protocol between the
application and the window manager. This is the approach taken by
both NeWs and the X Windowing System. However, certainly in the case
of X, I think that they have made an error in their way of implementing
the Toolkit libraries. 

X causes the toolkit libraries to be linked in with the application
code. This causes large applications which are only portable between
X servers -- fair enough. But, what if I only have a few X servers
and a few NeWs servers and a few dumb terminals to support? I would
have to have my application written in X, NeWs (postscript) and, say,
curses. Hardly a portable solution either.

[To be fair, X does not force you to do things this way. It's just
that this is the common way in which X is being used today]

So, why not add layers of protocols between the application,
something I will call the "agent" and the window manager?
The agent in this case, could be something as simple as a 
forms manager, or as complex as a 3D graphics package. The point
is this: Since the agents hold the knowledge of how a task is
to be presented, the application has only to be concerned about 
how the data is to be manipulated. Again, since the window manager
is concerned about how the data from the agent is to be physically
converted for the display device, the agent is only responsible
for determining how to format the data from the application in
a virtual sense.

What does this gain us?

1. Portability -- an application, speaking the correct protocol,
   would not have to be re-written to support either X or NeWs.
2. Clearer programs: Application code need only deal with the
   manipulation of data, not the presentation of data.
3. Customizability -- If you don't like a particular agent, 
   substitute your own.
4. Growth -- As new systems become available, only the agents
   would have to be re-written (only is not a small thing however)
   In addition, the protocol can be grown as the requirements
   for it become more complex.

Does it work?

Yes, these comments are basically about a small system I and
Stephen Lane developed here to test these ideas. Using the X
Windowing System, we were able to develop an application for
taking telephone messages using only 14 protocol commands
from the application (eg: Load_form("telephone.msg");)

Unfortunately, the plug was pulled on this before I could
take it as far as I wanted to (sigh)...

If anyone is interested in discussing this further (or wants to
talk about data dictionaries for forms systems such as these)
drop me a line. (Of course, if you want to hire me to continue on
this concept, call collect ;-) )

-david-