msc@ramoth.sgi.COM.UUCP (06/04/87)
> I've never seen NeWS in action, unfortunately.] If you're ever in this area I'll be happy to give you a demo. In NeWS the semantics of overlay canvases are identical to that of any other canvas. The only restriction is that it can't be reshaped separately from its parent. > Wrong, at least according to Revision A of 29 March 1987 of > the NeWS Manual (copyright 1987 by Sun Microsystems). I quote > "Because of the way that overlays are implemented on some > displays, there will be performance problems if too many things > are written into the overlay. They are intended to be used for > animated objects like rubber band lines and bounding boxes." etc. This paragraph refers specifically to the implementation. The performance problem in this implementation is due to the overlay canvas being "taken down" every time the cursor is moved. This is necessary due to the software cursor on the Sun and is done using the display list I mentioned in my last message. Again these are weaknesses in the implementation not in the model. > "The current color is usually ignored when drawing in > overlays. They will generally be done in black. This weakness > in the specification of overlays is an explicit feature: it's > there to allow overlays to be implemented using a variety of > tricks on different types of hardware." Yes this is indeed to allow overlays to be implementated using XOR or a single overlay plane. > I don't see any mention about reshaping. There isn't. I discovered this while putting the menus in the overlays. In the very early version of NeWS that I first acquired reshaping overlays would crash the server. In the current Release 1.0 (pre-release) it is ignored. > How do you put up a paint palette > menu? Full color menus of course won't work in the overlay planes. However it is easy to modify the postscript code that implements the menu package so that it will paint full color menus in the image planes. My preferred paint palette is the whole screen anyway. I wouldn't use a menu. I'd just let you pick any color on the screen. > Yes. Of course, it can be captured within a library so that > application writers don't have to think about it. If there is Except for remote clients compiled with someone else's library. > There are > those already hacking overlays, by treating them as independent > "screens" with particular "known" (a priori, which is the > difficult part to overcome) geometry and visual characteristics > with respect to the "normal" screens. The restriction of overlays to black and white is an attempt to encapsulate some of these visual characteristics. I agree that such encapsulation is difficult and think the overlay canvas is an excellent start. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/05/87)
Again these are weaknesses in the implementation not in the model.
I guess I don't see that much of a distinction. Unless you somehow
think the implementation will get wonderfully better (without the
hardware changing), the fact seems to remain that a) an application
had better not depend on overlays for much and b) an application
doesn't seem to have any facilities for finding out what properties
overlays really have.
My preferred paint palette is the whole screen anyway. I wouldn't use
a menu. I'd just let you pick any color on the screen.
User-interface religion as a justification for not providing mechanism ...
Not to belabor this discussion, but somehow I doubt your screen starts off
with 2^24 colors already on it from which to "pick".msc@ramoth.sgi.COM (Mark Callow) (06/06/87)
Again these are weaknesses in the implementation not in the model. > I guess I don't see that much of a distinction. Unless you somehow The essential point is that weaknesses in the implementation of an idea are not a good reason to throw out the idea itself. My preferred paint palette is the whole screen anyway. I wouldn't use a menu. I'd just let you pick any color on the screen. > User-interface religion as a justification for not providing > mechanism ... That's a cheap shot made possible by using a quote in isolation. In the sentence before this I described a way to provide full color menus. I was merely stating my preference. I would never let my preferences be a justification for not providing mechanism. > Not to belabor this discussion, but somehow I doubt your screen > starts off with 2^24 colors already on it from which to "pick". Having 2^24 colors on a menu would be totally impractical even if it were possible (there aren't enough pixels on the screen to display all those colors at once). However your real question here, "how do you get colors if you don't have much on your screen", is a good one. The answer is a simple tool to display the color map. Let's continues any further discussion privately. This debate has already degenerated too far toward a childish "yes it is, no it isn't" style. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."