Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!texbell!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.windows.news Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? Message-ID: Date: 31 Dec 89 01:24:02 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> <4360@crdgw1.crd.ge.com> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 137 In article <4360@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > In article <7422@ficc.uu.net>, peter@ficc (Peter da Silva) writes: > >The application programmer should not have to deal with the details of a > >scrollbar. Changes to the scrollbar should be outside the application binary. > 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? What does this have to do with a scrollbar? This sort of functionality could be attached to the window as a whole, with little if any loss of generality. Attaching menus to objects smaller than a window seems of dubious value to me. Your point seems to be that standardising will limit the things that can be done to the window. What if you're running under a window system that traps the menu button at a higher level? That won't let you attach a menu to something like a scrollbar? Now you've lost a capability... your program isn't portable anyway. I agree... standardisation involves limiting the capability of the programmer to implement things. It's the price you pay for the ability to run a program on a wide variety of systems. > >X is a dead end. As I've said before, it's the Fortran of windowing systems. > Good analogy. Thanks. So why standardize on an X toolkit? > >> 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. Yes, but it shouldn't require that environment. I find it hard to see how a standard program interface to windows will limit the utility of object oriented programming techniques any more than a standard program interface to files. > 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. Sure. I could really improve the capability of Browse if I could get real-time response, or if I could watch files to see when they change. But the hooks don't exist. You could do all sorts of amazing things with the machine if the interface to the file system was just a shared library that you could dig into and go around. There are good reasons for locking stuff away behind doors: security, efficiency (how well would buffer pools work if all programs had their own copy of the FS? How much work would be duplicated if every program had to do its own locking?) I think that windowing systems are another place where this sort of thing should be considered. > 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 someone proposed a "windowing standard" that *required* O-O languages to work, I wouldn't even consider it usable. > 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. Yes, but you can also add menu accelerators by using keyboard shortcuts. I like them a lot better, because I generally don't have a lot of screen real-estate to throw away. If the UI wasn't in the program, I could take your application and set it up on my screen with Alt-N for New, Alt-D for Delete, and so on. *I*, as a user, could customise the UI. > The application programmer is no longer required to add special code > to duplicate this functionality. the application programmer was never required to do this. > Yet this is so important that each > programmer would add this extension in some unique way. That's your opinion. Not mine. Much more important is the ability for me, as a user, to customise the hell out of my environment without having to put up with application programmers stuck on Open Look, or Motif, or whatever. > The end user would then be faced with a several programs with > incompatible accelerators, giving the impression that each program had > a different interface. Not if the standard said "The user will have the ability to provide shortcuts for menus. The mechanism of this shortcut is not specified, and may change from one minute to the next, and in fact multiple methods may be used". > 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. No, you'd have some *applications programmers* using pushpins, some using keyboard shortcuts, some using floating icons or icon bars, and so on... Or else you'll have people using pushpins, and pushpins only, until the cows come home. > I don't believe that. The UI can be integral to a nicely tuned program. If the UI is *that* integral to the program, then the UI or the program needs some redesign. > 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. Yes, but it doesn't (back to my point) require the PROGRAM as a whole to be written in an O-O language. Unfortunately the NeWS toolkit is too big for today's small computers. Which are going to be with us for a long time to come. Oh, and it's still proprietary to Sun, and not even available for the small machines that *can* support it (that is, the ones not dependent on intel's brain-dead processors). A properly designed windowing standard would let you port a program from the Sun to the Mac just by recompiling. Like Guido Von Rossum's "STDWIN" package. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "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