Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!crdgw1!crdgw1.ge.com!barnett From: barnett@crdgw1.crd.ge.com (Bruce Barnett) Newsgroups: comp.windows.news Subject: Re: Is SUN a "PURE PLAYER" in window systems - SunView or OpenWindows??? Message-ID: <4318@crdgw1.crd.ge.com> Date: 20 Dec 89 19:58:12 GMT References: <8912162135.AA03025@iris.rand.org> <4290@crdgw1.crd.ge.com> <7352@ficc.uu.net> <4301@crdgw1.crd.ge.com> <7363@ficc.uu.net> Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.crd.ge.com (Bruce Barnett) Organization: GE Corp. R & D, Schenectady, NY Lines: 189 In-reply-to: peter@ficc.uu.net (Peter da Silva) 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 uunet!crdgw1!barnett