cooper@netcom.UUCP (Ken Cooper) (11/29/89)
I've received several requests for information about the interface builder we're working on, so I thought I'd post a little information to satisfy curiosity. Some portions of the design are not yet finalized, so we invite comments and requests. The interface builder is a part of a set of tools we're working on to help in programming GUI 'applications' in Smalltalk V/286 and Smalltalk V/Mac. We may end up porting this to Smalltalk V as well, but we have yet to see what the issues are there. The basis of the interface builder is a set of reusable classes, or widgets, which implement the functionality of standard GUI mechanisms. Each widget manages its interaction with the user, and sends relevant messages to its registered owner only when something interesting occurs. For example, a button widget would handle all button presses, giving the user feedback that the button was pressed, sending a message to its owner only when the mouse was released within the button. If you're used to MVC, this model brings the View and Controller into one package, avoiding much of the spaghetti so typical of Panes and Dispatchers. Each of these widgets is a class, and we've designed them to be subclassable for different looks and feels. With this, one can easily change an application's appearance to look like the Mac, MS Windows, Next, or a look and feel of one's own design. We're implementing all the common user interface components, including windows, dialog boxes, list boxes, popup and pulldown menus, scrollbars, buttons, checkboxes, radio buttons, and text edit boxes. In addition, we're providing less common components, like hierarchical menus, icon palettes, and numeric editors. [The emacs-like window I described before was the text edit box. This is *not* an emacs goody; it won't implement a lisp interpreter, and thus you won't be able to port code from emacs to it. I describe it as emacs-like because smalltalk code can be bound to keys, and because the standard motion keys can match those of emacs. (Since all widgets have programmer definable event bindings, binding keystrokes to commands in an editor rides along for free). It's written with smalltalk in mind, so commands like "select current line and show it", or "extend selection to end of paragraph" will be available.] The interface builder itself allows one to 'paint' applications made up of these components. If you're familiar with NextStep or Prototyper, this is very similar: one creates an interface by dragging its component widgets off a palette, editing each of them individually, and then saving the unit as an instance. Unlike these systems, the interface and code can be changed and executed interactively; one can watch one's objects in action as the interface is built. To deal with handling all the resulting instances, we've created a mechanism for saving and retrieving instances by name or keywords, with a facility for saving unused instances to disk to avoid bulging images. This will have a front end "finder" similar to the Macintosh's SFGetFile dialog box, with keywords as the mechanism for limiting a search rather than directories. Further, we've defined a class called a module, which is a collection of those classes and instances that make up a unit of functionality (e.g. a "program", or a library of classes). A module can use this same mechanism for storage and retrieval to minimize image size, and further, a module can be exported into a disk file that another programmer with these tools can then import. This provides a mechanism for exchanging code far superior to fileIn and fileOut, since GUI applications often require instances such as fonts, bitmaps, and icons in order to run (and we all know how much support there is for instance transfer). We also provide a simple mechanism for isolating platform specific code (e.g. directory pathnames on V/286 don't look like those on V/Mac), so one can write a module that is *truly* portable across platforms. All of these tools have GUI and programmatic interfaces. The graphical interfaces for these tools are consistent with each other, and fit together into a consistent programming environment. That's about it. Any comments? Ken ============================================================================= Ken Cooper USENET: cooper@netcom.uucp Acumen Software Compu$erve: 71571,407 =============================================================================
puklich@sparky.UUCP (Blayne Puklich) (11/30/89)
In article <4692@netcom.UUCP> cooper@netcom.UUCP (Ken Cooper) writes: >I've received several requests for information about the interface builder >we're working on, so I thought I'd post a little information to satisfy >curiosity. Some portions of the design are not yet finalized, so we invite >comments and requests. > >The interface builder is a part of a set of tools we're working on to help in >programming GUI 'applications' in Smalltalk V/286 and Smalltalk V/Mac. We may [ stuff deleted ] >released within the button. If you're used to MVC, this model brings the View >and Controller into one package, avoiding much of the spaghetti so typical of >Panes and Dispatchers. [ stuff deleted ] >these components. If you're familiar with NextStep or Prototyper, this is >very similar: one creates an interface by dragging its component widgets off a >palette, editing each of them individually, and then saving the unit as an >instance. Unlike these systems, the interface and code can be changed and >executed interactively; one can watch one's objects in action as the >interface is built. > >To deal with handling all the resulting instances, we've created a mechanism >for saving and retrieving instances by name or keywords, with a facility for >saving unused instances to disk to avoid bulging images. This will have a >front end "finder" similar to the Macintosh's SFGetFile dialog box, with >keywords as the mechanism for limiting a search rather than directories. This sounds like a very good idea; I'm suprised I haven't heard of it yet. I'm relatively new to Smalltalk (Smalltalk V/Mac), so that may be the reason. That means I know exactly what is meant by the "spaghetti typical to panes and dispatchers." That's the trickiest part about learning Smalltalk, but even though it is important to know. What is described will no doubt be a welcome alternative to Prototyper, which I'm somewhat familiar with. Prototyper generates GUI code in Pascal or C for the Macintosh for those of you who don't know what it is. Being able to do this in the Smalltalk way of doing things will definitely make the job of creating GUIs even easier, since in addition to the GUI one could also create the application-specific code at the same time, interactively. I can also see this as a better tool for prototyping applications than what we currently have available for the Macintosh. The current method is to basically create the whole application. One can use Prototyper to create the GUI part, but that only provides a look and feel for the application, and from my experiences with Prototyper, the GUI code it generates is much less than optimal. I myself would never use what it generates in a finished application. The interface for retrieving pieces of the image will also be a welcome addition to fileIn and fileOut. This should make finding chunks of code much easier if it allows keyword searching. I can't think of any suggestions offhand, since what is described sounds good already. I appreciate the posting about the design of this new product. I know that I'll be looking for more information about this in the future. If it does what is described in this posting, I know I'll be the first to want the product (well, maybe not quite the first). ||+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|| || Blayne Puklich nopuklic@Plains.NoDak.EDU "I think I'm going || || NDSU Student ACM Vice-Chair bald..." || || North Dakota State University, Fargo, ND -- Rush, from Caress || || (701) 237-4408 of Steel, 1975 || || Damn it's cold up here in the Great White North! || || Alternate address: puklich@Sparky.NoDak.EDU (Until Dec 7th). || ||-------------------------------------------------------------------------||
brucec@demiurge.WV.TEK.COM (Bruce Cohen;685-2439;61-028) (12/06/89)
In article <4692@netcom.UUCP> cooper@netcom.UUCP (Ken Cooper) writes: > ... >The basis of the interface builder is a set of reusable classes, or widgets, >which implement the functionality of standard GUI mechanisms. Each widget >manages its interaction with the user, and sends relevant messages to its >registered owner only when something interesting occurs. For example, a >button widget would handle all button presses, giving the user feedback that >the button was pressed, sending a message to its owner only when the mouse was >released within the button. If you're used to MVC, this model brings the View >and Controller into one package, avoiding much of the spaghetti so typical of >Panes and Dispatchers. This design sounds similar to the various X toolkits, especially InterViews. Your use of the word "widget" makes me think the resemblance is more than coincidence. Recently, Mark Linton, who is the driving force behind InterViews, began organizing a working group to develop a C++ class lattice which provides an X toolkit. I'd say much of what you have done in Smalltalk is applicable to that effort; I'd like to hear more detail, and I think Mark ought to know about this. I'm sending him a copy of you posting, in case he hasn't seen it. Bruce Cohen brucec@orca.wv.tek.com Interactive Technologies Division, Tektronix, Inc. M/S 60-850, P.O. Box 1000, Wilsonville, OR 97070