Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!sun-barr!rutgers!bellcore!spectral!sjs From: sjs@spectral.ctt.bellcore.com (Stan Switzer) Newsgroups: comp.windows.news Subject: Toolkits, toolkits, toolkits ... Message-ID: <18637@bellcore.bellcore.com> Date: 20 Dec 89 14:56:54 GMT References: <8912162135.AA03025@iris.rand.org> <4290@crdgw1.crd.ge.com> <7352@ficc.uu.net> <4301@crdgw1.crd.ge.com> <7363@ficc.uu.net> Sender: news@bellcore.bellcore.com Reply-To: sjs@bellcore.com (Stan Switzer) Organization: Bellcore Lines: 118 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