3 ms·

Apples and Oranges. Postscript itself includes the code for the primitives used in xeyes, whereas the C code implements them first. Take away that code and it

Apples and Oranges. Postscript itself includes the code for the primitives used in xeyes, whereas the C code implements them first. Take away that code and it is much more illuminating.

DonHopkins 8y ago
Are you saying that HTML Canvas should not have a method to draw circles because you can implement a circle drawing algorithm in JavaScript? What is your point? That it's a liability that PostScript has a far superior, more powerful, scalable, device independent, future proof, and vastly more convenient and easier to use and understand imaging model than X11? And by the way, NeWS eyes came first: "xeyes" was a lower quality knock-off, not the original. The first version of "xeyes" actually used a rectangular window, which kind of missed the whole point, until somebody added hundreds of lines of extremely complex code to implement the SHAPE extension. I linked to the source above: download and read it if you don't believe me. NeWS lets you shape a round (or any shape) window the exact same way you draw the same shape. See how pizzatool shapes the spinning full or half circle pizza window floating inside a rectangular frame, so you can easily move and resize it: % Reshape the parent popup pizza window, % to reflect a change in the pizza's shape. % In all truth, the pizza canvas is rectangular! % It gets its round (or semi-circular) shape % from the shape of its parent canvas, % which is a hollow rectangular popup window frame % (just the window borders), % with a discontiguous pie floating in the center. % /ReshapeParent { % - => - gsave Parent setcanvas /bbox PreviewWindow send /reshape PreviewWindow send grestore } def % The popup pizza window path includes the window borders and the % round (or semi-circular) pie floating in the middle, but excludes % everything between. % /path { % x y w h => - matrix currentmatrix 5 1 roll % mat x y w h /minsize self send xymax 4 2 roll translate % mat w h 0 0 3 index 3 index rectpath WInset SInset translate % mat w h EInset WInset add % mat w h ewinsets NInset SInset add % mat w h ewinsets nsinsets xysub % mat insidew insideh 0 0 3 index 3 index rectpath 2 div exch 2 div exch % mat centerx centery 2 copy translate min dup neg scale % mat { % send to Center client (the Pizza): /radiusscale self send 0 moveto 0 0 /radiusscale self send 0 360 /fraction self send mul arc closepath } % mat {msg} /Center /client self send % ... client true | false /WhatPizza? assert % mat {msg} client send % mat setmatrix % } def % Reshape the window canvas with the even/odd rule. % /reshape { % x y w h => - /invalidate self send gsave 4 2 roll translate % w h 0 0 4 2 roll % 0 0 w h /path self send % self eoreshapecanvas grestore } def So it looks like this: https://donhopkins.com/home/catalog/images/pizzatool.gif https://donhopkins.com/home/catalog/images/pizzatool.gif But with X-Windows you have to bend over backwards manipulating pixmaps or lists of rectangles, so the window shaping code is completely different and much more complex than the drawing code. Case in point: take a look at the "ShapePieMenu" function in the Tk pie menus I implemented for X11/TCL/Tk SimCity, for another example of how much of a pain in the ass it is to shape a window in X11. It has to first get the display and query to make sure the extension is supported, then if it is, make the window exist, get the window id, make a pixmap, make a graphics context, set the foreground color, erase the background, set the foreground color, fill a bunch of rectangles, free the graphics context, and call XShapeCombineMask. And that's only shaping the window to a simple list of few rectangles for all the labels, not a circle, which would have been MUCH harder: https://github.com/SimHacker/micropolis/blob/master/micropolis-activity/src/sim/w_piem.c#L2305 https://github.com/SimHacker/micropolis/blob/master/micropol... So funny that you'd compare drawing circles in X11 -vs- PostScript. Have you actually tried to draw a circle with either API yourself -- let alone used the X11 SHAPE extension to make a round window? Here's an excerpt from the X-Windows Disaster which addresses that very topic -- specifically "in the case of arcs": https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Myth: X is “Device Independent” X is extremely device dependent because all X graphics are specified in pixel coordinates. graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don’t mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio. A task as simple as filing and stroking shapes is quite complicated because of X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus pixels” when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that “in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion).” This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can’t even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
- gilbetron 8y ago
  I created a new language called zis, which has a function named "doXeyes()". I can do xeyes in literally one line of code. It destroys postscript with it's amazing simplicity. Sorry for the snarkiness, but that's my point.
  - infinite8s 8y ago
    Nice way to completely miss Don's point. His point is that postscript provides all the necessary primitives to draw in 2D, consistently at every level of the stack. X-Windows is a continuation of the 'worse is better' NJ school of software design.
  - DonHopkins 8y ago
    Snarkyness? What snarkyness? I don't understand what you mean. So I'd appreciate it if you'd explain what your point is more clearly, by directly addressing the questions I asked. Please be kind enough to link to the source code of the language "zis" that you wrote, just like I linked to the source code that I and others wrote to illustrate my point. I'd like to see the actual code you wrote, so I don't miss your point, and can see that you're arguing in good faith. Thank you, kind sir or ma'am! So what else is your language "zis" good for? Is it fully general purpose, easily editable at runtime, graphically skinnable with a build-in drawing editor, and dynamically scriptable and extensible by normal users, like HyperCard and HyperLook and Smalltalk? Do you think Alan Kay would describe "zis" as the "right way to go" like he described NeWS, and what other end-user problems does it solve, in the sense that he thinks HyperCard is brilliant and that Smalltalk pioneered? Is "zis" as "finished and smoothed and documented beautifully" as Alan Kay describes HyperCard? Have you developed and shipped any commercial products or free software with your language, like SVR4 or SimCity, that I can see and run for myself, so I can be confident you're not just making stuff up or wildly exaggerating, and that it works as you advertise? And have you written any books or documentation or articles or research papers about it that I can read to learn more about it? Or at least a screen snapshot, please? What are the URLs? Have you finished reading the X-Windows xeyes source code that I referred you to? Did you simply copy that code somebody else wrote into "zis" verbatim, or did you actually write your own original code? How is it licensed, and where has it been distributed: is it open source or not, and where's the repo? Now that you have presumably used the X-Windows SHAPES extension API first hand yourself, please share your experience and tell me what you think of it: do you think that it is well designed and easy to use or not? What changes or improvements would you suggest? Did you run into any of its limitations, or notice any unnecessary complexity, or ICCCM window manager incompatibilities? How well does your language "zis" support the SHAPES extension and ICCCM protocol, or improve upon them, and what else is it good for than xeyes? Finally, does "zis" support dragging and dropping eyes into each other, nesting their windows into an arbitrarily deep hierarchy, like my NeWS eyes did 27 years ago, and what ICCCM window managers support that feature, or did you have to write your own window manager or X extension to support that feature? Thanks for taking all this time and effort to design and write and share all that code, and to support and clarify your fascinating arguments. I'm looking forward to seeing your code and your answers to my questions.

