gnu@hoptoad.uucp (John Gilmore) (12/09/89)
In article <5fLz02oD72dj01@amdahl.uts.amdahl.com> aksegu@uts.amdahl.com (Ashok Kumar A. Segu) writes: > I was going thru the SPARCserver family specifications (technical > brochure) ans saw that the WINDOW SYSTEM that SUN supports is > OpenWindows. This was also reiterated by Mr. Scott McNealy and Mr. Eric > Schmidt at the introduction of SPACRCserver 1 and 490 on Dec.6th. > > Guess what folks, the SYSTEM SOFTWARE does not include OpenWindows, > but includes SunView. rogern@sun.com (Roger Nolan, Product Marketing Manager--Windows) wrote: > This sounds like a misunderstanding. The OpenWindows Developers Release > 1.0 is supported and shipping on SPARC systems. No, this sounds like deliberate evasion. All the Sun press releases and speeches and brochures and stuff talk about Open Windows as if it was real, but Sun still ships the old SunView stuff and doesn't ship Open Windows *with the system*. Calling it a "Developers Release, SPARC Only" would be fine -- just stop telling the press and the customers that Sun is 100% behind Open Windows, leaving them with an ugly surprise when the system arrives. Also, I thought the Intel and Motorola ports would be out in October: > From: rprobst@SUN.COM (Richard Probst) > Newsgroups: comp.windows.x > Subject: Sun ships OpenWindows > Message-ID: <8909270029.AA26500@paba.sun.com> > Date: 27 Sep 89 00:29:27 GMT > > Sun is now shipping OpenWindows 1.0 on SPARC machines. Sun-3 and Sun386i > versions will start shipping in 30 days. > > OWN-1.0-4-4-5 SPARC -- Doc and Media $ 295 ND ** 9/25/89 > OWN-1.0-4-3-5 Sun-3 -- Doc and Media 295 ND ** 10/25/89 > OWN-1.0-4-R-5 386i -- Doc and Media 295 ND ** 10/25/89 (Note the dates in the last column.) > This means that you can buy one copy of the media and > documentation and run it on as many Sun workstations as you like. Oh, really? Can I upload it to uunet and let anybody FTP it or uucp it from there? Can I put it on the Sun User Group tape? Can I send it to the guy in Europe who is getting a runaround from his sales office but keeps seeing postings from other people who have it? If so, why didn't Sun just do all this stuff? Or simply put it on the next &%^$ Unix release! > At the current time, OpenWindows is a Developers Release. We are not > recommending it to the general end user community at this time. As a > result, SunView is still bundled with all of our systems and is the > default window system for Sun workstations. And with this policy, it sure will stay that way. Imagine you are a software developer. Let's say you port your first Sun product to Open Windows. The customers start to buy it. You ship them copies. Then: "What do you mean I can't run it? I have to buy Open Windows from Sun? You've ordered things from Sun before, it will take weeks just to get my sales rep to return a call, since I only bought three workstations. Howabout I just send back your software?" Will OpenWindows be bundled in SunOS 4.1, or will we have the same story for another whole year? -- John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com Just say *yes* to drugs. Use your *no*s for government bullshit.
barnett@crdgw1.crd.ge.com (Bruce Barnett) (12/14/89)
In article <9236@hoptoad.uucp>, gnu@hoptoad (John Gilmore) writes: >Will OpenWindows be bundled in SunOS 4.1, or will we have the same >story for another whole year? Well, from what I hear, the alpha/beta test time for SunOS is HUGE! By separating window stuff from SunOS, we might see new releases of SunView and OpenLook before we see SunOS 4.1. Sure enough, I just got the following message: ------------------------------------------------------------------------------- SUN INTRODUCES NEW EASY-TO-USE TOOLS FOR DESKSET SunFLASH Vol 12 #1 December 1989 ------------------------------------------------------------------------------- Free Right-To-Use License Included With All Sun Workstations MOUNTAIN VIEW, Calif. --December 5, 1989-- Sun Microsystems today introduced an enhanced release of the DeskSet(TM) environment, a suite of easy-to-use, window-based tools built around the OPEN LOOK(TM) graphical user interface. Four new tools bring the DeskSet 1.0 total to 12 making this the most extensive set of tools available on workstations today. Sun also announced that a free right-to-use license for DeskSet 1.0 is now included with all Sun workstations. These "essential" tools such as a file manager and mail tool make the UNIX(R) operating system simpler, replacing the keying in of commands with the point and click of a mouse. Additionally, the tools can be run in a 2-D or 3-D mode. DeskSet 1.0 will be of particular interest to independent software developers who use the SunView(TM) window system, since the new release enables them to add "drag and drop" functionality to their SunView applications. Until now, DeskSet has only been available for X-based applications. DeskSet was first released in April as a part of the OpenWindows(TM) application environment, built on the X11/NeWS(TM) window system. The new release includes four new tools: a calendar manager, print tool, tape tool and calculator, in addition to the original tools: file manager, mail tool, text editor, binder, icon editor, snapshot tool, performance meters and clock. All 12 tools utilize the "drag and drop" method of directly manipulating visual objects with a mouse, making work very fast and intuitive. The New Tools: Calendar manager simplifies appointment and resource scheduling, notifying the user of scheduled one-time or ongoing meetings, visually or via sound; Print tool enables users to simply "drag and drop" an icon with a mouse to print documents or mail messages; Tape tool provides an easy way to read, write or list data from a local or remote tape drive; Calculator is programmable for algebraic, scientific and logic mathematical functions. Availability The DeskSet 1.0 tool suite will be available during the first quarter of 1990. A right-to-use license is free with every Sun workstation shipped; tape and documentation are $295. The suite is available on all Sun platforms and requires only 4 megabytes of memory. Sun Microsystems, Inc., headquartered in Mountain View, Calif., is a leading worldwide supplier of network-based distributed computing systems, including professional workstations, servers and UNIX operating system and productivity software. ### OpenWindows, SunView and DeskSet are trademarks of Sun Microsystems, Inc. UNIX is a registered trademark and OPEN LOOK is a trademark of AT&T. All other products or services mentioned in this document are identified by the trademarks or service marks of their respective companies or organizations. For reader inquiries, telephone 1-800-821-4643 outside California. Inside California, call 1-800-821-4642. Press Contact: Cathy Garfield (415) 336-6536 -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
salzman%iris@RAND.ORG (Isaac) (12/18/89)
>No, this sounds like deliberate evasion. All the Sun press releases >and speeches and brochures and stuff talk about Open Windows as if it >was real, but Sun still ships the old SunView stuff and doesn't ship >Open Windows *with the system*. yup! all talk, no action. don't count on seeing OpenWindows shipped with SunOS until SVR4/SunOS, which is quite a ways off. >Calling it a "Developers Release, SPARC Only" would be fine -- just stop >telling the press and the customers that Sun is 100% behind Open >Windows, leaving them with an ugly surprise when the system arrives. >Also, I thought the Intel and Motorola ports would be out in October: >> Sun is now shipping OpenWindows 1.0 on SPARC machines. Sun-3 and Sun386i >> versions will start shipping in 30 days. >> >> OWN-1.0-4-4-5 SPARC -- Doc and Media $ 295 ND ** 9/25/89 >> OWN-1.0-4-3-5 Sun-3 -- Doc and Media 295 ND ** 10/25/89 >> OWN-1.0-4-R-5 386i -- Doc and Media 295 ND ** 10/25/89 >(Note the dates in the last column.) >> This means that you can buy one copy of the media and >> documentation and run it on as many Sun workstations as you like. hey, i thought the SPARC release would be out in SEPTEMBER!!! that announcement looks to me like a blatant lie. those dates are completely bogus. yes i know it's a developers release and that it's not an FCS product. but when you make announcements like that, please explain what a developers release is! the above announcement gives me the impression that i can place an order and expect it to arrive within a reasonable amount of time (with their s/w shipping record, that'll be about a month, which really isn't reasonable but....), and that's not the case. the case is, as i found out from the SUG conference - that they are (severly) limiting the number of copies shipped. >Oh, really? Can I upload it to uunet and let anybody FTP it or uucp it >from there? Can I put it on the Sun User Group tape? Can I send it to >the guy in Europe who is getting a runaround from his sales office but >keeps seeing postings from other people who have it? If so, why didn't >Sun just do all this stuff? Or simply put it on the next &%^$ Unix >release! according to their release notice, we should be able to get it via FTP or UUCP. the RTU is part of SunOS. yeah, right. the RTU is limited to some X-hundered of preferred customers. why? because they aren't ready to support it yet with 1-800-USA-4SUN. why can't they just make that fact explicit in the RTF and ship the thing already!!?? i can't think of one GOOD reason, can anyone else? >> At the current time, OpenWindows is a Developers Release. We are not >> recommending it to the general end user community at this time. As a >> result, SunView is still bundled with all of our systems and is the >> default window system for Sun workstations. >And with this policy, it sure will stay that way. no kidding! so far everything they've done has accomplished nothing but decrease the likelyhood of the products success. they are simply killing it. if they wait long enough, they won't have to ship it at all. they can just bury the tapes and it'll be done with! consider this. many people are interested in Open Windows because the MIT X11R3 server for color Sun's is pathetically slow. if you've got a machine with enough memory to run Open Windows, the color performance blows away MIT X11R3. these customers (and maybe there are only a few), will want Open Windows only for X11 and may have no interest in NeWS. but at least they'll have it in their hands, and maybe they'll try it, and maybe they'll like it! so there's some potential for turning more people on to NeWS. but hey, X11R4 is due out next month. and guess what, the Sun color server is (from all reports that i've heard), a LOT faster than the X11R3 server. so people getting X11R4 will be quite happy and won't have any interest in Open Windows. just keep holding those tapes back.... >Will OpenWindows be bundled in SunOS 4.1, or will we have the same >story for another whole year? it'll be the same old story.... and get this. sun announces their new DeskSet utilities - a (really nice) calendar tool, print tool and tape tool, to go along with the other DeskSet tools - the filemgr, etc. - that come with Open Windows. but these new DeskSet tools are not XView programs - they are not for Open Windows. they are SunView programs! someone please explain the rationale behind this brilliant move. these, along with SunWrite/SunPaint/SunDraw, should all be Open Windows tools (written with XView or The NeWS Toolkit). how are they supposed to promote Open Windows by providing new SunView tools??!!!! and these new tools are really nice. they implement Open Look with a 3D look - real slick. and Open Windows (for those few that have it) is still 2D only. i've been running Open Windows for quite some time now - because we were fortunate enough to get into their beta/special program. it's some pre-FCS release (well, there's no FCS release - so pre-developers release i guess). but i've used their current release at SUG, and they are quite similar, so for all i know it's the same thing they're shipping (in very limited quantity). but i can't know since i can't seem to get my hands on the "released" version. whatever version it is ... i like it A LOT. i'm sure that given the opportunity to run it, so will other people!!! keeping it under lock and key isn't going to do anyone any good. in a way, i see another Xerox happenning. you've got some brilliant people at Sun developing some brilliant products: Open Windows, which includes NeWS, XView, Open Look, and GUIDE as a separate future product (i tried this at SUG, it's GREAT). but their marketting people are killing it. they are being totally wishy-washy. introducing some new products under SunView, some under Open Windows. so if you really want to be up to speed you have to run both! i don't like SunView - because it's not a network based window system. i don't care about running SunView applications under Open Windows. i bet if they gutted the SunView compatibility it's performance would improve DRAMATICALLY!! most of Sun's SunView tools have XView equivalents. many commercial products (will) have X11 (and hopefully NeWS, but not at the rate Sun's going) versions. if you need SunView support, use something like overview or adjacentscreens, but take the overhead out of Open Windows. i also happen to like Open Look. but somehow Motif has taken hold. as far as i'm concerned, Motif is a joke. it may have a nice "look" (the 3D is real cute), but the feel sucks. Open Look goes out of its way to have a good feel and to be consistent (my opinion of course). i've tried a few versions of a Motif X11 window manager. the mouse actions that de-iconify a window on one version ended up killing the window on another version (because it brings up a menu with the default action of killing the window). lots of thought went into that i'm sure. why has Motif taken hold? who knows. XView, a freely available X11 toolkit which implements Open Look, has been out there for a while, but not long enough i guess. it's just very depressing to see what i (and i'm sure many readers of this list) consider to be superior technology end up in the dust because of poor management and marketting decisions. NeWS should've been made public (in the sense that NFS was) a *long* time ago. care to guess what would've happened? Open Windows should be made available to everyone and anyone that wants it. MIT doesn't have a 1-800-USA-4X11, they have xpert@expo.lcs.mit.edu. the people that want Open Windows *now* can support themselves! c'mon Sun, get it together. what good are Open Windows if they are covered by iron bars??!!! -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * Internet : salzman@rand.org / | | * UUCP : !uunet!rand.org!salzman | | |
barnett@crdgw1.crd.ge.com (Bruce Barnett) (12/19/89)
In article <8912162135.AA03025@iris.rand.org>, salzman%iris (Isaac) writes: > How are >they supposed to promote Open Windows by providing new SunView tools??!!!! >someone please explain the rationale behind this >brilliant move. Perhaps they are promoting OpenLook instead of Open Windows. OpenLook has nothing to do with operating systems or toolkits. You can have OpenLook on a PC, Mac, OS/2, Amiga, VMS system. The real goal is to have the same user interface on every computer, not just on Unix workstations running the X window system. Remember the analogy of dashboards - you can get inside any car and drive it away. No so with computers. Also - OpenLook does have some advantages over SunView with respect to user interfaces. I am also sure that a lot of people would love to have the file manager on their workstation and still have all of the advantages of SunView. >i bet if >they gutted the SunView compatibility it's performance would improve >DRAMATICALLY!! It might be true - as a lot of code is in the kernel. Removing 100K from the kernal would give you the equivalent to 1 Meg in user space, since you can page in the code you need. But I don't really understand your comment about "it's performance". what is "it"? The server? The application? The window manager? The real problem is that you may end up using three or more toolkits that are not sharing any code. SunView, XView, tNt, plus the other X toolkits. Each toolkit has it's advantages. But using all three at once does eat up a lot of memory. >most of Sun's SunView tools have XView equivalents. As of today, I doubt this. There are a LOT of SunView programs out there. Catalyst, etc. A year from now you may be right. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
peter@ficc.uu.net (Peter da Silva) (12/19/89)
In article <4290@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > You can have OpenLook on a PC, Mac, OS/2, Amiga, VMS system. > The real goal is to have the same user interface on every computer, > not just on Unix workstations running the X window system. How about the same programmer interface as well? One nice thing about C is that the stdio library gives you pretty much the same programmer interface to what are really quite sophisticated system functions on a wide variety of machines. Don't you think it's time to take a step back and look into this? Until it's there, having a standard *user* interface is a bit premature. -- `-_-' 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/19/89)
In article <7352@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >How about the same programmer interface as well? >Don't you think it's time to take a step back and look into this? > >Until it's there, having a standard *user* interface is a bit premature. I don't agree. First of all, there would have to be a standard language. C++ and Lisp would be a good choice for an object oriented windowing system. And of course PostScript/NeWS. Perhaps the standard has already been defined - CLX. That's X windows on top of CLOS, which is the object oriented extension to common lisp. Does this solve your problem? Of course not. I would rather use an object oriented (O-O) language to support an O-O window system. If I couldn't have that, then I would want a package that would let me design the program interactively, without any programming. I certainly would not want to wait three years for a standards committee to define the stdio-windows library package. And if something does come out - it wouldn't have the ability to provide the features I need today. IMHO defining a standard binding is premature. People don't even know what toolkit to use! Standards are also restricting - they are great at telling people what they cannot do. Defining a standard programming too soon is a disaster. in <7344@ficc.uu.net> Peter says: >Personally, I think terminfo sucks. Case in point. terminfo is a standard package for ASCII terminals. It doesn't make it good. Also - as any novice software engineer will tell you, the first step in a project is the top level specifications. You DON'T write code before you know what it is that you want the code to do. This is the function of the Open Look style guide. I think it is obvious that the top level specifications should be done before any code is written. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
thor@stout.UCAR.EDU (Rich Neitzel) (12/19/89)
> > The real goal is to have the same user interface on every computer, > not just on Unix workstations running the X window system. > > Remember the analogy of dashboards - you can get inside any car and > drive it away. No so with computers. > Sigh! I can't stand it any longer. This is a very bad analogy in my opinion. Yes, I can drive any car car intended for the U.S. market, but the level of commonality is no where near the level that as proposed by the "one user interface claim". I own two cars, made the same year by the same firm and here is a partial list of the differences in dashboard layout- 1> One has the dimmer switch on a lever on the steering column, the other has a foot switch. 2> One has the gear selection lever on the steering column, the other is floor mounted. 3> One has only simple idiot lights that turn red to indicate a problem, the other has analog gauges. 4> The fuel level gauges are on opposite sides of the speedometer. 5> One has a true toggle switch for the rear defroster, the other has a momentary button. Further, the toggle swicth lights up whle the defroster is on, the other has no indicator. 6> On one the heater speed controls are aligned horizontally and placed below and to the right of the temperature control. On the other the speed control is vertically aligned and to the left of the temperature control. I could go on with many more examples of how these two vehicles differ in their control interfaces, but I think the point is clear - despite all the overblown hype about consistent user interfaces and the claims that these are common outside of computing, the truth is quite the opposite. In few cases are there universal interfaces for functions that are even moderately complex. Further, it is rare for users to find this a limitation or barrier to their use of the item in question. When was the last time anyone heard a serious complaint that the dashboard of their Escort was not identical in layout and function to the dashboard in their Civic? I suspect that no reading this has any trouble using an elevator, but there are obviously no standards in their control design, not even in which direction the floor numbers soon run - highest at the bottom, lowest, etc. All this talk about commonality of "look & feel" is simply an attempt to evade the real issue in the design of user interfaces - does the interface for THIS application adequate suit the conditions of use, level of user skill and functionality required to perform the job? Common user interfsces simply make the life of developer easier by allowing one to put on any interface, cklaim that this is good because it is "standard" and walk away. No thought or concern about reality required! Don't force interface applications into a bed of Procrustes (sp?)! ------------------------------------------------------------------------------- Richard Neitzel National Center For Atmospheric Research Box 3000 Boulder, CO 80307-3000 303-497-2057 thor@thor.ucar.edu Torren med sitt skjegg Thor with the beard lokkar borni under sole-vegg calls the children to the sunny wall Gjo'i med sitt shinn Gjo with the pelts jagar borni inn. chases the children in.
peter@ficc.uu.net (Peter da Silva) (12/20/89)
Suggested that a standard user interface is premature, and urged consideration of the lack of a standard programmer interface. The analogy I used was with the UNIX system calls and the C stdio library... In article <4301@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > I don't agree. First of all, there would have to be a standard > language. Why? Let's go back to my analogy... what difference does it make whether the system call looks like: nread = read(fd, buf, nbytes); CALL READ(FD, BUF, NBYTES, NREAD) CALL C_READ(FD, @BUF, NBYTES, @NREAD); (setq nread (read fd buf nbytes)) nread := cread(fd, buf, nbytes); The semantics are the same. Similarly, let's look at a hypothetical window call: Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); CALL ADDWM(WINDOW, 'Frobitz', 'Fooble', MENU) CALL W_ADDWINDOWMENU(WINDOW, @('Frobitz',0), @('Fooble'), @MENU); (setq menu (AddWindowMenu Window 'Frobitz 'Fooble)) menu := AddWindowMenu(Window, 'Frobitz', 'Fooble'); > C++ and Lisp would be a good choice for an object oriented > windowing system. I don't think tying windowing into any particular metaphor is a good idea. A program is more than a user interface with a bit of work going on behind it. The main purpose for most programs is what they do, not what they look like. > Does this solve your problem? Of course not. I would rather use an > object oriented (O-O) language to support an O-O window system. I'd rather use the best language for the job the program is intended to do. Not the best language for the user interface. That's just putting the cart before the horse. What if you're working in Prolog? Or APL? Or you're working for the DoD in ADA? Or adding a GUI to MicroEmacs? > I certainly would not want to wait three years for a standards > committee to define the stdio-windows library package. But you're willing to wait three years for a standards committee to define the user interface? > IMHO defining a standard binding is premature. People don't > even know what toolkit to use! Toolkit? As in X toolkit? My dear fellow. X is part of the problem. It's way too low level for something like this. > Standards are also restricting - they are great at telling people what > they cannot do. Defining a standard programming too soon is a disaster. No more than defining a standard UI. > in <7344@ficc.uu.net> Peter says: > >Personally, I think terminfo sucks. > Case in point. terminfo is a standard package for ASCII terminals. > It doesn't make it good. Termcap is a standard package for ascii terminals too. It's a hell of a lot smaller, cleaner, and (as I said in the message you so ruthlessly cribbed that from) better. Besides, Termcap and terminfo are both far below the level I'm talking about here. Curses is a closer metaphor. > Also - as any novice software engineer will tell you, the first step > in a project is the top level specifications. You DON'T write code > before you know what it is that you want the code to do. Yeh, but is the code supposed to put up pretty pictures or do real work? > This is the function of the Open Look style guide. The style of the UI shouldn't even be *in* the program. The details involved in OpenLook or Motif are way too low level. they belong in the UI handler (whether it be a server process, a PostScript program, a shared library, or even a statically linked library). > I think it is obvious that the top level specifications should be > done before any code is written. Yeh, but what should we be specifying? "I want a window big enough to hold the following objects: a text pane containing this text, and a selector for YES and NO. Tell me when someone selects YES or NO, and don't bug me otherwise", or "Draw a rectangle here, now put these characters in this font here, and then draw these rectangles... (lots deleted) now tell me when anyone clicks in my window. Oh, OK, erase this rectangle and redraw it here, and blit this rectangle up by the size of this font, put these characters here, and tell me what you want me to do next..." ? -- `-_-' 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/20/89)
In article <5728@ncar.ucar.edu>, thor@stout (Rich Neitzel) writes: >Sigh! I can't stand it any longer. This is a very bad analogy in my >opinion. Yes, I can drive any car car intended for the U.S. market, but >the level of commonality is no where near the level that as proposed by >the "one user interface claim". It is only an analogy. But there is some truth to it. The first time I started up X windows I could get it to do NOTHING. Zip. No menus. mouse clicks did nothing. I tried every combination I could think of, and then gave up. I am someone who has used several window systems. But I could not "drive" the system I installed. >All this talk about commonality of "look & feel" is simply an attempt to >evade the real issue in the design of user interfaces - does the >interface for THIS application adequate suit the conditions of use, >level of user skill and functionality required to perform the job? >Common user interfsces simply make the life of developer easier by >allowing one to put on any interface, cklaim that this is good because >it is "standard" and walk away. No thought or concern about reality required! Well - first of all - the person who benefits most from a common user interface is the user. I would love to have all of tools on all of the window systems I use have the same user interface. It is true that all standards have limitations. I have not found one that was perfect yet. But your statement can be argued. Since this discussion started with Open Look, I can say that Sun has done a lot to address the issue you mention. They have tried to provide a standard look and feel that is an improvement on what else is out there. Did you ask for a copy of the preliminary style guide? Do you have a copy of the current one? Did you send in your criticisms? Did it meet your requirements for a "real" application? How did Sun evade the real issue? -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
barnett@crdgw1.crd.ge.com (Bruce Barnett) (12/21/89)
In article <7363@ficc.uu.net>, peter@ficc (Peter da Silva) writes: >Suggested that a standard user interface is premature, and urged consideration >of the lack of a standard programmer interface. The analogy I used was >with the UNIX system calls and the C stdio library... >In article <4301@crdgw1.crd.ge.com> I wrote: >> I don't agree. First of all, there would have to be a standard >> language. >Why? Let's go back to my analogy... what difference does it make whether >the system call looks like: > > nread = read(fd, buf, nbytes); > CALL READ(FD, BUF, NBYTES, NREAD) > CALL C_READ(FD, @BUF, NBYTES, @NREAD); > (setq nread (read fd buf nbytes)) > nread := cread(fd, buf, nbytes); >The semantics are the same. Creating simple windows is not really an issue. As I mentioned, if your window system allows you to prototype a simple window tool in 30 minutes, you wouldn't need a standard library. If the results used a toolkit that was available to everyone - you would have portable code. Sun has donated XView to the world. There's one portable library. Does this solve your problem? If not, I'd like to understand why. I, you see, don't think a common library would solve the REAL problem. Portability is not easy in the X world. You must worry about fonts to use. If you had a very high resolution display, you couldn't use the same font as a 640*480 display. The xfig program is a program that needs completely different layouts for 640*480 vs. 1000*1000 displays. I tried it on an X terminal and the window was too big. I couldn't use it. With the flexibility of .XDefaults, this is even more complex. Let's say Joe Programmer decides to use XView. Jill Hacker decides to use the HP or Motif toolkit. And Bill Consumer ends up confused because he used both programs at the same time and the scrollbars are completely different. I would love to have a single scrollbar that is used in every tool I use. I would also love to have a perfect scrollbar. There's no such thing as perfection. Therefore we will see an evolution in scrollbars as the years go by. The biggest advantage of the Mac is that most programs have the same user interface. I am not saying the interface is good, just uniform. When a Mac user gets a new program, he/she doesn't even read the manual before trying it out. It is not necessary. This is a good thing. Unix needs the same benefit if it is to be the heir to the throne. One of the most important features of a window systems package is extensibility. If it cannot be extended - it will not be successfull. You said: > Personally, I think terminfo sucks. >Termcap is a standard package for ascii terminals too. It's a hell of >a lot smaller, cleaner, and (as I said in the message you so ruthlessly >cribbed that from) better. I was being brief, not ruthless. One of the reasons termcap is better than terminfo is its extensibility. I also was pointing out that standards are not necessarily useful. ESPECIALLY if they are too low a level. >Similarly, let's look at a hypothetical window call: > > Menu = AddWindowMenu(Window, "Frobitz", "Fooble"); > CALL ADDWM(WINDOW, 'Frobitz', 'Fooble', MENU) > CALL W_ADDWINDOWMENU(WINDOW, @('Frobitz',0), @('Fooble'), @MENU); > (setq menu (AddWindowMenu Window 'Frobitz 'Fooble)) > menu := AddWindowMenu(Window, 'Frobitz', 'Fooble'); > >> C++ and Lisp would be a good choice for an object oriented >> windowing system. > >I don't think tying windowing into any particular metaphor is a good idea. >A program is more than a user interface with a bit of work going on behind >it. The main purpose for most programs is what they do, not what they look >like. > >> Does this solve your problem? Of course not. I would rather use an >> object oriented (O-O) language to support an O-O window system. > >I'd rather use the best language for the job the program is intended to >do. Not the best language for the user interface. That's just putting the >cart before the horse. What if you're working in Prolog? Or APL? Or you're >working for the DoD in ADA? Or adding a GUI to MicroEmacs? I agree. Since I feel that a good window system should be extensible, how can this be done? One of the best methods is to use Object Oriented programming. You should be able to extend a scrollbar to improve on it. Example - you have an application with several windows with scrollbars. You want to redefine the scrollbar to pop up a menu and show you a special index into the window. In a few cases you may want it to be a list of C functions in a source file. So you would want to subclass the new scrollbar class and create several instances of it. Now suppose you wanted to add a new method to help you debug this extension. Or you want to change one of the methods to either create a hard copy of the menu in action, or perhaps a keep a histogram of the menus called. And you also want multiple inheritance. And of course you want to redefine/add these methods dynamically. My point is that this is difficult to do in Fortran, C or Pascal. Yet if you were limited to the C language, you would not be able to make use of the more powerful features that are really needed. 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. 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. I'm sorry for going on and on. I'll cut this short. > >Yeh, but what should we be specifying? > > "I want a window big enough to hold the following > objects: a text pane containing this text, and a > selector for YES and NO. Tell me when someone selects > YES or NO, and don't bug me otherwise", >or > "Draw a rectangle here, now put these characters in > this font here, and then draw these rectangles... > (lots deleted) now tell me when anyone clicks in my > window. Oh, OK, erase this rectangle and redraw it > here, and blit this rectangle up by the size of this > font, put these characters here, and tell me what > you want me to do next..." I guess I still don't follow your real complaint. If you want a portable program, use one of the toolkits. If you don't like the toolkit, extend it. If it can't be extended easily, pick a different toolkit. 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. One vendor has a portable window package. It runs on PC and Unix machines. In either case, solutions exist now. To use your example, you could use the technique in the sources of xfig? Xfig started on sunview and was ported to X not using XView. There are a few routines that provide a common interface to drawing text, bitmaps, and lines. The "portable library" is just a few lines long. Why not just make up your own little routines to draw vectors and text, and build up your own primitives? Use xfig as a start. I, personally, would prefer to have a toolkit that let's me define classes of objects to be drawn, moved, rescaled, selected, grouped, deleted, etc. I would like to sub-class these objects so that I can draw a new thing, like a shaded box, and insert this new thing into my menu, so I can draw it again as easily as I can draw a circle. I would also like to be able to edit, move, refresh. etc. the entire diagram with no network traffic. This way I could use it over a 1200 baud modem with reasonable results. But then, I would just start with Bernard Yves's Illustrator program for NeWS, because it does all that. (In 5000 lines of code! Xfig is 17,000 lines.) In conclusion, I think a standard library would limit creativity, and slow down evolution towards a decent user interface. I agree with Padlipsky: "Standards should be discovered, not decreed" -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
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
lerici@SUPER.ORG (Peter W. Brewer) (12/31/89)
>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. >`-_-' 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 Almost all of the things you say about X could also be said about UNIX and have thus I am confused by your signature quote. Could it be that Sun is still trying to make something as good as the Apollo Display Manager .. a network windowing system based on the client server model? I think some of the toolkits coming out for X have alot of promise.. they are also for the most part still basically public domain freeware. In terms of extensibility they all have their good and bad sides. If NeWS is to find some niche it would be better off not knocking X but joining with it and enhancing it. Xnews is a poor attempt at this.. I do not think all of that stuff belongs in the server. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ ||||||
peter@ficc.uu.net (Peter da Silva) (12/31/89)
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. <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
mlandau@bbn.com (Matt Landau) (12/31/89)
lerici@SUPER.ORG (Peter W. Brewer) writes: >Could it be that Sun is still >trying to make something as good as the Apollo Display Manager .. a network >windowing system based on the client server model? No, they've already made something *better* than either X11 or the Apollo Display Manager: a network window system based on the client/server model where the imaging model in the server is *useful*, and helps rather than hinders someone who wants to write an application that has non-trivial display requirements. The place where Sun botched it was in not doing a "sample implementation" of NeWS and making it publicly available in the same way that the "sample implementation" of X11 is freely available. If they had, X would have died off by now, because NeWS is simply a technically superior idea. For the life of me, I still can't understand how anyone involved in the early design phases of X11 thought that a resolution-dependent imaging model based on rectangular arrays of pixels was a good idea, when the groundwork had already been laid for using a page description langauge as the basis of the imaging model in other systems. Was no one familiar with the history of SunDEW, for example? >I think some of the >toolkits coming out for X have alot of promise.. they are also for the most >part still basically public domain freeware. Tell that to OSF -- Motif, which is (alas!) likely to become the dominant X11 toolkit, is considered proprietary software with source code license fees, royalty payments due by software vendors who ship Motif binaries, etc. That's an interesting contrast to Sun -- historically considered the "bad guys" of the window system world for not making NeWS free -- which has finally seen the light and made the XView toolkit freely available to anyone, for any purpose. >In terms of extensibility they all have their good and bad sides. The point is not about toolkits, although personally I don't find any of the existing toolkits terribly worthwhile from the point of view of extensibility. (Writing new widgets, for instance, is considerably more difficult than it needs to be. InterViews might be an exception to the rule that toolkits are hard to extend -- writing in C++ buys you a lot a priori -- but I haven't had a chance to work much with InterViews.) The real point is that X11 is fundamentally flawed by virtue of not providing extensible window *server*. There's no way for an application at runtime to change the characteristics of the server, add new facilities to it, etc. If you look even cursorily at what you can do by downloading PostScript code into the X11/NeWS server, and at the contortions you have to go through to achieve the same thing in X, it should be obvious why a runtime-extensible server is The Right Thing. No, Display PostScript doesn't count. It only allows you to image stuff, not to extend the input handling characteristics of the server the way you can in X11/NeWS. It's also by no means universal, and if you can't count on a facility being in the server, then it might as well not be there. The so-called "extensibility" of the X11 protocol also doesn't count. You have to recompile the server to make extensions. As a software vendor, I shouldn't have to be in the business of writing modified window servers in order to write the kind of applications I want to write. >If NeWS is to find some niche it would >be better off not knocking X but joining with it and enhancing it. Xnews is >a poor attempt at this.. I do not think all of that stuff belongs in the >server. I'd be interested in knowing exactly what you think is wrong with X11/NeWS. Personally, the idea of a single server based on a reasonable imaging model that interprets both X11 and NeWS protocol requests seems like the most elegant way to provide the X11 compatibility that the market demands without sacrificing the inherently superior characteristics of NeWS. (Don't get me wrong -- there are some things wrong with X11/NeWS. One is that it runs too slowly and uses too much memory, but that can be fixed if Sun gets on the ball technically. Another is that making "point" == "pixel" in NeWS PostScript was just stupid -- granted you can't discover automatically the resolution of your display device, since the hardware doesn't tell you, but you could at least provide command line flags or environment variables read by the server that would let the *user* tell you what the resolution is. Maybe in OpenWindows 1.1??) -- Matt Landau mlandau@bbn.com Diplomacy is the art of saying "nice doggy" until you can find a rock.
peter@ficc.uu.net (Peter da Silva) (12/31/89)
In article <8912302010.AA11723@super.super.org> lerici@SUPER.ORG (Peter W. Brewer) writes (and also sends in mail. I wish people would stop doing this... or at least *note* that they're mailing as well as posting a response!): > Almost all of the things you say about X could also be said about UNIX Not at all. The things that I particularly dislike about X are: It requires a huge runtime overhead linked in with each program. Complex policy is forced on the application programmer. A certain programming model is forced on the application programmer. It's very very large. None of these things are true of UNIX. The runtime for a small programming language (say, FORTH) under UNIX is under 1K. Most programs have no user interface policy at all. Almost none even have to parse filenames or scan directories. In fact, UNIX forces less policy on the program than anything I know: most systems at least expect a program to scan wildcards! UNIX has (and does) run languages and systems in every programming model you can think of... including communicating concurrent processes. And UNIX is small. It's run 8 users in 128 K words of RAM. The Cory 11/70 at Berkeley, running V7 and 2BSD, was usable with 35 users in 2 Meg of RAM. With 60 users it was unbearable but it kept going. These numbers are in line with the best proprietary systems of the time. Now it may be that Sun, AT&T, and Berkeley have forgotten their roots. But there's nothing inherent in UNIX that makes it a hog. And it scales very well. X scales not at all... it starts big. > If NeWS is to find some niche it would > be better off not knocking X but joining with it and enhancing it. I'm sorry, I really don't know how you can combine X and NeWS. They have completely different ideas of how the system works. X puts all this overhead in the client, where it gets duplicated zillions of times and gets copied over the network redundently again and again and again... NeWS puts the window system where it's needed... in the display system. > Xnews is a poor attempt at this.. How could it help but be? > I do not think all of that stuff belongs in the server. It's gotta be one plece or the other. At least in the server you only need one copy of it. And RAM's generally cheaper for the server. -- `-_-' 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
davidh@ic.Berkeley.EDU (David S. Harrison) (01/02/90)
In article <HNWF05ggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Not at all. The things that I particularly dislike about X are: > > It requires a huge runtime overhead linked in with each program. > Complex policy is forced on the application programmer. > A certain programming model is forced on the application programmer. > It's very very large. > >None of these things are true of UNIX. The runtime for a small programming >language (say, FORTH) under UNIX is under 1K. ... > I am afraid I disagree with the arguments expressed here. The problem truely lies in toolkits and policy. In order for memory savings to take place, programs *must agree* to use the same features. Otherwise, using the NeWS paradigm, each program will download its own features into the server and you will have a gigantic server where little or no sharing occurs. Furthermore, the problem is *identical* for both NeWS and X. Both systems provide fairly low-level user interface programming facilities. Both systems require higher level facilities in order to quickly build real-world user interfaces. The solution is to have programs agree on a toolkit. The memory savings will be the same under both systems: - Under NeWS, toolkit facilities will be downloaded to the server where possible and applications will link against a shared library for client side facilities. - Under X, applications will link against a shared library for most toolkit functionality and may use server extensions (if present). In both cases, applications will share the toolkit code. The sum of server size and client size should be roughly equivalent. My point is that there is nothing fundamental about NeWS that makes this problem any easier. Furthermore, in my opinion, there are some problems in the NeWS model that make it harder to develop a general purpose toolkit that meets the needs of a wide range of application developers. I have posted these problems before in this newsgroup so I won't repeat them here. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (01/02/90)
In article <F4W-V3ggpc2@ficc.uu.net>, 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 <barnett@crd.ge.com> uunet!crdgw1!barnett
barnett@crdgw1.crd.ge.com (Bruce Barnett) (01/02/90)
In article <13323@diamond.BBN.COM>, mlandau@bbn (Matt Landau) writes: >Was no one familiar >with the history of SunDEW, for example? Mesa, Cedar and Docs (1980) had an advanced image model four years before SunDEW. -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
sjs@spectral.ctt.bellcore.com (Stan Switzer) (01/02/90)
In article <F4W-V3ggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > If the UI is *that* integral to the program, then the UI or the program > needs some redesign. Here's the crux of the problem: if you want a responsive GRAPHICAL user interface, you'll have to write the UI portion of the application in a particular, probably event-driven, way. There just ain't no getting around it. At the same time, it might just be possible to write the UI portion of the program as a separate front-end program (as in bc/dc in UNIX). There was some discussion about a year ago on this very group about techniques for doing this in NeWS. > Yes, but it doesn't (back to my point) require the PROGRAM as a whole to > be written in an O-O language. In NeWS, you write your program any way you want to, but it is just plain silly not to use O-O techniques in the UI part (which can be almost entirely in the server). > 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). First, I don't know what you mean by "today's small computers." This has been discussed to death. Small is already quite large and it is getting larger. Second, NeWS has been ported to PC's and this too has already been discussed. Third, although NeWS is "proprietary," it is available for token licensing fees. And this seems prudent to me. Anyone who is really serious about porting NeWS to a new platform as a commercial venture can scrape up the capital to do it. It is less than a year's salary for a grunt worker. Contact Steven Messino (messino@Sun.com) for details. Educational licensing is quite reasonable as well. Finally, your Intel bashing is tiring. What IS your point anyway? > 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. OH! That's it. Well for heaven's sake, if you find STDWIN adequate for your purposes, then by all means use it. The rest of us have real work to do. Stan Switzer sjs@bellcore.com
peter@ficc.uu.net (Peter da Silva) (01/02/90)
> I am afraid I disagree with the arguments expressed here. The problem > truely lies in toolkits and policy. In order for memory savings to > take place, programs *must agree* to use the same features. This is a political problem, primarily. You have to convince people that it's not a good idea to create new *types* of gadgets. However, there's no point in trying to make them all look alike. > Otherwise, > using the NeWS paradigm, each program will download its own features > into the server and you will have a gigantic server where little or > no sharing occurs. Perhaps. Does this happen in practice, though? I think we can all agree that it does happen in X. And X doesn't even have the option of sharing resources when they're desirable... sure, you can use shared libraries, but that doesn't help when you're dealing with multiple machines. This is a networked window system, after all. And X doesn't leave a channel for the user to install enhanced gadgets, except by at least relinking all their programs. -- `-_-' 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
bob@MorningStar.Com (Bob Sutterfield) (01/02/90)
(Bob starts the new year by diving into a flamefest :-)
In article <13323@diamond.BBN.COM> mlandau@bbn.com (Matt Landau) writes:
The place where Sun botched it was in not doing a "sample
implementation" of NeWS and making it publicly available in the
same way that the "sample implementation" of X11 is freely
available.
Right! And it's surprising that their marketeers didn't see that.
Enough people at the time were offering such suggestions as free
advice, one wonders why Sun didn't listen. It's too late now.
If they had, X would have died off by now, because NeWS is simply a
technically superior idea.
X may not have died off yet. It has become a rallying point for other
companies' marketeers who noticed that Sun was getting its name on too
many innovations that were being adopted as de-facto standards. The
widespread adoption of X was, IMHO, largely in response to the
announcement of NeWS. And since that time we've seen corresponding
marketing department-based battles over the underlying operating
systems (Why do you think OSF exists? Entirely for marketing and
political reasons, the technical concerns included as an afterthought.
But I digress still more...).
For the life of me, I still can't understand how anyone involved in
the early design phases of X11...
My understanding is that X grew from W, the window system atop the V
kernel from Stanford.
...Was no one familiar with the history of SunDEW, for example?
V happened before SunDEW, and X just carried much of W's basic
technology along. An interesting semi-early (1985) reference is
"Methodology of Window Management", Aho, Hopgood, and Ullman;
Springer-Verlag. Sorry, my copy is at home, else I'd have the ISBN
handy to cite. The conference of which the book contains the
proceedings discusses various historic approaches to windows and user
interfaces on various underlying software architectures (Cedar, UNIX,
Perqs, etc.) Well worth reading.
No, Display PostScript doesn't count.
Right! It's another marketing-originated red herring. It's useful
for those without a sufficient imaging model who realized later (as
PostScript printers became universal) that they needed to invoke the
magic P-word for "compatibility".
The so-called "extensibility" of the X11 protocol also doesn't
count.
It might help to have a sample implementation of a server that would
be protocol-extensible on the fly, at runtime.
In the mean time, X runs on everything and there are lots and lots of
people writing free software for it. I use X mainly for those
reasons, though my aesthetic sensibilities cry out for better.peter@ficc.uu.net (Peter da Silva) (01/02/90)
> 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. <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
davidh@dent.Berkeley.EDU (David S. Harrison) (01/03/90)
In article <18YA-8xds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > Perhaps. Does this happen in practice, though? I think we can all agree > that it does happen in X. And X doesn't even have the option of sharing > resources when they're desirable... sure, you can use shared libraries, > but that doesn't help when you're dealing with multiple machines. This > is a networked window system, after all. > > And X doesn't leave a channel for the user to install enhanced gadgets, > except by at least relinking all their programs. Most of the NeWS applications I have seen posted here download their own UI code into the server without even expecting any other application will use these features. I remain adamant that the problem can only be solved by the adoption of a common toolkit that all application writers can link against. Work in this area is moving much faster under X than under NeWS. In any case, I expect the underlying system will not be very important once a dominant toolkit (like Motif) becomes commonplace. It is true that NeWS has a slight memory advantage if a user uses several applications each running on a different machine. However, due to the use of shared libraries, the savings is proportional to the number of machines not the number of applications and is thus reasonably small. With an appropriate implementation of shared libraries, it may even be possible to install enhanced gadgets without relinking (since some runtime binding is required to implement shared libraries). All in all, the differences are minor. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)
mlandau@bbn.com (Matt Landau) (01/03/90)
bob@MorningStar.Com (Bob Sutterfield) writes: >(Bob starts the new year by diving into a flamefest :-) (Bob starts the new year by saying some remarkably reasonable things :-) > The place where Sun botched it was in not doing a "sample > implementation" of NeWS and making it publicly available >Right! And it's surprising that their marketeers didn't see that. >Enough people at the time were offering such suggestions as free >advice, one wonders why Sun didn't listen. It's too late now. Maybe not. I recently learned first-hand the degree to which customer opinion really can make a difference in Sun corporate policy. It's a little-known fact that until quite recently (the last couple of weeks), Sun had OpenWindows on a tight allocation policy, which is why people who'd ordered it months ago were still waiting for their tapes. At the recent Sun User Group conference, several of us got wind of this fact, and we were rather ... ahem ... "outspoken" ... in our opinion that this was a critical tactical mistake, and tantamount to suicide for both NeWS and Open Look. Basically, lots of people complained real loudly about this brain-dead policy (I spent about 45 minutes talking to Carl Wolf in the gripe booth, and another 30 talking to Scott McNealy; other people raised the issue in the public question-and-answer sessions and the executive roundtable.) The result was that, according to a piece of mail I got from a friend inside Sun, OpenWindows has been taken off allocation and will ship to all customers who order it. What's the point? The point is that if enough people make enough noise, things can change. Now ask yourself what might happen if Sun were to donate the source to X11/NeWS to the MIT X Consortium, just for the sake of promoting it as a superior technology that wasn't under Sun's complete control anymore... After all, Sun's done something similar with control of the Sparc processor architecture... And AT&T is doing something vaguely similar with SvR4... So ask yourself what might happen if X11R5 (or X12 or something) were based on the merged NeWS/X server... Then ask yourself how we might make this happen...
peter@ficc.uu.net (Peter da Silva) (01/03/90)
> Most of the NeWS applications I have seen posted here download their > own UI code into the server without even expecting any other application > will use these features. Well, except for the stuff that is designed to globally modify the environment, like pie menus. Or I think it was Bruce who brought up rounded windows. And NeWS has another big advantage... if you put enough of the UI in the server, you don't have to munge the rest of the program into the X event loop/callback mould. > I remain adamant that the problem can only > be solved by the adoption of a common toolkit that all application > writers can link against. Yes. yes yes. In fact I think that's pretty much what I've been saying. Or at least that's what I think I've been saying. Oh, you get the idea. > Work in this area is moving much faster > under X than under NeWS. In any case, I expect the underlying system > will not be very important once a dominant toolkit (like Motif) becomes > commonplace. Is Motif a toolkit or an interface? I got the impression that it's just a style guide like OpenLook. A dominant standard toolkit is something I'd like to see very much... but should it be so tightly tied to X? In programming in X, the UI tends to dominate the app. This tends to lead to unfortunate consequences. Like, say you want a program to go away for a while and do some work. Under X you lose the UI... and you can't even put up an "I'm busy" sign because it won't get displayed until you return to the event loop. -- `-_-' 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
graham@fuel.dec.com (kris graham) (01/05/90)
In article <13324@granite.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > Now ask yourself what might happen if Sun were to donate the source to > X11/NeWS to the MIT X Consortium, just for the sake of promoting it as a > superior technology that wasn't under Sun's complete control anymore... > After all, Sun's done something similar with control of the Sparc processor > architecture... And AT&T is doing something vaguely similar with SvR4... > So ask yourself what might happen if X11R5 (or X12 or something) were > based on the merged NeWS/X server... Then ask yourself how we might make > this happen... I have heard a lot about the so-called "Technical Superiority" of NeWS. Anybody care to educate us non-believers of this claim. I have never thought of Postscript as a friendly language to program in.....or love a windowing system that makes the implementation of a print screen facility more tedious than necessary ; BTW: On a more cynical note, we all know the outcome of the "SPARC versus XXX" 'technical superiority" battle ;-) One of my co-workers, Larry Timmins, has been involved in multiple ports of applications originally done with Sun's toolkits. On average, for every six months (calendar time) that the customer/software house put into the project, only one month was needed with DECwindows' XUI toolkit. Using the Intrinsics -based toolkit reduces the network requests and ultimately has proven itself over and over. Regarding the donation of X11/NeWS, fine -- put it in the contrib like others have. However, when OSF went with the XUI toolkit, it was a fully tested production -quality toolkit at over 300 sites. What is needed is solid incremental contributions and not yet another toolkit, approach, etc. Christopher Graham Digital Equipment Corp Ultrix Resource Center New York City Internet: graham@fuel.enet.dec.com UUCP: ...!decwrl!fuel.enet.dec.com!graham I speak as an individual, not representing any organisation or company.
lerici@SUPER.ORG (Peter W. Brewer) (01/05/90)
I'm not sure that X is so fixed in concrete that some of the things you find bothersome could not change. I find InterViews almost equivalent to PostScript in terms of 'imaging power' and yet flexible enough to do low level stuff.. and there is no interpreter nor the restrictions of a 'page description' paradigm. I like the look and feel of Motif more than OpenLook as a 'style guide', but I think in terms of functionality InterViews has them beat.. particularly with their new Unidraw graphical object/'widget' editor. I have yet to see anything like this come from NeWS. I see NeXT with their NeXTStep and Display Postscript as being a more serious challenge to X and all other window systems than NeWS. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ ||||||
don@CS.UMD.EDU (Don Hopkins) (01/05/90)
Date: Thu, 4 Jan 90 14:39:38 -0500 From: Peter W. Brewer <lerici@super.org> I'm not sure that X is so fixed in concrete that some of the things you find bothersome could not change. I find InterViews almost equivalent to PostScript in terms of 'imaging power' and yet flexible enough to do low level stuff.. and there is no interpreter nor the restrictions of a 'page description' paradigm. I haven't used InterViews, so I'm not familiar with its imaging model and flexability. I don't know what you mean by "page description' paradigm, would you please explain? Does it have anything to do with device independance, printer compatibility, etc? I see having an interpreter as an advantage! I think WINTERP is an excellent idea, and I'd love to have a version of WINTERP with an interface to the NeWS toolkit. Extensibility is as useful on the client side as it is on the server side! What NeWS really needs is a way to dynamically link object files containing compiled primatives into the server at run time. (There was an *extremely* undocumented primative for just that purpose called "dynoload" in a beta version of NeWS 1.1 once, but I haven't seen it since. It's certainly possible, just not portable. [I guess we should just wait for PCR...]) I like the look and feel of Motif more than OpenLook as a 'style guide', but I think in terms of functionality InterViews has them beat.. particularly with their new Unidraw graphical object/'widget' editor. I have yet to see anything like this come from NeWS. I see NeXT with their NeXTStep and Display Postscript as being a more serious challenge to X and all other window systems than NeWS. Peter Brewer |||| ||||| ||||||||| |||||| //|||||\ |||||| lerici@super.org || ||__ || || || || || THE Supercomputing || || ||^^^^^^\\ || || || Research Center ~~~ |||||||| ||||| || || ||||| \\|||||/ |||||| Have you tried GoodNeWS, by Arthur van Hoff of Turing Institute? It's a window system built on top of NeWS, that includes a very nice PostScript drawing editor (and lots of other useful stuff like a LaTeX previewer that lets you place your GoodNeWS drawings in your documents.) *AND IT'S ALL FREE!!!* (available via anonymous ftp from tumtum.cs.umd.edu) Agreed, NeXTStep and Display PostScript are serious challenges to a lot of people, places, and things. (It doesn't hurt having H. Ross Perot fighting for your cause.) IMOH, it remains to be seen how flexable and easy to use the NeXTStep window system is. I had a wonderful argument with Jobs at EduCom about it, and he claimed they had tried all kinds of different user interface techniques and done all sorts of usability studies that showed that NeXTStep was incredibly easy to use. I'd like it if they'd publish those usability studies, and included the source to the window system in case I didn't agree with them, since I still haven't figured out a way to interact with a window that's partially covered up by another window, or how to type into a window without clicking on it and bringing it to the top. Enforced click-to-type is a throwback to the MacIntosh. Make it an option or make it so I can fix the problem! The interface builder looks very nice, but I don't know the merits of the toolkit it's built on top of. Ohio State did a study showing the interface builder was indeed easy to use. But how easy is it to write an application such that you can build an interface to it? And how easy is it to modify and implement new parts of the toolkit and integrate them with pre-existing applications? I talked with one of the NeXT window techies about implenting pie menus on NeXTStep, gave him some papers on the subject, and encouraged him to do it. I will be impressed if somebody can implement pie menus in NeXTStep (with or without the round windows) as seamlessly as they dropped into NeWS (so every application gets pie menus, without modification). -Don
barnett@grymoire.crd.ge.com (Bruce Barnett) (01/06/90)
In article <1558@riscy.dec.com> graham@fuel.dec.com (kris graham) writes: |I have heard a lot about the so-called "Technical Superiority" of NeWS. |Anybody care to educate us non-believers of this claim. I have never |thought of Postscript as a friendly language to program in.....or love a |windowing system that makes the implementation of a print screen facility |more tedious than necessary ; Well, PostScript is not a "high level" language, designed to make the programmer's life as easy as possible. Instead, is is a language designed for quickly generating graphical images. There is very little syntactic "sugar" that has been added. So the programmer's job is harder, but the execution is faster because the parsing is simpler. But some of the advantages of NeWS as I see are: 1) the user's program can execute in the server or the client. Or both. One example was mentioned in the Sun Technology article discussing the IBM 3270 emulator with graphic support. Who keeps track of the text and graphics in the window? The implementation desided that the text would be maintained in the client, while the server maintains the graphics. One benefit from this model was that it became possible to redisplay the graphics, changing the position, scaling factor, zooming in our out, changing the colors, etc - WHILE the IBM was still sending new graphics to the server. Another example is all of the NeWS programs that have no client code - the entire application resides in the server. You could have an illustration program work over a low speed modem. You could down load the program to the server, and transfer the diagram back when you are done. but inbetween there would be no network traffic! 2) The Graphics image is PostScript, of course. This gives you automatic scaling and rotation. Also - text is now treated the same as graphics. A text program can be a WYSIWYG editor with little effort. 3) Flexibility - Because the entire window system is based on the PostScript model, there are very few limitations. You can make a new shape, and use it for a cursor, character, icon, button, menu, or window. The distinction between these window concepts is very fuzzy. So you can have "icons" that contain "icons", windows containing windows. The "winwin" program is a simple ROOMS-type extension to the server, allowing you to organize a group of windows and icons into super windows, allowing you to switch between one set of tools and another. A "character" could really be a button or a window. This simplifies a HyperText system, for instance. Don Hopkins has done a lot of "blurring" in this direction. :-) His Pie Menus and HyperText system, for instance. He published some code in this newsgroup that transformed the cursor into a pulsating rainbow. As I also mentioned, you can draw a new thing on the screen, and use it to modify/redefine an existing button, menu choice, window shape, etc. Don also wrote soft menus - some code downloaded to the server that lets you cut/modify and paste menus from one aplication to another. Another example mentioned here was the integration of dozens of workstations to a large "Strategic Command Display". Each user could move the mouse up to the top of his/her workstation, and it would appear on the large display on the far wall, where it could be used to manipulate the information shown to everyone. Also - because of the syntax of PostScript, you can redefine the "reserved words" - well, actually, there are no reserved words in PostScript. You can redefine the entire language on the fly, changing constants into procedures. As an example, I changed the FillColor constant (which colors the background of the window) into a procedure. I made a table that listed machine names and colors. The procedure got the host name the client was running on, and returned a different color for each machine. This let me have several windows on the screen, and all of the icons and windows with a pale green were remote programs on the same system. It only took 10 lines of code downloaded into the server. Note that all of the above DID NOT require any modification of the server. It was done with dynamic extensions. 4) The window system is object oriented. The windows/ icons, buttons are all different objects in the object hierarchy (at least with the tNt toolkit). Subclassing icons and windows is easy. You could subclass every program and define new methods that apply to them. Send them a "refresh", "update" "Print HardCopy", "Return to original position", "revert to original defaults", "save to file", etc. method, much like we send kill signals. And you can add new methods on the fly, like a "send contents to a Laser Printer" or "start collecting a histogram" method to all windows of a certain class. I must admit the ways people have extended X is amazing. There must be a dozen new techniques to add the sort of feature to X that NeWS had all along. (Of course NeWS has evolved too - due to the influence of X). |One of my co-workers, Larry Timmins, has been involved in multiple ports |of applications originally done with Sun's toolkits. On average, for every six |months (calendar time) that the customer/software house put into the project, |only one month was needed with DECwindows' XUI toolkit. Using the Intrinsics |-based toolkit reduces the network requests and ultimately has proven itself |over and over. I don't understand. First of all, Sun has several toolkits. The older applications (SunView) did not have any networking support. I don't see how the number of network requests can be reduced from zero. The NeWS server allows the entire application to reside in the server. If there are a large number of network requests, the code can be re-written to eliminate this. The only other package I know about is XView, which is very new. It supports the older SunView model, in a manner that is easy to convert from SunView to X, but may not be tuned properly. There is a new document that tells people how to convert the old PixWin code to the new Xlib code, making better use of the native technology, instead of using code who's function is backwards compatability. I would like to hear more about this "reduction in network requests", because the argument doesn't ring true. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett