peter@ficc.uu.net (Peter da Silva) (12/27/89)
> Portability is not easy in the X world. You must worry about > fonts to use [etc etc] Yes, I'm aware that X has some horrible design choices. > One of the best methods is to use Object > Oriented programming. You should be able to extend a scrollbar to > improve on it. 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. Of course this is virtually impossible in X. Which is why making X or X toolkits the basis of a future standard is, well, a horrible idea. X is a dead end. As I've said before, it's the Fortran of windowing systems. > 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? > 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? > If you want an application to run on PC's, Mac's, Amiga's and Unix > machines - I agree - this is a difficult problem. You can get X for > Mac's and I think PC's. I wouldn't *want* X for Macs or PCs or Amigas. It's big and it locks you into a programming model that isn't necessarily appropriate. But, yes > In conclusion, I think a standard library would limit creativity, and slow > down evolution towards a decent user interface. Depends on what the library looks like. And it would, properly designed, accelerate evolution towards a decent UI, by moving UI decisions OUT of the application. 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. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
barnett@crdgw1.crd.ge.com (Bruce Barnett) (12/27/89)
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 <barnett@crd.ge.com> uunet!crdgw1!barnett
walters@community-chest.uucp (Chris Walters) (12/28/89)
In article <7422@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I wouldn't *want* X for Macs or PCs or Amigas. It's big and it locks you into >a programming model that isn't necessarily appropriate. But, yes Sure. X11/NeWS is BIG, X is just big. At least X will run on a 4MB 3/50. >`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. > 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. -- Chris Walters, walters@community-chest.mitre.org -- Chris Walters, MITRE McLean