stergios@Jessica.stanford.edu (stergios marinopoulos) (06/12/89)
My last count showed there exist 6 toolkits and not one user interface builder. I'm really curious how this imbalance came to be. It seems people believe there is *no* difference between toolkit facilities and user interface builder facilities. While I find no fault with the toolkit programming interface, I do not believe that every X programmer should have to learn the intrinsic just to be productive. Obviously I am not speaking about a radically new idea here. The Mac has ResEdit, the Amiga has Power Windows, and the Next has the Interface Builder. With each of these I can create a *complete* user interface and not wright one line of code! Not one. This is simply impossible with the toolkits. An interface builder abstracts the specification of the user interface away from its implementation. It then compiles the specification into an implementation which can, and I dare say should, take on various platform characteristics. Implementations of a user interface specification should be identical regardless of whether it runs on X, MS Windows, GKS, Intuition, Display Postscript or any other windowing system, the same as one would expect C code to compile to equivalent operations on different instructions sets. A windowing system is not an end on to itself for application programmers, rather a vehicle used along the path of implementation. And yet I see 6 different toolkits non of which provide anything substantially better than the next, and not one tool that helps with the implementation of specifications, more over some toolkits even enforce specification. Lets say you have an application that runs on all windowing systems and you want to change or add to the behavior of the user interface. How will you do it? Modify a toolkit by changing or creating a new widget? Wright this code for each window system? On a particular window system will you write code for each toolkit? Who will QA all this work? How many people will it take to add and maintain this? Big and expensive questions indeed! It is time to stop building toolkits interfaces to X and get to the real productivity problems encountered by application programmers. While toolkits do relieve the burden of having to learn Xlib (which is all I will use by the way), they simply create a different set of implementation challenges for the application programmer. We need an Interface Builder. One that can compile user interface specifications into various implementations be they Xlib, Xt, Xmu, Xaw, or Interviews. Real productivity is only achieved when large numbers of lines of code are eliminated; not reduced, not replaced. Stergios Marinopoulos stergios@jessica.stanford.edu
peter@ficc.uu.net (Peter da Silva) (06/12/89)
Interface builders are nice, but they really don't solve the basic problem... which is a standard programmer interface to windowing. Even with the best IB in the world, you still have to write code to actually talk to the screen. It seems to me that windowing systems are where Basic was in the early seventies, with a dozen mutually incompatible dialects... none of them particularly nice. You all know what's happened there. The standard for Basic is now Microsoft's rather poor design (even for a Basic). Yes, I realise that using Basic as an analogy is not calculated to please, but I really don't think any of the programmer interfaces to windows are any better designed. Basic has a poor programming paradigm, but pretty much all windowing systems are no better as graphics programming paradigms. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
phil@GOLDHILL.COM (06/13/89)
> My last count showed there exist 6 toolkits and not one user interface > builder. I'm really curious how this imbalance came to be. It seems > people believe there is *no* difference between toolkit facilities and > user interface builder facilities. While I find no fault with the > toolkit programming interface, I do not believe that every X > programmer should have to learn the intrinsic just to be productive. If they aren't learning the X intrinsics and toolkit then by definition the programmer is not an X programmer. > Obviously I am not speaking about a radically new idea here. The Mac > has ResEdit, the Amiga has Power Windows, and the Next has the > Interface Builder. With each of these I can create a *complete* user > interface and not wright one line of code! Not one. This is simply > impossible with the toolkits. I'm familiar with the above but have not used any of these tools. I have built menu/dialog layout tools for MS/Windows and believe that there are many issues that need to be addressed: 1) What are the objects that are supposed to be manipulated? If we're just dealing with menu and dialogs then the list of ojects are narrowed down but the list is still long: buttons (square, rounded, pixmaps), selectable text (font, location relative to other objects, clipping behaviour), non-selectable text (similar issues to selectable text), scrolling non-editable text, scrolling editable text fields, popup list menus, checkboxes, and radio buttons are all objects that I would want to manipulate. I'm not a CAD/CAM user/implementor but I have to believe that the primitives that are requires in a CAD interface go beyond the level of buttons and checkboxes. Let's not forget 3D, animation, voice, mixed media, etc... These are all parts of a user interface. 2) What is the behaviour of these objects? How are callbacks supposed to be associated with events and objects? There are posted examples of tools that will take a relatively high level description of a layout of buttons, edit fields, etc... and produce toolkit calls to support the appearance. Behaviour and actions need to be added by hand however. > [ section removed ] > > Lets say you have an application that runs on all windowing systems > and you want to change or add to the behavior of the user interface. > How will you do it? Modify a toolkit by changing or creating a new > widget? Wright this code for each window system? On a particular > window system will you write code for each toolkit? Who will QA all > this work? How many people will it take to add and maintain this? > Big and expensive questions indeed! Big and expensive - yes. But atleast a standard exists and companies that would never have adopted such an open standard 5 years ago now have. Programming in an event driven, bit-mapped, extendable window system is not something that you can do without long hours of learning, experimenting, testing, etc... Maybe the day will come when the best and the brightest don't have to spend over 5 years developing standards and systems and we all know how to program these systems when we get out of high school > It is time to stop building toolkits interfaces to X and get to the > real productivity problems encountered by application programmers. > While toolkits do relieve the burden of having to learn Xlib (which is > all I will use by the way), they simply create a different set of > implementation challenges for the application programmer. Toolkits arise out of an awareness among many peers that there are a set of common ways of doing things and that an API or protocol might eliminate redundant methods. > We need an Interface Builder. One that can compile user interface > specifications into various implementations be they Xlib, Xt, Xmu, > Xaw, or Interviews. Real productivity is only achieved when large > numbers of lines of code are eliminated; not reduced, not replaced. I agree that a menu/dialog editor needs to be built as well as a language in which to describe the primitive, and it would be great if there was a public domain version that performed everything that you ask. Perhaps a group should be formed to address this very problem, but let's not forget the spirit of X and how much it has accomplished. Phil Stanhope Gold Hill Computers, Inc. Cambridge, MA. phil@goldhill.com
rlh2@ukc.ac.uk (Richard Hesketh) (06/13/89)
In article <2904@portia.Stanford.EDU> stergios@Jessica.Stanford.EDU (stergios marinopoulos) writes: >Obviously I am not speaking about a radically new idea here. The Mac >has ResEdit, the Amiga has Power Windows, and the Next has the >Interface Builder. With each of these I can create a *complete* user >interface and not wright one line of code! Not one. This is simply >impossible with the toolkits. Hmm. This depends upon where you draw the line between the User Interface of an application and its core functionality. Many direct manipulation style applications require a very tight cooperation between the core part and user interface. Building this type of user interface with a prototyping system is difficult due to the need to talk to core routines .. some "code" is needed here. Systems like Brad Myers' PERIDOT go some way to the removal of programming in the design of user interfaces however having an "Interface Builder" is not a final solution. User Interface Management Systems have been put forward as a method for building all sorts of user interfaces. However due to the currently incomplete knowledge on the subject of what makes a "good" and usable user interface, they are limited to certain user interface styles and domains. >An interface builder abstracts the specification of the user interface >away from its implementation. It then compiles the specification into >an implementation which can, and I dare say should, take on various >platform characteristics. Current systems exist, as you say on other Windowing environments. Its just a matter of time before these things become available. I too am wondering why no visual user interface editor is currently available. However if you consider the immaturity of the toolkits available (or soon to be available) you'll realize that the problem of user interface design using object-oriented style toolkits is still being investigated. This does not mean however that user interface builders shouldn't be produced right now. DEC has its User Interface Language (UIL) for its DECWindows. Looking at its syntax it reminds me of COBOL which does nothing for the "casual" user interface designer or user who wants to dabble. A more promising example of a user specification language has just been posted to comp.sources.sun which only runs under SunView (pardon my language 8-) its called ToolTool and is a specification language for producing toolkit based user interfaces using user interface components. Whilst this currently only runs under SunView the syntax is not highly dependent on SunView (although the code generated is 8-{). The author, Chuck Musciano (chuck@trantor.harris-atd.com) says he would like to see it ported to other windowing environments, like X (any takers?). If the View2 toolkit, said to be included free with R4 is backwards compatible with existing SunView programs then I guess it should be able to port ToolTool to use this new toolkit? >Lets say you have an application that runs on all windowing systems >and you want to change or add to the behavior of the user interface. >How will you do it? Modify a toolkit by changing or creating a new >widget? Wright this code for each window system? On a particular >window system will you write code for each toolkit? Who will QA all >this work? How many people will it take to add and maintain this? >Big and expensive questions indeed! Take a look at March'89 issue of BYTE which contains a software review of "A Virtual Toolkit for Windows and the Mac" by Ray Valde's. This describes a product called XVT which is basically a library of routines for generating graphical applications that has been ported to MS Windows and the Macintosh. They are currently working on a version for X11, another paper in the April Conference Proceedings of the European Unix Users Group (EUUG) describes this current effort. > >It is time to stop building toolkits interfaces to X and get to the >real productivity problems encountered by application programmers. Yes and No. Carry on refining the toolkit paradigm but also produce user inteface designing systems. I would prefer to see graphical editors and incremental execution environments .. why should we be stuck with grammar definitions when we can use visual languages? >Stergios Marinopoulos >stergios@jessica.stanford.edu Thanks for bringing this up, more needs to be said on the subject of visual, dynamic, user interface builders/editors and the associated support tools. Power-tools for the people 8-) Richard Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: (0227) 764000 ext. 3682
peter@ficc.uu.net (Peter da Silva) (06/13/89)
In article <8906121703.AA01605@godiva.goldhill.com>, phil@GOLDHILL.COM writes: > If they aren't learning the X intrinsics and toolkit then by definition > the programmer is not an X programmer. Is this really relevent to anything? The goal is getting an environment where programmers can create reasonably efficient and portable window-oriented applications. If those programmers aren't X gurus, who cares? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
trost@crl.labs.tek.com (Bill Trost) (06/14/89)
In article <2904@portia.Stanford.EDU> in comp.windows.x, stergios@Jessica.stanford.edu (stergios marinopoulos) writes: ``It is time to stop building toolkits interfaces to X and get to the real productivity problems encountered by application programmers. While toolkits do relieve the burden of having to learn Xlib (which is all I will use by the way), they simply create a different set of implementation challenges for the application programmer. ``We need an Interface Builder. One that can compile user interface specifications into various implementations be they Xlib, Xt, Xmu, Xaw, or Interviews. Real productivity is only achieved when large numbers of lines of code are eliminated; not reduced, not replaced.'' So quit your ranting and raving a write one. X11 is the result of hundreds of people developing various programs as they feel the need for them and contributing them to the community. If you feel there is something lacking, perhaps you should do something about, not gripe at everyone how difficult things are. X is not their responsibility; it's *our* responsibility.
janssen@xerox.com (William Janssen-SSL) (06/14/89)
In article <2904@portia.Stanford.EDU>, stergios@Jessica (stergios marinopoulos) writes: >My last count showed there exist 6 toolkits and not one user interface >builder. Well, Andrew has the beginnings of an editor-based one, in ADEW, but you're right; this is a strange situation. Bill Bill Janssen janssen@sw.mcc.com (512) 338-3682 MCC Software Technology Program 3500 W. Balcones Center Drive, Austin, Texas 78759
wdc@ATHENA.MIT.EDU (Bill Cattey) (06/21/89)
There are the beginings of a user interface builder and an extensible toolkit environment right there on your X tape. It's the Andrew Toolkit, and it's ADEW subsystem. The ADEW system was featured in a talk at January's X conference at MIT. It has some major problems: 1. It's not compatible with the X toolkit intrinsics. Interestingly, it's window server independent graphics layer does some useful stuff that was missing from the XVT system. 2. It is not user-interface policy independent. I like to think of it the way we used to talk about the Bell System: One system -- it works. 3. It contains an operating system specific dynamic object loading system. This took two person months for Olivetti to port to their UNIX port, but it _was_ UNIX dependent. 4. Some coding is still required. But the modules are templated with helpful comments automatically generated showing where the user has to add code. 5. It is 400,000 lines of C code that is intimidating to get running. This code yeilds a different, simpler intrinsic toolkit layer, the dynamic object loader, a multi-font text editor, a rich widget set, including geometry management, and a variety of high level applications, such as a drawing editor, a spreadsheet, a raster editor, and a multi-media mail interface. ---- I have been trying to motivate development with this stuff along several fronts: 1. Getting people to at least look at the stuff. Maybe compile it and try it out and think about it. 2. Discussion of what unique features and technology the ATK stuff has to offer. 2. Re-consideration of the X toolkit intrinsics in the light of the emerging Motif user interface policy. 3. Development of useful applications with the ATK objects which offer a much wider diversity of functions than presently existing X intrinsics based widgets. 4. Development of code that will enable applications written using the unique ATK abilities to migrate to what eventually becomes the full-featured industry standard. ---- Here at Athena, the home of X, we also look at other useful and interesting technologies. People interested in cooperating on studying, using, evaluating, and developing using contrib/toolkits/andrew can contact me directly or can enroll in the CMU based andrew mailing list by sending mail to info-andrew-request+@andrew.cmu.edu -wdc wdc@athena.mit.edu