Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!crdgw1!crdgw1.ge.com!barnett From: barnett@crdgw1.crd.ge.com (Bruce Barnett) Newsgroups: comp.windows.news Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? Message-ID: <4392@crdgw1.crd.ge.com> Date: 2 Jan 90 05:40:36 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> Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.crd.ge.com (Bruce Barnett) Organization: GE Corp. R & D, Schenectady, NY Lines: 122 In-reply-to: peter@ficc.uu.net (Peter da Silva) In article , peter@ficc (Peter da Silva) writes: >> 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. I generally use the scrollbar to "go to" a different part of the object I am looking at. I also like to jump to specific line numbers or procedures. Why shouldn't this be in the scrollbar? It is true that I could do this by a pop-up menu in the main window, but I might want to keep this menu free for my application, and since I can ask for a menu in the scrollbar area, why not use it? Also - the scrollbar can be used as the mechanism to split a window into two separate views of the same object, with two separate scrollbars. This little "feature" requires forethought; adding this to the UI might require a major rewrite of the code. Even if you would NEVER want to do the above, the point is - some people do want the ability, and because the style guide says it is possible, the toolkits should support this feature. Without the style guide, a toolkit could be written that would require major source code changes to support new features. All I am doing is repeating the basic software engineering waterfall model. To repeat myself, I believe AT&T/Sun did the right thing by specifying the style guide first, and then develop four toolkits that more or less meets the specification of the style guide. The obvious goal is to have several independent groups develop the best toolkit for the market segment. An application programmer can pick the most appropriate toolkit (X intrinsics, XView, NeWS, or SunView) and the end user will be unaware that there are different toolkits underneath. As this conversation proves, there is no one right language to everyone. Trying to specify a single language/window interface that can meet everyone's requirements is not possible. >X is a dead end. As I've said before, it's the Fortran of windowing systems. > So why standardize on an X toolkit? I'm not sure what you are asking. There are obvious reasons to standardize on an X toolkit. Unfortunately, the application writers and the end users will suffer, unless AT&T and OSF merge the two user interfaces. >> 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. Well, you may consider items like menus, windows, icons, cursors, buttons, scrollbars, and drawing primitives to be separate items with separate interfaces. NeWS views those items as different objects in the same class hierarchy. You can draw an object, enlarge it and use it as a background on your screen, convert it to an icon, button, window, cursor or anything else you want. There is no reason you couldn't, in NeWS, draw a new geometric shape, like a rectangle with curved corners complete with a shadow, and then make that shape the new default shape of all of your windows. You can also change constants (like the color of a window) into a procedure. In otherwords, the restrictions in most window systems don't apply to NeWS. A "standard program interface" would effectively eliminate most of the advantages of the NeWS windowing system. It's like asking a Lisp programmer to program in Fortran. [I talked about the shortcomings of Open Look, and how it doesn't support user defined keyboard accelerators for menu items] >Yes, but you can also add menu accelerators by using keyboard shortcuts. >> 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. This is a misunderstanding here. I was discussing how Open Look does NOT allow the user to add keyboard accelerators. If I were developing a program that used Open Look, I would provide some way for the END USER to add those keyboard accelerators for the menu choices. >> 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. Huh? There are a lot of satisfied Mac users. There are people who LIKE a one-button mouse. Convince them the user interface and/or the program needs redesign. >Unfortunately the NeWS toolkit is too big for today's small computers. As is X. > Oh, and it's still proprietary to Sun, It comes with the Unix source tape. >and not even available for the small machines that *can* support it >(that is, the ones not dependent on intel's brain-dead processors). Shrug. It was your decision to buy an Amiga. Bug Commodore for Unix V.4. -- Bruce G. Barnett uunet!crdgw1!barnett