Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!dogie.macc.wisc.edu!decwrl!ucbvax!hplabs!hplabsz!mayer
From: mayer@hplabsz.HPL.HP.COM (Niels Mayer)
Newsgroups: comp.windows.news
Subject: Re: Toolkits, toolkits, toolkits ...
Message-ID: <4585@hplabsz.HPL.HP.COM>
Date: 6 Jan 90 23:15:34 GMT
References: <7391@ficc.uu.net> <634@s5.Morgan.COM> <4572@hplabsz.HPL.HP.COM> <1132@tub.UUCP>
Reply-To: mayer@hplabs.hp.com (Niels Mayer)
Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA.
Lines: 85
Summary:
Expires:
Sender:
Followup-To:

In article <1132@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes:
>
> [code fragment for hello-world in elk deleted]
>
>Note that the initialization of the application context and display
>is somewhat lengthy (by the way, I wonder why the initialization is
>missing in the WINTERP example). 

Because WINTERP already has the application context and the display
initialized when it starts up. You also don't need to explicitly code an
event handling loop since that is also implicit in WINTERP. You see, lisp
forms sent to WINTERP's serverized lisp listener look just like another
event to WINTERP -- there is no need to switch between a lisp-listener loop
and an Xevent loop since the loops are merged. I did things this way
because I wanted WINTERP-based applications to
  1) be fully interactive -- unlike elk, there's no need to exit and
  reenter the X event loop in order to access the lisp listener. This means I
  can interpretively and interactively create, and modify an interface.
  2) allow for WINTERP-based processes to be able to send messages to
  each other through the TCP-based serverized lisp listener. THis will allow
  for better application integration as applications can talk to each other. It
  is also a necessary feature in allowing real-time communications between
  the experimental multimedia and groupware applications that we are building.

The Elk approach is more of a 1-to-1 correspondence to the Xtoolkit
intrinsics calls, and is similar to my initial proof-of-concept "alpha"
WINTERP that I hacked together out of ELI and the HP Xwidgets about a year
ago. I found my "alpha" approach to be workable, but still a bit too
verbose. Thus in the released "beta" WINTERP I opted to use XLISP's object
system as the API to the Motif widget classes. This has resulted in a much
cleaner design that allows me to eploit OOP features such as polymorphism,
inherticance and subclassing on existing Motif widget classes. Furthermore,
interactive use of the beta WINTERP is much more robust since you cannot
accidentally call, for example, the function XmGetText() on a pushbutton
widget class instance causing a core dump. In the "beta" WINTERP,
XmGetText() is called in response to the message :GET_TEXT on instances of
the XM_TEXT_WIDGET_CLASS; an "undefined method" error is signalled if you
send that message to an instance of the wrong class.  The assumptions and
coding style must change drasticaly when coding in an object oriented model
in compiled C (Xtoolkit/Motif) versus an interpreted object oriented lisp
(WINTERP/XLISP)....

So anyways, if I send the following form to WINTERP's serverized lisp listener

  (let* ((top_w (send TOP_LEVEL_SHELL_WIDGET_CLASS :new
                :XMN_TITLE "hello world"       ;note auto string->XmString conv
                :XMN_ICON_NAME "hello world")) ;ditto
         (but_w (send XM_PUSH_BUTTON_WIDGET_CLASS :new :managed top_w
                :XMN_FONT_LIST "8x16")))        ;note auto string->FontList cv
   (send but_w :add_callback :XMN_ARM_CALLBACK '()
      '((system "echo \"Hello World Run!\" | mailx mayer@hplabs.hp.com")
        (format t "hello world\n")))
   (send top_w :realize))

I can expect a "hello world" window to pop up as soon as WINTERP has
finished evaluating the form. The receipt of the form is seen as a "lisp
event" by WINTERP's XtMainLoop() and is sent off to the evaluator which in
turn ends up calling the various Motif/Xt functions to create widgets.
Upon return to the XtMainLoop, the windows are created, mapping and expose
events are processed, and the windows appear on the screen...

I see application contexts, display initializations, loading widgets,
XtMainLoops and such as too much low-level noise that the WINTERP
programmer really shouldn't have to deal with -- they should be transparent.

One feature currently supported in Elk and not supported in WINTERP is the
ability to dynamically load C object code. Although I wanted this feature
in WINTERP, I explicitly decided against it due to the fact that (1)
dynamic loaders are inherently unportable and my primary goal for the first
public release of WINTERP were that it be easily portable (*); (2) I wrote
"beta" WINTERP on an extremely tight schedule; (3) I didn't want to
worry about dynamic loading because I had my hands full trying to
understand Motif, the Xtoolkit, and the internals of XLISP. When I
add dynamic loading to WINTERP, I hope to make it a dynamic auto-loader.

PS: (*) -- I've received reports that WINTERP currently runs on the
following machines: HP9000s3xx (68030), HP9000s8xx (HP PA-RISC), HP-Apollo
DN-*, Sun3, Sun4, MIPS, DEC 3100.

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *