Thesis Presentation to Sys Dev 5/2/88 1- 3 Introductions a- Me- User Consultant for 3 and a half years now. Not a programmer by trade. E.E. major, actually. b- Andrew Toolkit developed at CMU after CMU decided to adopt X as their window system, instead of using their own. Based mainly on their original work, be1. It is a hierarchical, object-based high-level, event-driven toolkit. c- Olc code- various authors here at Athena: Win, Ken, Steve, Bill Saphir, Dan Morgan, et. al. 2- Ask how many people have used - real olc or olcr - my olc or olcr 3- My thesis a- Learn about and evaluate the Andrew Toolkit through the porting of a non-window-based application to an Andrew Toolkit window-based application. More specifically, I ported olc and olcr (the OLC client) programs to use the Andrew Toolit b- Through this porting to a window-based client, learn about what goes into the creation of a user interface 4- What I did... a- Created two client programs, olc and olcr. First three pages in handout after cover page are screen dumps of the running clients. b- Object breakdown of olcrWindow (source code follows screen dumps) - editWindow - titleBar - lpair - frame - textview (scrollbar, 'cause application mode) - text - buttons (source code follows olcrWindow source) - panelWindow - same as above, except +panel Total of 6 self created objects + lots of builtins (font, style, context, etc..); c- The clients actually work, an tie directly into olc-daemon on matisse. 5- What I learned... a- Andrew 1- interaction manager queue not in sync with X queue; have to be careful about things like the startup screen, etc.. 2- Toolkit is not strict about use of object data; all object data can be accessed without object methods or macromethods; makes for sloppy programming 3- Objects available directly from the toolkit are rather extensive, including a full-function multi-object editor object. 4- To but down on overhead, sometimes better to modify their source code to create slightly different object, rather than subclass and override. 5- lots of overhead; compiled and stripped client ~470K; xmh ~= 225K; unable to use saber and do development on RC; stuck with dbx (not that bad) 6- interaction with X kinda slow (although I here of re-write); a few bugs in exposure-type events; menus attrocious; turned off for applications 7- VERY easy to create new objects once you get the hang of it 8- Documentation not specific enough; need to look at sources and/or header files quite often when dealing with a new object of theirs i- data types (e.h. rectangle) ii- explanation of routines b- User Interface 1- Main Point- Can't really design on paper. Need to look at on screen; need interation of design 2- Difficult to control user interface in event driven system; Should I turn off all buttons when one is pressed? How to handle queries for info that user must type? How to display more than one message at a time. 3- Not worth the time to turn off useless buttons (lot of time to figure out what is useless). Better to let the user select, and tell him that it's not available because of current state. 3- Different people have different ideas; most consultants won't use my olcr because of speed; faster to type than use mouse to press buttons or move scroll bars; these clients probably a bigger win on the olc side of things (user) 4- Button (and panel) interface better than menus; visually more real-estate dependent. No hidden suprises. 6- Conclusion The Andrew Toolkit provided an very adequate means of porting the olc and olcr clients to an easy-to-use window-based interface. At times, was frustrating because of lack of complete documentation. Toolkit is rather complete, though. User interface design is a tricky matter. Tied into the tools that you are using. Need to make sacrifices at the expense of speed. 7- Try it out. Instructions on last page. 8- Questions?