sjs@spectral.ctt.bellcore.com (Stan Switzer) (12/20/89)
Against my better judgement I jump into the fray ... In article <7363@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > ... of the lack of a standard programmer interface. The analogy I used was > with the UNIX system calls and the C stdio library... There is simply no use comparing something like stdio with a a graphical user interface. There are two "tricks" behind stdio: 1) let's imagine that files are just bytestreams and 2) the printf vararg hack. These are nice tricks to be sure, but are something of an overabstraction. How many times have you seen the query, "how do you read a single character from the terminal" in comp.lang.c? Is this REALLY such a crazy question? Hmmm. Let's see if we can find a simple abstraction for windowing... > nread = read(fd, buf, nbytes); No wait. That's too simple. > Similarly, let's look at a hypothetical window call: > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); Looking kinda like a widget call isn't it? I mean after we answer a few questions like where the window is to be placed relative to other windows, what kind of behaviors the window is to have, etc. > > C++ and Lisp would be a good choice for an object oriented > > windowing system. [That's Bruce talking.] Yes. Objective-C or PostScript with the object-oriented extensions and a powerful toolkit are pretty good too. Looked at tNt yet? > I'd rather use the best language for the job the program is intended to > do. Not the best language for the user interface. That's just putting the > cart before the horse. What if you're working in Prolog? Or APL? Or you're > working for the DoD in ADA? Or adding a GUI to MicroEmacs? Good points all. That is why I like to download all of my UI code into the server and interface to it using stubs crafted to the specific functionality of the interface. Looked at NeWS's "cps" yet? > > I certainly would not want to wait three years for a standards > > committee to define the stdio-windows library package. > > But you're willing to wait three years for a standards committee to > define the user interface? Why? I've got a job to do today. I have the technology to do it. I don't expect that it will last forever or that it won't take additional work to keep up with the technology rat-race. I expect someday that people will notice who's getting the job done and try to standardize based on the successful tools rather than trying to define success through the standards process. > Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's > way too low level for something like this. Mon ami, have you REALLY looked at the X widget interface? Nobody is suggesting you write an interface using Xlib. But back to the search for a simplifying windowing metaphor... > Besides, Termcap and terminfo are both far below the level I'm talking > about here. Curses is a closer metaphor. > ... > "I want a window big enough to hold the following > objects: a text pane containing this text, and a > selector for YES and NO. Tell me when someone selects > YES or NO, and don't bug me otherwise", Oh! Curses. There's an idea: a window is a screen region with text and maybe a few menu items at the top. > "Draw a rectangle here, now put these characters in > this font here, and then draw these rectangles... > (lots deleted) now tell me when anyone clicks in my > window. Oh, OK, erase this rectangle and redraw it > here, and blit this rectangle up by the size of this > font, put these characters here, and tell me what > you want me to do next..." Wait a minute here, now it's getting complicated. What's that? You want to implement a drawing tool? Sorry, we only blit rectangles. Circles? Polygons? Clipping? Filling, images, animation, sliders, scrollbars, menus? Oh stop! It's getting SO complicated! There is a minimum complexity to a windowing interface unless you accept that some of the inherent capabilities of the device will be unaccessable. Yes, simplifying models are quite useful, but they are not always appropriate to the task at hand. This is why an object-oriented interfacing approach is a Good Thing. You can define object classes which capture certain interfacing abstractions and present a simple interface to the user for that particular interfacing abstraction. But who knows what gadgets might be useful? I wrote and debugged a "graph" gadget for NeWS which allows you to grab points on the graph and adjust them visually in a few hours one evening after putting the baby to bed. Why should it be hard? In NeWS it isn't. Unfortunately, as a result my interface will forever be more complex than it was before. Every time I write a program I'll have to ask myself: "Self," I ask, "do you want to use a graph item, a slider, a scrollbar, or one of these other tools?" Now look what I've gone and done! But to pick some particular simplifying abstraction and to base an API on that abstraction is going to doom you to forever explaining to the poor user who asks "how do I let a user drag the control point of a spline with real-time visual feedback" that you had not anticipated his particular need and if he weren't so stupid he'd know that you can't read a single character from the terminal without doing non-portable hacks. As Yogi Berra said, "It's deja-vu all over again." Stan Switzer sjs@bellcore.com
peter@ficc.uu.net (Peter da Silva) (12/22/89)
In article <18637@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: > There is simply no use comparing something like stdio with a a > graphical user interface. There are two "tricks" behind stdio: 1) > let's imagine that files are just bytestreams and 2) the printf vararg > hack. So what sort of "tricks" do we need to solve the window programming problem? > These are nice tricks to be sure, but are something of an > overabstraction. How many times have you seen the query, "how do you > read a single character from the terminal" in comp.lang.c? And I'd expect that in a real high-level windowing environment you'll get the same sort of question. And the same sort of answer: "You don't do that". In the case of C, you use curses. Stdio is the wrong tool for hacking with the screen. It's too high a level of abstraction. In the case of windowing, you design the user interface at a higher level of abstraction. But don't force the whole program into that mould. > Hmmm. Let's see if we can find a simple abstraction for windowing... I don't know either. But I think it's a much more important problem than deciding what windows should look like. The examples I gave were deliberately simple... > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); > Looking kinda like a widget call isn't it? Maybe. But you don't want to design your program around the UI, like you have to with widgets. > Good points all. That is why I like to download all of my UI code > into the server and interface to it using stubs crafted to the > specific functionality of the interface. Looked at NeWS's "cps" yet? Yeh, it's a nice metaphor. I'm not sure it's the best one for today's systems, though. It's got quite a bit of overhead, and you're not going to be able to cram much of a postscript interpreter into 640K if you need your apps in there as well... > > Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's > > way too low level for something like this. > Mon ami, have you REALLY looked at the X widget interface? Nobody is > suggesting you write an interface using Xlib. The interface is not so bad. You still have to design the whole program around it, though, or you'll end up pissing off users who want to work instead of wait. That level of abstraction belongs in the server. Not the program. No matter how it's hidden. Here we have my "desirable" example: > > "I want a window big enough to hold the following > > objects: a text pane containing this text, and a > > selector for YES and NO. Tell me when someone selects > > YES or NO, and don't bug me otherwise", This stuff here was my "undesirable" example. Of course this is what systems like X give you. They hide it, but your program still has to be able to get back to the user or none of this will happen: > > "Draw a rectangle here, now put these characters in > > this font here, and then draw these rectangles... > > (lots deleted) now tell me when anyone clicks in my > > window. Oh, OK, erase this rectangle and redraw it > > here, and blit this rectangle up by the size of this > > font, put these characters here, and tell me what > > you want me to do next..." > There is a minimum complexity to a windowing interface unless you > accept that some of the inherent capabilities of the device will be > unaccessable. I accept that some inherent capabilities of the device will be unacessible at this level of abstraction. Similarly, most of the hardware UNIX runs on is quite capable of, oh, lightweight processes, asynchronous I/O, real time response, and so on. But people are wiling to give all this up so they can use a higher-level metaphor. Your argument here is beginning to sound like the ones advanced by PCware programmers who NEED to get to the raw hardware. Remember, form liberates. > Yes, simplifying models are quite useful, but they are > not always appropriate to the task at hand. This is why an > object-oriented interfacing approach is a Good Thing. But it makes your programs huge. The program itself should have as little of the user interface as possible as an integral part of itself. If you need to go to a lower level, do it. But first make the easy things easy. "Hello World" in a windowing system shouldn't be more than 10 lines of code. Oh, and yes. I would LOVE to play around with Display Postscript. But it's never going to show up in today's PCs, and the way things are going it's gonna be a long time before it'll show up in any. Standards aren't just for the elite. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
barnett@crdgw1.crd.ge.com (Bruce Barnett) (12/23/89)
I added comp.windows.misc to the discussion. In article <7391@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >In article <18637@bellcore.bellcore.com> sjs@bellcore.com (Stan Switzer) writes: >> Yes, simplifying models are quite useful, but they are >> not always appropriate to the task at hand. This is why an >> object-oriented interfacing approach is a Good Thing. >But it makes your programs huge. The program itself should have as >little of the user interface as possible as an integral part of itself. I think there is a major difference of perspective here. Some people want environments that let them *build tools* as fast as possible If you can build the basic tool in a few hours, who cares if it's portable? Others want the *tools* to be as fast (and small) as possible. The target market is different, i.e. PC's vs. Workstations. I don't thing the two problems can have have one solution in the near term. Unless you make a PC like a workstation, with all of the extra costs, etc. Another solution Peter is looking for is something more portable than X. >If you need to go to a lower level, do it. But first make the easy things >easy. "Hello World" in a windowing system shouldn't be more than 10 >lines of code. Window systems have evolved so much in the last 10 years. However it is still changing. SunWindows failed the Hello World test. SunView is a better job. Xlib also failed, but the X intrinsics fixes that. (See David Rosenthal's paper in core.src/doc/HelloWorld). Window systems evolve. Tool kits get better. >Oh, and yes. I would LOVE to play around with Display Postscript. But it's >never going to show up in today's PCs, and the way things are going it's >gonna be a long time before it'll show up in any. >Standards aren't just for the elite. The problem the PC's users are facing is evolution. Remember when some "expert" said that 64K was enough for any application? The future PC will be a 486 with 4 Megs of memory for under $1000. You'll see X and NeWS on PC's once some vendor ships Unix V.4. I know there is no standard User Interface or library. But there is a lot more that is not standard. What about the imaging model? Bitmaps are not going to be the model used in the future. Already everyone is talking about outline/rescalable fonts. The PostScript model is even more powerful, and allows for hardware accelerators. Think about the job a bitmap programmer has to do to stretch and rotate a diagram. This is trivial in PostScript. How about the basic model of the user interface? People don't want stand-alone applications. They want to drag a file and drop it onto a tool. Or select several files or objects, and then start the application with the input being the items selected. They also want to cut some information from one tool, and paste in into another tool - like a column of numbers into a chart drawing tool, which in turn is inserted into a document. If you change the data in the table, the chart will be updated and so with the document. These sort of issues make a large difference in the style of programming used to develop the application. What is 10 lines using one model might be 10 pages in another. Selecting a standard now won't solve those problems. Sure, you'll have a product next year, but the year after that you will have to redesign it anyway. I'm sorry for ranting on and on. My old company was very short sighted. They might still be around if they decided to take a few short term risks that had long term benefits. Perhaps that is why I believe so much in new technology. Happy Holidays, everyone. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
hugh@hoptoad.uucp (Hugh Daniel) (12/25/89)
I would like to point out that there is a version of NeWS for 640k MS-DOS
IBM-PC class machines, here is a note I had laying around about it.
||ugh Daniel
hugh@toad.com Grasshopper Group, +1 415/668-5998
hugh@xanadu.com 1996 Hayes St. San Francisco CA94117
--------------------------------------------------------------------
NewScript, a NeWS interaction clone for MS/DOS by TAG inc.
Technology Application Group inc.
10621 Bloomfield St., Suite 33
Los Alamitos, CA 90720 USA
213 430-9792
NewScript(tm) is a compact, high performance emulation of the NeWS,
for 286 and 386 machines running DOS or OS/2(tm). NewScript offers
an interactive user interface design environment for the development
and prototyping of NeWS compatible graphical interfaces.
Perfect for PostScript and NeWS class teaching! NewScript is based on the
PostScript language as defined by Adobe Systems Inc. with Events,
canvases, monitors, processes, and object PostScript extensions specified
by NeWS. NewScript emulates a subset of NeWS and PostScript. CPS,
network communications, and stroke fonts are not supported in version 1.0.peter@ficc.uu.net (Peter da Silva) (12/27/89)
In article <9405@hoptoad.uucp> hugh@hoptoad.UUCP (Hugh Daniel) writes: > I would like to point out that there is a version of NeWS for 640k MS-DOS > IBM-PC class machines, here is a note I had laying around about it. From the description you included, it sounds like a teaching tool. Can you write a program in C on the Sun, move it to the PC, compile it, and run it under NewsScript? Or is it a Postscript system only? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
hugh@hoptoad.uucp (Hugh Daniel) (12/29/89)
>From the description you included, it sounds like a teaching tool. Can you >write a program in C on the Sun, move it to the PC, compile it, and run it >under NewsScript? Or is it a Postscript system only? Right now it is a PostScript (NeWS really) only system with some serial I/O(I think). TAG ueses is to do user interfaces to run control equpment (milling machines etc.) ||ugh Daniel hugh@toad.com Grasshopper Group, +1 415/668-5998 hugh@xanadu.com 210 Clayton St. San Francisco CA94117
jordan@Morgan.COM (Jordan Hayes) (01/03/90)
Peter da Silva <peter@ficc.uu.net> writes: But first make the easy things easy. "Hello World" in a windowing system shouldn't be more than 10 lines of code. Sigh. When will people learn to code before blabing on USENET? This is in Motif ... == not 10 lines but the meat is only 8 lines ... === main(argc, argv) int argc; char **argv; { Arg sArgs[3]; Display *display; Widget topW; XmString str; XtAppContext app; XtToolkitInitialize(); display = XtOpenDisplay(app = XtCreateApplicationContext(), (String)NULL, "Joe", "Hodedo", NULL, 0, &argc, argv); topW = XtAppCreateShell(NULL, NULL, applicationShellWidgetClass, display, NULL, 0); str = XmStringCreateLtoR("Hello World", XmSTRING_DEFAULT_CHARSET); XtSetArg(sArgs[0], XmNlabelString, (XtArgVal)str); XtManageChild(XmCreateLabel(topW, "label", sArgs, 1)); XtRealizeWidget(topW); XtAppMainLoop(app); } /jordan
jesup@cbmvax.commodore.com (Randell Jesup) (01/03/90)
In article <4355@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >The problem the PC's users are facing is evolution. Remember when some >"expert" said that 64K was enough for any application? The future PC >will be a 486 with 4 Megs of memory for under $1000. You'll see X and NeWS >on PC's once some vendor ships Unix V.4. Or maybe an '030 or '040 with 4 Meg... BTW, we (Commodore) already have announced (and demoed in NYC) Sys V.4 for the Amiga 2500 (admittedly not $1000 yet). X is also available for the Amiga and shipping (doesn't require Unix, or even an '020/'030). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (01/04/90)
In article <634@s5.Morgan.COM> jordan@Morgan.COM (Jordan Hayes) writes: > But first make the easy things easy. "Hello World" in a > windowing system shouldn't be more than 10 lines of code. >Sigh. When will people learn to code before blabing on USENET? >This is in Motif ... > >== not 10 lines but the meat is only 8 lines ... === > Well, you can easily do a "hello world" in WINTERP in less than 10 lines. WINTERP is an interpretive environment for rapid prototyping applications using the Motif UI toolkit. It is based on the mini-lisp interpreter XLISP and makes extensive use of XLISP's object system as the application programmers interface to Motif. It is available for free on the X11r4 tape or via anonymous ftp from expo.lcs.mit.edu:contrib/winterp.tar.Z. You might think of WINTERP as client-side NeWS without the imaging model (??). Or you might think of WINTERP as a gnuemacs-like prototyping environment that uses widgets as it's primary UI interactor rather than textual buffers.... ---------- The following is an excerpt from a previous posting to comp.windows.x containing a 9 line hello world: ... WINTERP makes extensive use of XLISP's Smalltalk-like extensions for object oriented programming: All the Motif widget classes are actually implemented as XLISP classes, Xtoolkit functions become methods on the widget base class. Motif "Convenience Functions" become methods on particular classes. Because Motif Classes look like normal XLISP classes inside WINTERP, you may extend the functionality of existing widget classes in Lisp via subclassing, or by adding new methods to existing widget classes. Example -- evaluating the following form in WINTERP results in the display of a "hello world" window which sends me mail and prints "hello world" on stdout each time the button is clicked: (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)) Once the "hello world" window is displayed, you can interactively modify the look and the functionality of the interface. For example, lets say I want to change the color of a widget on the display -- I give WINTERP the following command: (send (get_moused_widget) :set_values :XMN_FOREGROUND "white" :XMN_BACKGROUND "blue") and then click on the pushbutton widget created above. One can use the same technique to interactively change a widget's callbacks, eventhandlers, etc. For further information, take a look at the WINTERP source distribution's "examples" directory. Interesting mini-applications include a bitmap browser, a MH-based mail browser, and a grep-based file search browser. Other examples show you how to contruct menus, radio-boxes, etc. ... ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
net@tub.UUCP (Oliver Laumann) (01/04/90)
In article <4572@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > In article <634@s5.Morgan.COM> jordan@Morgan.COM (Jordan Hayes) writes: > > But first make the easy things easy. "Hello World" in a > > windowing system shouldn't be more than 10 lines of code. > >Sigh. When will people learn to code before blabing on USENET? > >This is in Motif ... > > Well, you can easily do a "hello world" in WINTERP in less than 10 lines. [Example program and WINTERP blurb deleted] This is how you would write it in `Elk' Scheme: ;;; -*-Scheme-*- (require 'xwidgets) (load-widgets shell label) (let* ((con (create-context)) (dpy (initialize-display con 'kraftbus:0 'hello 'demo)) (top (create-shell 'hello 'demo (find-class 'application-shell) dpy)) (w (create-managed-widget (find-class 'label) top 'label "Hello world"))) (realize-widget top) (context-main-loop con)) 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). `kraftbus' is the name of the workstation on my desk (yes, the name is weird, if you want me to tell you the anecdote behind it, drop me a letter), so `kraftbus:0' obviously is the display name. One can use #f instead to indicate that the value of the $DISPLAY environment variable is to be used. The `require' form loads the Elk interface to the Xlib, Xt, and the Athena widget set (one would write "(require 'motif)" to load the interface to the OSF/Motif widgets). `find-class' creates a Scheme object of type `widget class' (widget classes are, like widgets and application contexts, first class objects). If the example had used the Athena command widget, one could have added a callback like this: (add-callback w 'callback (lambda (widget) ; do something )) or, using set-values!, (set-values! w 'callback (list (lambda (widget) ...))) -- Oliver Laumann net@TUB.BITNET net@tub.UUCP
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (01/07/90)
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. *
net@tub.UUCP (Oliver Laumann) (01/08/90)
In article <4585@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > > 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. Since we are using Elk-Scheme as the extension language for a `real' software package (an ODA-based document processing system), we do need to be able to access the full power of the X toolkit, for instance, our application must be able to open more than one display (for shared editing of a document). Of course, funtionality like opening a display and creating an application context (the things that you called `noise') can be hidden in an additional `layer' if desired; building abstractions is one of the things that can be done in Scheme quite elegantly (which is one reason why we think that Scheme is better suited as a general extension language than, for instance, Xlisp). [Since this has no longer anything to do with NeWS, I have directed follow-ups to comp.windows.x] Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP