9 ms·

It is interesting that something 'not the ultimate window system' can last almost 40 years already, though it also seems like Wayland is getting close to critic

It is interesting that something 'not the ultimate window system' can last almost 40 years already, though it also seems like Wayland is getting close to critical mass of adoption?

thesuitonym 5y ago
Wayland is getting close, and is very good indeed, but X is still the default window system. I feel like there are a lot of technologies that are this way. They were not designed to be the best, but good enough, and they have passed the test of time.
- a-dub 5y ago
  i have a hard time liking wayland because they're taking away remoting, which was one of my favorite parts of x.
  - johnny22 5y ago
    waypipe is one solution in that realm (i haven't used it myself though). but it's not like x servers and clients will stop working.
    - colonwqbang 5y ago
      Once wayland gets good adoption, people will gradually stop supporting X. That is how it always works in software.
  - sprash 5y ago
    Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing manager at runtime without affecting any running programs. In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server. So kind of the opposite of what Wayland is doing.
    - DonHopkins 5y ago
      "X: The First Fully Modular Software Disaster" https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#fda6 https://donhopkins.medium.com/the-x-windows-disaster-128d398... John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls": https://news.ycombinator.com/item?id=17056516 https://news.ycombinator.com/item?id=17056516 DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori... Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet? There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly. https://news.ycombinator.com/item?id=6864364 https://news.ycombinator.com/item?id=6864364 "For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;) https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047 https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047... https://news.ycombinator.com/item?id=15325226 https://news.ycombinator.com/item?id=15325226 https://web.archive.org/web/20171028110659/https://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html https://web.archive.org/web/20171028110659/https://minnie.tu... >XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. >The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. >The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. >The bit encodings should be part of a separate language binding, not part of the functional description. [...] >X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." >Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. [...]
  - erik_seaberg 5y ago
    AFAIK Wayland in a datacenter still falls back to software rendering and running images through a video codec. I think X is more likely to be replaced by Javascript apps, because those are cross platform and a browser running locally can take advantage of the end user’s GPU.
    - DonHopkins 5y ago
      Gee, that sounds kind of like the whole point of NeWS. ;) https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation. https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398...
      - rbanffy 5y ago
        > - used PostScript code instead of JavaScript for programming. I'm no fan of JavaScript, but even I would prefer it to PostScript. And I actually like FORTH.
        DonHopkins 5y ago
        That's interesting! I love Forth, but I love PostScript even more, because it's so much like Lisp. What is it about PostScript that you dislike, that doesn't bother you about Forth? Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript. https://news.ycombinator.com/item?id=25432748 https://news.ycombinator.com/item?id=25432748 DonHopkins on Dec 15, 2020 | parent | context | favorite | on: Source of the famous “Now you have two problems” q... Leigh Klotz has written more PostScript than Jamie too, while working at Xerox! But "KLOTZ IS A LOGO PRIMITIVE [BEEP BEEP BEEP]". He wrote a 6502 assembler in Logo! https://news.ycombinator.com/item?id=13524588 https://news.ycombinator.com/item?id=13524588 Leigh Klotz's comment on the regex article: >OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java. >So there. >And yes, we did have two problems… >— comment by Leigh L. Klotz, Jr. on June 7th, 2008 at 3:22am JST (12 years, 6 months ago) — comment permalink Arthur van Hoff (the author of PdB and the original Java compiler written in Java) has also written more PostScript than Jamie, especially if you count the PostScript written by programs he wrote, like PdB and GoodNeWS/HyperNeWS/HyperLook. Here's the README file (and distribution) of PdB, Arthur van Hoff's object oriented C to PostScript compiler: https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/pdb/pdb2.1.1-README https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/... Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms": https://www.donhopkins.com/home/archive/NeWS/PdB.txt https://www.donhopkins.com/home/archive/NeWS/PdB.txt Some before and after examples, like menu.h menu.pdb menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/ https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.h: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.h https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.pdb: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.pdb https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.PS https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... GoodNeWS/HyperNeWS/HyperLook: https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-goodnews-99f411e58ce4 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... pvg on Dec 15, 2020 | prev [–] Arthur van Hoff (the author of PdB and the original Java compiler written in Java) And the original AWT, if this is to be a full Airing of Sins. DonHopkins on Dec 15, 2020 | parent [–] Agreed, AWT was a horrible compromise in an impossible situation! But he made up for it by creating "Bongo" at Marimba. Bongo is to Java+HyperCard as HyperLook is to PostScript+HyperCard. https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-goodnews-99f411e58ce4#1718 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... >Arthur van Hoff [...] >Marimba Castanet and Bongo >Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts. >Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor. >Danny Goodman’s “Official Marimba Guide to Bongo” https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/dp/1575212544 https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/... >Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”. >[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.] >Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review >Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review Unfortunately Marimba's Bongo got overshadowed by Sun's announcement of "Java Beans" which Sun was pushing with much fanfare and handwaving as an alternative to "ActiveX", but which eventually turned out to actually be just a server side data modeling technology, not a client gui framework. https://news.ycombinator.com/item?id=21784027 https://news.ycombinator.com/item?id=21784027 [...] Marimba developed Bongo, a Java-based gui toolkit / user interface editor / graphical environment, inspired by HyperCard (and HyperLook), which they used to develop and distribute interactive user interfaces over Castanet. https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html https://people.apache.org/~jim/NewArchitect/webtech/1997/10/... >Feel the Beat with Marimba's Bongo, By Chris Baron >In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications. Bongo was unique at the time in that it actually let you edit and dynamically compile scripts for event handlers and "live code" at run-time (in contrast with other tools that required you to recompile and re-run the application to make changes to the user interface), which was made possible by calling back to the Java compiler (which Arthur had written before at Sun, so he knew how to integrate the compiler at runtime like a modern IDE would do). Without the ability to dynamically edit scripts at runtime (easy with an interpreted language like HyperTalk or PostScript or JavaScript, but trickier for a compiled language like Java), you can't hold a candle to HyperCard, because interactive scripting is an essential feature. Danny Goodman, who wrote the book on HyperCard, also wrote a book about Bongo. Arthur later founded Flipboard and JauntVR, and now works at Apple. Here's a paper I wrote comparing Bongo with IFC (Netscape's much-ballyhooped Java Internet Foundation Classes). (Notice how IFC = Internet Foundation Classes was Netscape's answer to MFC = Microsoft Foundation Classes. Never define your product's name in terms of a reaction to your widely successful competitor's name. cough SunSoft cough) NetScape's Internet Foundation Classes and Marimba's Bongo https://donhopkins.com/home/interval/ifc-vs-bongo.html https://donhopkins.com/home/interval/ifc-vs-bongo.html >In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans. More: https://news.ycombinator.com/item?id=19837817 https://news.ycombinator.com/item?id=19837817 >Wow, a blast from the past! 1996, what a year that was. [...]
  - M1nase 5y ago
    That's not where it stops... wayland was designed without giving any thought to color management at all. Beware, long read ahead, not happy ending: https://discuss.pixls.us/t/wayland-color-management/10804 https://discuss.pixls.us/t/wayland-color-management/10804 I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.
    - kaba0 5y ago
      https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
      - magicalhippo 5y ago
        Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component. Having a bunch of pixels with no knowledge of which color space they're in is useless.
        pierrebai 5y ago
        You think that color management belongs in the window manager / compositor. Wayland thinks color management belongs in the app. The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control. So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
        magicalhippo 5y ago
  - kaba0 5y ago
    X is not “network transparent” for any practical definition. Most modern applications don’t use X render commands to draw, so you will get shitload of bitmaps moved over the network, which will result in really bad performance. Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
    - drzaiusapelord 5y ago
      VNC outperforms it, which is saying a lot since VNC is terrible. Remote x apps were always this selling point in linux culture and I always thought I was doing something wrong because they were so incredibly slow until I realized its the protocol that's just slow.
      - glandium 5y ago
        It was fine until apps ended up doing everything on their end and push pixmaps to the X server. Back in the xaw and motif days, it was fine.
        kaba0 5y ago
        Well yeah, but then you could just as well use an ncurses app through ssh for the same “experience”
    - SkeuomorphicBee 5y ago
      While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.
      - kaba0 5y ago
