carlson@lance.tis.llnl.gov (John Carlson) (12/02/89)
Is there a good paper which differentiates "User Interface Development Environment", "User Interface Builder", "User Interface Prototyper", and "User Interface Management System"? Now that we are all good toolkit programmers, toolkit programming is being replaced by user interface builders. How can we easily take our existing applications and bring them into the user interface builder world? I am aware of past work done in this area, but I'm not up to date on current toolkits. Is the brute force solution the best? John "Time is Money" Carlson
klee@chico.pa.dec.com (Ken Lee) (12/02/89)
In article <639@ncis.tis.llnl.gov>, carlson@lance.tis.llnl.gov (John Carlson) writes: > Is there a good paper which differentiates "User Interface Development > Environment", "User Interface Builder", "User Interface Prototyper", and "User > Interface Management System"? IMHO, these are terms used by sales people, not programmers. Programmers use words like "layout tool" and "dialog management tool". Some current products do both, though most only do layout. A paper by Olsen, et al, called "A Context for User Interface Management" (IEEE CG&A, Cec., 1984) gives a good overview of these concepts. > Now that we are all good toolkit programmers, toolkit > programming is being replaced by user interface builders. How > can we easily take our existing applications and bring them into > the user interface builder world? It's probably not too hard to write a tool that will read your C code (or query your running widgets) and spit out some sort of high level layout/resource specification language. Reverse engineering dialog, on the other hand, seems extremely difficult. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
rlh2@ukc.ac.uk (R.L.Hesketh) (12/02/89)
In article <2213@bacchus.dec.com> klee@decwrl.dec.com writes: >In article <639@ncis.tis.llnl.gov>, carlson@lance.tis.llnl.gov (John >Carlson) writes: >> Now that we are all good toolkit programmers, toolkit >> programming is being replaced by user interface builders. How >> can we easily take our existing applications and bring them into >> the user interface builder world? > >It's probably not too hard to write a tool that will read your C code >(or query your running widgets) and spit out some sort of high level >layout/resource specification language. Reverse engineering dialog, on >the other hand, seems extremely difficult. Yup, reading a widget tree and producing a user interface "layout" specification is not too difficult .. I know, I've done it 8-). Ken is right about the dialog though. You can extract all the resources on a widget instance, including the current translations and compare these against the widget classes' default values, junking the ones that are the same. You can even check the application added actions and callback routines on the callback lists and produce procedural stubs for these. I am currently developing a layout/UI builder/resource manager tool which has a "vampire tap" facility to latch on to existing toolkit programs. The only proviso is however, that the application must be recompiled and linked against a library containing the inter-client communication mechanisms .. plus any Xt{App}MainLoop()'s must be replaced by one of my own. This sets up the link behind the application's back ... it then allows the UI layout (or whatever you want to call it) to latch on to the running application and suck out a copy of its contents. This also means that the application can be edited as it is running (you can do this to some extent using the Macintosh's ResEdit program). Of course this also means you can cause a program to core dump remotely 8-}. My tool has already attached to itself and further refinements to its own interface should be possible using itself (this appears to be a standard test a for UI builder .. can it build itself?). So reverse engineering using the toolkit is very much possible and highly practical. I would very much like to discuss with any interested people the problems involved with interactive UI building and, more importantly to me, the practicalities of end-user customization of user interfaces. >Ken Lee Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 3682/7620
garya@garya.Solbourne.COM (Gary Aitken) (12/05/89)
We have a crude approach which hasn't really been exercised much,
but it involves a flag you can give any application built with our
toolkit which, upon termination, causes the toolkit to spit out the
appropriate code to set up the application from the prototyper output.
So... you start up the application with the dump proto config flag on
rip out all the code which builds the object tree
insert a call to build the object tree from the proto output
You're supposed to be done.
I think the principle is sound, and it works in the few test cases I've done.
You'd have to modify the toolkit so objects know about prototyper output for
this to work, unless your toolkit already knows about it.
--
Gary Aitken
Solbourne Computer Inc. ARPA: garya@Solbourne.COM
Longmont, CO UUCP: !{boulder,nbires,sun}!stan!garya