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
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
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/...
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
Some before and after examples, like menu.h menu.pdb menu.PS:
https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.h: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.pdb: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
GoodNeWS/HyperNeWS/HyperLook:
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-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/...
>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
[...]
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/...
>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
>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
>Wow, a blast from the past! 1996, what a year that was. [...]
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-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/...
>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
[...]
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/...
>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
>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
>Wow, a blast from the past! 1996, what a year that was. [...]
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.
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
>Official Marimba Guide to Bongo, by Danny Goodman
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
>SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
>HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
[...]
>The Axis of Eval: Code, Graphics, and Data
>We will return to these three important dimensions of Code, Graphics and Data as a recurring theme throughout this article. But which way to go from here?
>Alan Kay on NeWS:
>“I thought NeWS was ‘the right way to go’ (except it missed the live system underneath). It was also very early in commercial personal computing to be able to do a UI using Postscript, so it was impressive that the implementation worked at all.” -Alan Kay
It was indeed deeply inspired by and indebted to HyperCard, but of course had networking built in thanks to NeWS, and used PostScript as the data format and networking protocol (like XML and JSON are now used), and as the scripting language (which is more like Lisp than HyperTalk), and as the imaging model instead of pixels (including a nice built-in structured graphics editor component that supported EPS and raster images too, which you could use to build your own apps, property sheets, and editors, like the editable Clock component the article shows).
Another significant difference between HyperCard and HyperLook is that HyperLook used its own "stacks" to implement its own user interface for property sheets, etc. HyperCard just used the traditional Mac Toolbox for its user interface, instead of property sheets and dialogs being stacks. So you could edit and customize HyperLook property sheets and dialogs, and define new classes of HyperLook widgets, and then build your own seamlessly integrated property sheets for them (or just customize the property sheets of existing components). For example, I defined some NeWS Toolkit OPEN LOOK components like sliders and buttons and menus to support SimCity, all configurable with their own property sheets. The property sheets could use as many PostScript graphics editor components as they needed: for example, the editable clock component's property sheet let you edit its clock face, minute hand, and hour hand, which it rotated and drew around the clock. ...But it was just too slow to practically redraw a second hand once per second, so I left that out! Then you could copy and paste your custom clocks into any HyperLook stack, in case you cared what time it was.
However, this feature did enable "user interface vandalism", so HyperLook has a non-editable runtime system with the editors stripped out, that you could ship with apps:
http://www.art.net/~hopkins/Don/hyperlook/TalkRunTime.gif
In case you don't like PostScript as much as I do, Arthur van Hoff also wrote "PdB", an object oriented C to PostScript compiler that you could use to write classes and scripts. Later, after working on Java at Sun and leaving to found Marimba, Arthur wrote Bongo in Java, which was inspired by HyperCard (and called the Java compiler he wrote at Sun to dynamically compile scripts), and Danny Goodman wrote the book on Bongo! (He also wrote the book on HyperCard.) Arthur's working at Apple, now.
https://en.wikipedia.org/wiki/Arthur_van_Hoff
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
https://books.google.nl/books?id=NToEAAAAMBAJ&pg=PA47&lpg=PA...
I've included links to a bunch of brochures, articles, product info, documentation, and SimCity README and manual at the end of the article. Here's the link to the HyperLook product info, which summarizes it pretty well, and the HyperLook SimCity manual, which has a lot of screen snapshots and shows what it can do.
HyperLook Product Info:
http://donhopkins.com/home/HyperLook-Product-Info.pdf
HyperLook SimCity Manual:
https://donhopkins.com/home/HyperLook-SimCity-Manual.pdf
Also here's an illustrated transcript of a HyperLook SimCity demo (that shows all kinds of other HyperLook and NeWS stuff too, and includes a link to the original video):
https://medium.com/@donhopkins/hyperlook-simcity-demo-transc...
Imagine a window manager built on top of something like HyperLook, where users can not only edit the "chrome" in the window frames to make them look and behave any way they prefer, but also compose custom task-oriented interfaces by copying and pasting components from different parts of the same app, or even different apps, and integrating them by scripting, so you don't have to flip between different windows and navigate to different parts of multiple apps, and you just have all the controls you need together in one place, without any unnecessary junk. For example, SimCity came with an audio mixing server that other apps could use by sending messages to it, which would be mixed with SimCity's sounds, so you could make a button that went "PING" whenever you pressed it, then copy and paste it into any other HyperLook stack, and it would work! Or you could make a custom "SimCity Surveillance" window by copying three different map views into the same window:
https://miro.medium.com/max/556/0*XknyNX0FMotAR7y_.gif
>The neat thing is that this view here itself is just another user interface component, and I can copy and paste that, and have multiple views. Each one of these animated scrolling SimCity editors, once I’ve made one, I can put them anywhere. This window, you can click here to get three of them.
https://en.wikipedia.org/wiki/Arthur_van_Hoff
Arthur later went on to Sun, wrote the Java compiler in Java, developed the AWT user interface toolkit, then formed Marimba with Kim Polesi and Jonathan Payne and others from the original Java team, where they developed Castanet and Bongo.
https://www.wired.com/1996/11/es-marimba/
>1996-11-01: Tuning in to Marimba. Kim Polese wants you to upgrade your HTML-based browser to a more interactive, more TV-like, Java-based "tuner" by the name of Castanet.
>Marimba's first product, scheduled to be announced in early October, is the punnily named Castanet, which aims to push Java toward its full potential. Java was created to deliver interactive content over distributed networks, and its much-hyped arrival last year promised to completely change the way information and entertainment are delivered electronically. The first popular Java programs have been based on HTML - for example, the Java applets that lend some animation to boring Web pages. But Java doesn't need the Web to fly. It was designed to communicate over any kind of decentralized system. [...]
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/...
>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.
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
I've written lots more about HyperLook, NeWS and SimCity:
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
https://news.ycombinator.com/item?id=19837817
https://news.ycombinator.com/item?id=18314265
I'm frustrated that Wayland doesn't support all the good ideas (and avoid all the bad ideas) of X-Windows or NeWS, and doesn't even have a built-in extension language like emacs and web browsers do. (What were they even thinking, not making it extensible at runtime? That everybody would want to compile their own server to customize it in C? Or that they'd solved all possible problems perfectly and there would be no need for customization?)
I always thought X window managers put the cart before the donkey: the client starts first, then the window manager reactivally wraps it in a generic frame.
Instead, window managers should be more like HyperCard, where users can wysiwyg build and script their own stacks that frame and compose and integrate one or more clients together (or none, for fully server side stacks like the clock or drawing editor): the stacks come first, and they start up and pull in whatever clients they want to frame and integrate and even script.
Of course you should just be able to run any client and it gets assigned a generic frame, but the user can edit both the generic frame prototype in the warehouse, edit and add scripts and message handlers, and customize any existing frame, including adding more pages (with tabs) and widgets and clients, and save them out to use later, restore all your windows after you reboot, add them to the warehouse, trade them with friends, etc.
Users can easily customize and script their own window frames (stacks), and add or edit the look and feel of gui widgets like resize corners, buttons , tabs, and pie menus, and even high level components like drawing editors (great for property sheets that let you edit the graphics and colors and layouts of the gui, clock faces and hands, or graphics you can cut and paste between clients), so they can script and integrate together multiple clients to customize them for particular tasks and workflows.
OpenDoc and CyberDog were barking up the right tree, but they didn't have a ubiquitous scripting language that you could use to both integrate and implement components.
https://en.wikipedia.org/wiki/OpenDoc
https://en.wikipedia.org/wiki/Cyberdog
Sun's HotJava browser was also a step in the right direction, but it did not include a Java interpreter or the Java compiler written in Java (which was written by Arthur van Hoff who earlier wrote HyperLook for NeWS), so it didn't have runtime scripting like HyperCard had with HyperTalk.
https://en.wikipedia.org/wiki/HotJava
Later at Marimba, Arthur implemented Bongo, which did include and invoke the Java compiler and dynamic linker at runtime, so you could interactively write and run scripts and message handlers. (IDEs do this all the time now, but it was unprecedented for Java at the time, and Arthur knew how to pull it off, because he'd written the compiler.)
https://techmonitor.ai/technology/marimba_offers_bongo_inter...
https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...
Danny Goodman, the guy who wrote the HyperCard manual, also wrote the book on Bongo:
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
At UMD I wrote an X10 window manager scriptable in FORTH (by linking in the C "uwm" X10 window manager that I'd implemented pie menus for, and rewriting its main loop in Mitch Bradley's Sun FORTH, so I could fling windows around and they would animate bouncing around the screen with FORTH tasks), and used it to perform and measure controlled experiments comparing pie and liner menus.
https://donhopkins.com/home/archive/piemenu/uwm1/fuwm-main.f
Hacks for flinging windows around with FORTH tasks:
https://donhopkins.com/home/archive/piemenu/uwm1/hacks.f
Here's a similar hack in Lisp for the Lisp Machine window system using Flavors to define a pushy-bounce-window-mixin:
https://donhopkins.com/home/archive/lisp/bounce-and-push.lis...
And at Sun we wrote an integrated X11 and NeWS window manager for X11/NeWS in PostScript (three of them actually, but the last one "owm" was the best), which could manage X11 windows much better than X11 could (plus it was easily extensible, with tabbed windows, pie menus, rooms, scrolling virtual desktop, shaped windows, and was more responsive and didn't let input events fall through the cracks when you changed focus). And we also planned on making a much more advanced window manager with HyperLook (like HyperCard in PostScript), before Sun pulled the rug out from under us.
https://donhopkins.com/home/archive/NeWS/owm.ps.txt
https://news.ycombinator.com/item?id=29094938
>And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm".
https://news.ycombinator.com/item?id=24787061
DonHopkins on Oct 15, 2020 | parent | next [–]
Those are some great ideas that dovetail together in powerful ways! Thanks you for sharing your work in progress. In the hopes of inspiring you and others, here's a kind of messy draft of an article I haven't completely finished, but it's all about HyperLook (a user-editable desktop GUI system inspired by HyperCard and implemented in NeWS PostScript) and some components and applications I developed with it, like SimCity, a cellular automata machine, pie menus, a customizable clock editor, a customizable window manager, and "Happy Tool":
SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
https://news.ycombinator.com/item?id=24787166
DonHopkins on Oct 15, 2020 | parent | next [–]
You should check out Simon Schneegan's spectacular work on FlyPie, OpenPie, Gnome-Pie, and his Coral Menus and Trace Menus:
https://schneegans.github.io/news/2020/08/13/flypie
http://schneegans.github.io/news/2020/10/10/flypie3
http://schneegans.github.io/news/2018/05/31/openpie
http://schneegans.github.io/gnome-pie
http://schneegans.github.io/news/2017/07/09/gnome-pie-071
https://schneegans.github.io/news/2012/10/10/bachelor-thesis
https://vimeo.com/51072812
https://vimeo.com/51073078
https://news.ycombinator.com/item?id=38235871
DonHopkins 16 days ago | parent | next [–]
[...]
Gnome-Pie (wikipedia):
https://en.wikipedia.org/wiki/Gnome-Pie
Gnome-Pie (github):
https://schneegans.github.io/gnome-pie
Gnome-Pie 0.6.1:
https://vimeo.com/125339537
Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!
https://www.youtube.com/watch?v=sRT3O9-H5Xs
Fly-Pie 10: A new Clipboard Menu, proper touch support & much more!
https://www.youtube.com/watch?v=BGXtckqhEIk
And Simon's new project, Kando:
Kando - An Open Source, Cross-Platform Pie Menu:
https://www.youtube.com/watch?v=ZTdfnUDMO9k
Follow and support the project on Ko-Fi:
https://ko-fi.com/schneegans
Kando on GitHub:
https://github.com/kando-menu/kando
I also love the beautiful Trace and Coral menus he designed for his Bachelor thesis 11 years ago:
https://schneegans.github.io/news/2012/10/10/bachelor-thesis
The Trace-Menu:
https://vimeo.com/51073078
The Coral-Menu:
https://vimeo.com/51072812
More of his great stuff:
https://schneegans.github.io/
[...]
Some years ago, Simon discussed some of the problems with Wayland that made it impossible to implement all the features of Gnome-Pie. I don't know how much Wayland has progressed to address those problems since then, but he's moved onto developing cross platform pie menus with Kando - An Open Source, Cross-Platform Pie Menu, to reach the much wider audience of Windows and Mac users as well as Linux.
It baffles me that the Wayland compositor wasn't designed from the ground up in the first place around a scripting language like JavaScript (or PostScript even ;). It's not like the idea was a secret or patented, and it seems to work well for emacs and web browsers. Then it would have been much easier to address all those problems and implement much more flexible powerful and efficient window managers, pie menus, tabbed windows, etc. And then maybe Wayland wouldn't be so limited, and would have already fully taken over from X11 decades ago.
https://schneegans.github.io/news/2017/07/09/gnome-pie-071
Wayland – in it’s current state – makes applications such as Gnome-Pie hardly possible. Due to security concerns, applications are much more isolated. There is a good summary on the cairo-dock forums.
https://glx-dock.org/mr_article.php?b=5&a=73
Here are the big bummers:
No client side window placement: Application cannot position their windows. How shall we open the Pie beneath the cursor? The only way I can think of is to open a transparent full screen window and draw Gnome-Pie at the pointer location. Sadly, this is not possible either: Only as soon as the user moves the pointer over the window, we can get the pointer location. I see no chance in getting this information more early. That means that we simply do not know were the mouse is when we open the full screen window. Hence, Pies can be opened at the center of the screen only.
No global input grabbing: Another reason for the full screen window is, that input capturing is impossible. This is the only possibility to close Gnome-Pie when the user clicks outside the activation radius. The full screen window makes the whole thing much slower and may lead to unwanted side effects such as auto-hiding panels.
No global key bindings: Applications cannot intercept keyboard or mouse events anymore. While this seems reasonable in the context of security concerns, it limits the usefulness of Gnome-Pie drastically. The only possibility is to open Pies with the terminal command gnome-pie --open <ID of your Pie>. Of course, this command can be bound to global hot keys of your desktop shell (as can be seen in the screen shot above), assigned to hot corners, etc. However, there is no way to support the turbo mode and delayed activation mode Gnome-Pie features on X11.
No mouse pointer warping: It is impossible for an application to manipulate the position of the mouse pointer. Therefore it is impossible to warp the pointer to the center of the Pie.
No client side window management: This is something for the desktop shell. There is possibility for a client application to get a list of opened windows. Therefore something like the window list slice group (Alt-Tab) is not possible. Maybe there will be an interface in future? Gnome-Pie uses wnck which is specific to X11.
No sending of fake keyboard events: This is a very useful action type for pie slices. In addition, this is required for deferred pie activation.
The conclusion Hopefully this can be improved in future, however a lot of security decisions have been made during the development of Wayland which make applications like Gnome-Pie basically impossible. If there are no large scale changes in Wayland, I see bad future for Gnome-Pie.
If someone knows solutions for some of these problems please help making Gnome-Pie useful on Wayland!
[...]
https://schneegans.github.io/news/2018/05/31/openpie
OpenPie! With the advent of Wayland Gnome-Pie will slowly die. OpenPie is my new concept for bringing (pie-) menus to the Linux desktop. In this post I will give a motivation and describe the planned software architecture.
Gnome-Pie will die. On Wayland, there are at least six major issues which make applications such as Gnome-Pie basically impossible. I have described these issues in one of my previous posts in more detail - here they are listed again:
No client side window placement - Menus cannot be opened at cursor location
No global input grabbing - When a menu is opened, you will still be able to Alt-Tab to another application, etc.
No global key bindings - No global hot-keys from within Gnome-Pie. Only cumbersome configuration in your window manager
No mouse pointer warping - Leads to problems when menus are opened close to screen edges
No client side application management - No Alt-Tab window list features
No sending fake keyboard events - No simulated key strokes or deferred activation anymore
[...]
https://github.com/kando-menu/kando
Kando will be a pie menu for the desktop. It will be highly customizable and will allow you to create your own menus and actions. For instance, you can use it to control your music player, to open your favorite websites or to simulate shortcuts. It will be available for Windows, Linux and maybe macOS.
The Vision I am the developer of Fly-Pie, which is a similar project but limited to the GNOME desktop. I have been working on Fly-Pie for more than 3 years now and I am very happy with the result. However, I have always wanted to create a similar application for the desktop in general. This is why I started this project.
Kando is very similar to Fly-Pie in terms of interaction and appearance. At the same time, there will be some major differences. You can read more in this blog post!
https://ko-fi.com/post/Introducing-Ken-Do-L3L7L0FQ2
[...]