Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!wuarchive!texbell!sugar!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: 2 Jan 90 15:11:46 GMT References: <8912162135.AA03025@iris.rand.org> <4290@crdgw1.crd.ge.com> <4392@crdgw1.crd.ge.com> Organization: Xenix Support, FICC Lines: 71 > since I can ask for a > menu in the scrollbar area, why not use it? Perhaps because having a bunch of context-sensitive menus attached to different parts of the window is a bad idea? > 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. Perhaps, if the UI is specified at too low a level. If it's defined in terms of "text pane: size, contents" then what goes on inside that text pane is none of the applications business. Maybe you can "zoom" the pane out to encompass the whole window. Who cares? The application certainly shouldn't. The sort of micro-optimisation you're pushing for here seems penny wise and pound foolish. > 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. No, but you can come close if you don't concentrate on details. > >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. Menus are a reasonable level of abstraction. Buttons, scrollbars, and the like aren't. They're too low. That's more in the lines of a standard program interface to arrays. Too language and application dependent. [lots of good stuff about NeWS] > 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. And everyone else would do it differently. So much for your style guide. > 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. They don't need to be convinced. They're happy with the UI. That's why I'm opposed to Open Look or Motif... it's forcing a single (new) UI on folks who are already happy with the one they have. And I see no reason why a program running under the Mac UI should have one line of code different from one running under Motif or Open Look. > >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. And what about all the people with Macs? Or even Atari STs? Should they dump Finder and Gem? Maybe they like their own UIs... Actually the Amiga is better off than most home computers here. V.4 has been shown, and NeWS runs under AmigaOS. It's just not available for said political reasons. Or are you saying that if you can't afford a 5-10 grand workstation you aren't worth paying attention to? -- `-_-' 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