- kiwijamo 5y ago
  Debian uses Wayland by default these days. "As [GNOME] is the default Debian desktop environment, Wayland is used by default in Debian 10 and newer, older versions use Xorg by default." -- https://wiki.debian.org/Wayland https://wiki.debian.org/Wayland I personally use Arch and GNOME seemed to use Wayland by default without any intervention from me.
  - shmerl 5y ago
    Gnome still doesn't support adaptive sync in the Wayland session? KDE does, but last time I tried the Wayland session it had a major bug with display sleep, so I'm waiting for Plasma 5.24 to try it again since it should have some fixes for that.
glandium 5y ago
What's pretty wild is it took 3 years to reach X11, and that's where we're at, although there have been a bunch of revisions.

It is interesting that something 'not the ultimate window system' can last almost 40 years already, though it also seems like Wayland is getting close to critical mass of adoption?

thesuitonym 5y ago

Wayland is getting close, and is very good indeed, but X is still the default window system. I feel like there are a lot of technologies that are this way. They were not designed to be the best, but good enough, and they have passed the test of time.

a-dub 5y ago
i have a hard time liking wayland because they're taking away remoting, which was one of my favorite parts of x.
- johnny22 5y ago
  waypipe is one solution in that realm (i haven't used it myself though). but it's not like x servers and clients will stop working.
  - colonwqbang 5y ago
    Once wayland gets good adoption, people will gradually stop supporting X. That is how it always works in software.
- sprash 5y ago
  Personally I like the modularity of X11 because it has a lot of standardized interfaces. For example, you can exchange the window manager and the compositing manager at runtime without affecting any running programs. In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server. So kind of the opposite of what Wayland is doing.
  - DonHopkins 5y ago
    "X: The First Fully Modular Software Disaster" https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47#fda6 https://donhopkins.medium.com/the-x-windows-disaster-128d398... John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls": https://news.ycombinator.com/item?id=17056516 https://news.ycombinator.com/item?id=17056516 DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori... Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet? There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly. https://news.ycombinator.com/item?id=6864364 https://news.ycombinator.com/item?id=6864364 "For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;) https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047 https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047... https://news.ycombinator.com/item?id=15325226 https://news.ycombinator.com/item?id=15325226 https://web.archive.org/web/20171028110659/https://minnie.tuhs.org/pipermail/tuhs/2017-September/010471.html https://web.archive.org/web/20171028110659/https://minnie.tu... >XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two. >The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there. >The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added. >The bit encodings should be part of a separate language binding, not part of the functional description. [...] >X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation." >Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls. [...]
- erik_seaberg 5y ago
  AFAIK Wayland in a datacenter still falls back to software rendering and running images through a video codec. I think X is more likely to be replaced by Javascript apps, because those are cross platform and a browser running locally can take advantage of the end user’s GPU.
  - DonHopkins 5y ago
    Gee, that sounds kind of like the whole point of NeWS. ;) https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: - used PostScript code instead of JavaScript for programming. - used PostScript graphics instead of DHTML and CSS for rendering. - used PostScript data instead of XML and JSON for data representation. https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398...
    - rbanffy 5y ago
      > - used PostScript code instead of JavaScript for programming. I'm no fan of JavaScript, but even I would prefer it to PostScript. And I actually like FORTH.
      - DonHopkins 5y ago
        That's interesting! I love Forth, but I love PostScript even more, because it's so much like Lisp. What is it about PostScript that you dislike, that doesn't bother you about Forth? Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript. https://news.ycombinator.com/item?id=25432748 https://news.ycombinator.com/item?id=25432748 DonHopkins on Dec 15, 2020 | parent | context | favorite | on: Source of the famous “Now you have two problems” q... Leigh Klotz has written more PostScript than Jamie too, while working at Xerox! But "KLOTZ IS A LOGO PRIMITIVE [BEEP BEEP BEEP]". He wrote a 6502 assembler in Logo! https://news.ycombinator.com/item?id=13524588 https://news.ycombinator.com/item?id=13524588 Leigh Klotz's comment on the regex article: >OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java. >So there. >And yes, we did have two problems… >— comment by Leigh L. Klotz, Jr. on June 7th, 2008 at 3:22am JST (12 years, 6 months ago) — comment permalink Arthur van Hoff (the author of PdB and the original Java compiler written in Java) has also written more PostScript than Jamie, especially if you count the PostScript written by programs he wrote, like PdB and GoodNeWS/HyperNeWS/HyperLook. Here's the README file (and distribution) of PdB, Arthur van Hoff's object oriented C to PostScript compiler: https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/pdb/pdb2.1.1-README https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/... Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms": https://www.donhopkins.com/home/archive/NeWS/PdB.txt https://www.donhopkins.com/home/archive/NeWS/PdB.txt Some before and after examples, like menu.h menu.pdb menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/ https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.h: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.h https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.pdb: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.pdb https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3.0/src/menu.PS https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3... GoodNeWS/HyperNeWS/HyperLook: https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-goodnews-99f411e58ce4 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... pvg on Dec 15, 2020 | prev [–] Arthur van Hoff (the author of PdB and the original Java compiler written in Java) And the original AWT, if this is to be a full Airing of Sins. DonHopkins on Dec 15, 2020 | parent [–] Agreed, AWT was a horrible compromise in an impossible situation! But he made up for it by creating "Bongo" at Marimba. Bongo is to Java+HyperCard as HyperLook is to PostScript+HyperCard. https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-goodnews-99f411e58ce4#1718 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... >Arthur van Hoff [...] >Marimba Castanet and Bongo >Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts. >Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor. >Danny Goodman’s “Official Marimba Guide to Bongo” https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/dp/1575212544 https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/... >Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”. >[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.] >Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review >Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review Unfortunately Marimba's Bongo got overshadowed by Sun's announcement of "Java Beans" which Sun was pushing with much fanfare and handwaving as an alternative to "ActiveX", but which eventually turned out to actually be just a server side data modeling technology, not a client gui framework. https://news.ycombinator.com/item?id=21784027 https://news.ycombinator.com/item?id=21784027 [...] Marimba developed Bongo, a Java-based gui toolkit / user interface editor / graphical environment, inspired by HyperCard (and HyperLook), which they used to develop and distribute interactive user interfaces over Castanet. https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html https://people.apache.org/~jim/NewArchitect/webtech/1997/10/... >Feel the Beat with Marimba's Bongo, By Chris Baron >In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications. Bongo was unique at the time in that it actually let you edit and dynamically compile scripts for event handlers and "live code" at run-time (in contrast with other tools that required you to recompile and re-run the application to make changes to the user interface), which was made possible by calling back to the Java compiler (which Arthur had written before at Sun, so he knew how to integrate the compiler at runtime like a modern IDE would do). Without the ability to dynamically edit scripts at runtime (easy with an interpreted language like HyperTalk or PostScript or JavaScript, but trickier for a compiled language like Java), you can't hold a candle to HyperCard, because interactive scripting is an essential feature. Danny Goodman, who wrote the book on HyperCard, also wrote a book about Bongo. Arthur later founded Flipboard and JauntVR, and now works at Apple. Here's a paper I wrote comparing Bongo with IFC (Netscape's much-ballyhooped Java Internet Foundation Classes). (Notice how IFC = Internet Foundation Classes was Netscape's answer to MFC = Microsoft Foundation Classes. Never define your product's name in terms of a reaction to your widely successful competitor's name. cough SunSoft cough) NetScape's Internet Foundation Classes and Marimba's Bongo https://donhopkins.com/home/interval/ifc-vs-bongo.html https://donhopkins.com/home/interval/ifc-vs-bongo.html >In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans. More: https://news.ycombinator.com/item?id=19837817 https://news.ycombinator.com/item?id=19837817 >Wow, a blast from the past! 1996, what a year that was. [...]