Apples and Oranges. Postscript itself includes the code for the primitives used in xeyes, whereas the C code implements them first. Take away that code and it is much more illuminating.

DonHopkins 8y ago

Are you saying that HTML Canvas should not have a method to draw circles because you can implement a circle drawing algorithm in JavaScript? What is your point? That it's a liability that PostScript has a far superior, more powerful, scalable, device independent, future proof, and vastly more convenient and easier to use and understand imaging model than X11? And by the way, NeWS eyes came first: "xeyes" was a lower quality knock-off, not the original. The first version of "xeyes" actually used a rectangular window, which kind of missed the whole point, until somebody added hundreds of lines of extremely complex code to implement the SHAPE extension. I linked to the source above: download and read it if you don't believe me. NeWS lets you shape a round (or any shape) window the exact same way you draw the same shape. See how pizzatool shapes the spinning full or half circle pizza window floating inside a rectangular frame, so you can easily move and resize it: % Reshape the parent popup pizza window, % to reflect a change in the pizza's shape. % In all truth, the pizza canvas is rectangular! % It gets its round (or semi-circular) shape % from the shape of its parent canvas, % which is a hollow rectangular popup window frame % (just the window borders), % with a discontiguous pie floating in the center. % /ReshapeParent { % - => - gsave Parent setcanvas /bbox PreviewWindow send /reshape PreviewWindow send grestore } def % The popup pizza window path includes the window borders and the % round (or semi-circular) pie floating in the middle, but excludes % everything between. % /path { % x y w h => - matrix currentmatrix 5 1 roll % mat x y w h /minsize self send xymax 4 2 roll translate % mat w h 0 0 3 index 3 index rectpath WInset SInset translate % mat w h EInset WInset add % mat w h ewinsets NInset SInset add % mat w h ewinsets nsinsets xysub % mat insidew insideh 0 0 3 index 3 index rectpath 2 div exch 2 div exch % mat centerx centery 2 copy translate min dup neg scale % mat { % send to Center client (the Pizza): /radiusscale self send 0 moveto 0 0 /radiusscale self send 0 360 /fraction self send mul arc closepath } % mat {msg} /Center /client self send % ... client true | false /WhatPizza? assert % mat {msg} client send % mat setmatrix % } def % Reshape the window canvas with the even/odd rule. % /reshape { % x y w h => - /invalidate self send gsave 4 2 roll translate % w h 0 0 4 2 roll % 0 0 w h /path self send % self eoreshapecanvas grestore } def So it looks like this: https://donhopkins.com/home/catalog/images/pizzatool.gif https://donhopkins.com/home/catalog/images/pizzatool.gif But with X-Windows you have to bend over backwards manipulating pixmaps or lists of rectangles, so the window shaping code is completely different and much more complex than the drawing code. Case in point: take a look at the "ShapePieMenu" function in the Tk pie menus I implemented for X11/TCL/Tk SimCity, for another example of how much of a pain in the ass it is to shape a window in X11. It has to first get the display and query to make sure the extension is supported, then if it is, make the window exist, get the window id, make a pixmap, make a graphics context, set the foreground color, erase the background, set the foreground color, fill a bunch of rectangles, free the graphics context, and call XShapeCombineMask. And that's only shaping the window to a simple list of few rectangles for all the labels, not a circle, which would have been MUCH harder: https://github.com/SimHacker/micropolis/blob/master/micropolis-activity/src/sim/w_piem.c#L2305 https://github.com/SimHacker/micropolis/blob/master/micropol... So funny that you'd compare drawing circles in X11 -vs- PostScript. Have you actually tried to draw a circle with either API yourself -- let alone used the X11 SHAPE extension to make a round window? Here's an excerpt from the X-Windows Disaster which addresses that very topic -- specifically "in the case of arcs": https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... Myth: X is “Device Independent” X is extremely device dependent because all X graphics are specified in pixel coordinates. graphics drawn on different resolution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens even have square pixels: unless you don’t mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio. A task as simple as filing and stroking shapes is quite complicated because of X’s bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra “bonus pixels” when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that “in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion).” This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can’t even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio.

