Xref: utzoo comp.windows.news:1758 comp.windows.misc:1284 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!crdgw1!crdgw1.ge.com!barnett From: barnett@crdgw1.crd.ge.com (Bruce Barnett) Newsgroups: comp.windows.news,comp.windows.misc Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? Message-ID: <4360@crdgw1.crd.ge.com> Date: 27 Dec 89 12:53:38 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> <4318@crdgw1.crd.ge.com> <7422@ficc.uu.net> Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.crd.ge.com (Bruce Barnett) Followup-To: comp.windows.news Organization: GE Corp. R & D, Schenectady, NY Lines: 119 In-reply-to: peter@ficc.uu.net (Peter da Silva) In article <7422@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Yeh, but that extension should not be in the application. The application >programmer should not have to deal with the details of a scrollbar. Changes >to the scrollbar should be outside the application binary. Not necessarily. Changing the cosmetics of it, and the simple user interface, yes. But suppose you had a scrollbar on a text window - like a C program. And you wanted to implement a pop-up menu that showed all of the functions defined in the program, allowing you to "go to" any function? This requires some interaction from the application programmer. If the scroll-bar didn't implement a pop-up menu, or implemented one that had a fixed list of choices, the application programmer must extend the scrollbar code to implement such functionality. >X is a dead end. As I've said before, it's the Fortran of windowing systems. Good analogy. >> It is true that there are a lot of applications that don't need O-O >> techniques to develop powerful programs for them. But others do. >Fine. And some applications don't need real-time response, but others do. >Does this mean all programs should be written in a language designed for >real-time work on a real-time O/S? I'm saying that if someone is proposing a standard that will be useful to as many applications as possible, it should support the a programming environment that makes the standard useful. User interfaces should not be cast in stone. There should be room to grow. Programmers need to modify and improve the efficiency of the program with respect to the interaction with the user. O-O techniques allows the programmer to easily change small portions of the user interface. It also allows the programmer the ability to extend the interface for a program without breaking other applications. If someone proposed a "windowing standard" without O-O extensions, I wouldn't even consider it usable. Unless I wanted something "quick and dirty". >> If you want a standard to be a subset of a powerful window system, fine. >> I don't want such a standard myself. I would rather search for the >> perfect user interface. > >Well then you don't think we need to standardise the UI either. > >Right? There is no doubt about the fact that a standard user interface will help Unix become more popular, which means programs become better, easier and cheaper. I also think the Right User Interface is not here yet. I feel it is important to have a style guide as a framework for future development. You need some starting point because the toolkit developers need to understand the basic features of the UI. Take Open Look's Push Pin menus. The fact that any menu can be pinned into place has implications in the program using this technique. One thing this does is provide an automatic means for adding menu acelerators - that is, if you use a menu often, you can pin it into place. The application programmer is no longer required to add special code to duplicate this functionality. Yet this is so important that each programmer would add this extension in some unique way. The end user would then be faced with a several programs with incompatible accelerators, giving the impression that each program had a different interface. There are a few things I do not like about the Push Pin menus - 1) The Push Pins and frames are too large. A lot of screen real-estate is used to show the frame and whitespace. 2) No keyboard accelerators - Some Mac applications have the ability to bind a key sequence to a menu choice. I think this should be added. I would like to change the window system to add these features. Others might change the initial package some other way. Eventually, the push-pins would evolve into it's replacement. >And it would, properly designed, accelerate evolution towards a decent UI, by >moving UI decisions OUT of the application. I don't believe that. The UI can be integral to a nicely tuned program. >On the other hand a standard user interface just wastes time making people >rewrite working software. And *stops* evolution towards a better one. > >Pick your poison. My "poison" would be tNt (the NeWS toolkit). This provides a starting point for applications. As I see shortcomings in the UI, I could extend the UI and make a program more useful to the end user. Since the extensions are made dynamically, I can either make a new class for just my applications, or if I felt the extensions was useful for all other applications, I would change the default object to my new improved object. All applications would then be improved, without recompiling, etc. Of course if the new model of the scrollbar, menu, etc. offered new functionality requiring new input from the application, it would have to be modified to make use of that new feature (like the scrollbar for the C program above). And since the NeWS toolkit is a complete O-O toolkit with multiple inheritance, I can use as much or as little of Open Look as I desire. I can use the scrollbar and nothing else - if that is what I need. I wouldn't call it poison. More like the first step towards my goal. -- Bruce G. Barnett uunet!crdgw1!barnett