- M1nase 5y ago
  That's not where it stops... wayland was designed without giving any thought to color management at all. Beware, long read ahead, not happy ending: https://discuss.pixls.us/t/wayland-color-management/10804 https://discuss.pixls.us/t/wayland-color-management/10804 I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.
  - kaba0 5y ago
    https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/ https://www.collabora.com/news-and-blog/blog/2020/11/19/deve... Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
    - magicalhippo 5y ago
      Wayland was released in 2008. In 2008 color management should not be an afterthought for something which entire purpose is to ensure pixels end up on the screen, but rather an integral component. Having a bunch of pixels with no knowledge of which color space they're in is useless.
      - pierrebai 5y ago
        You think that color management belongs in the window manager / compositor. Wayland thinks color management belongs in the app. The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control. So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
        magicalhippo 5y ago
- kaba0 5y ago
  X is not “network transparent” for any practical definition. Most modern applications don’t use X render commands to draw, so you will get shitload of bitmaps moved over the network, which will result in really bad performance. Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
  - drzaiusapelord 5y ago
    VNC outperforms it, which is saying a lot since VNC is terrible. Remote x apps were always this selling point in linux culture and I always thought I was doing something wrong because they were so incredibly slow until I realized its the protocol that's just slow.
    - glandium 5y ago
      It was fine until apps ended up doing everything on their end and push pixmaps to the X server. Back in the xaw and motif days, it was fine.
      - kaba0 5y ago
        Well yeah, but then you could just as well use an ncurses app through ssh for the same “experience”
  - SkeuomorphicBee 5y ago
    While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.
    - kaba0 5y ago
kiwijamo 5y ago
Debian uses Wayland by default these days. "As [GNOME] is the default Debian desktop environment, Wayland is used by default in Debian 10 and newer, older versions use Xorg by default." -- https://wiki.debian.org/Wayland https://wiki.debian.org/Wayland I personally use Arch and GNOME seemed to use Wayland by default without any intervention from me.
- shmerl 5y ago
  Gnome still doesn't support adaptive sync in the Wayland session? KDE does, but last time I tried the Wayland session it had a major bug with display sleep, so I'm waiting for Plasma 5.24 to try it again since it should have some fixes for that.

glandium 5y ago

What's pretty wild is it took 3 years to reach X11, and that's where we're at, although there have been a bunch of revisions.