gilbetron 8y ago
I created a new language called zis, which has a function named "doXeyes()". I can do xeyes in literally one line of code. It destroys postscript with it's amazing simplicity. Sorry for the snarkiness, but that's my point.
- infinite8s 8y ago
  Nice way to completely miss Don's point. His point is that postscript provides all the necessary primitives to draw in 2D, consistently at every level of the stack. X-Windows is a continuation of the 'worse is better' NJ school of software design.
- DonHopkins 8y ago
  Snarkyness? What snarkyness? I don't understand what you mean. So I'd appreciate it if you'd explain what your point is more clearly, by directly addressing the questions I asked. Please be kind enough to link to the source code of the language "zis" that you wrote, just like I linked to the source code that I and others wrote to illustrate my point. I'd like to see the actual code you wrote, so I don't miss your point, and can see that you're arguing in good faith. Thank you, kind sir or ma'am! So what else is your language "zis" good for? Is it fully general purpose, easily editable at runtime, graphically skinnable with a build-in drawing editor, and dynamically scriptable and extensible by normal users, like HyperCard and HyperLook and Smalltalk? Do you think Alan Kay would describe "zis" as the "right way to go" like he described NeWS, and what other end-user problems does it solve, in the sense that he thinks HyperCard is brilliant and that Smalltalk pioneered? Is "zis" as "finished and smoothed and documented beautifully" as Alan Kay describes HyperCard? Have you developed and shipped any commercial products or free software with your language, like SVR4 or SimCity, that I can see and run for myself, so I can be confident you're not just making stuff up or wildly exaggerating, and that it works as you advertise? And have you written any books or documentation or articles or research papers about it that I can read to learn more about it? Or at least a screen snapshot, please? What are the URLs? Have you finished reading the X-Windows xeyes source code that I referred you to? Did you simply copy that code somebody else wrote into "zis" verbatim, or did you actually write your own original code? How is it licensed, and where has it been distributed: is it open source or not, and where's the repo? Now that you have presumably used the X-Windows SHAPES extension API first hand yourself, please share your experience and tell me what you think of it: do you think that it is well designed and easy to use or not? What changes or improvements would you suggest? Did you run into any of its limitations, or notice any unnecessary complexity, or ICCCM window manager incompatibilities? How well does your language "zis" support the SHAPES extension and ICCCM protocol, or improve upon them, and what else is it good for than xeyes? Finally, does "zis" support dragging and dropping eyes into each other, nesting their windows into an arbitrarily deep hierarchy, like my NeWS eyes did 27 years ago, and what ICCCM window managers support that feature, or did you have to write your own window manager or X extension to support that feature? Thanks for taking all this time and effort to design and write and share all that code, and to support and clarify your fascinating arguments. I'm looking forward to seeing your code and your answers to my questions.