4 ms·

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief

Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief scientist at Nvidia, and an old friend of mine): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://en.wikipedia.org/wiki/David_S._H._Rosenthal https://en.wikipedia.org/wiki/David_S._H._Rosenthal The X-Windows Disaster: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... Ice Cube: The Lethal Weapon One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel. If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view. As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past. The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release. In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor. Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

vidarh 3y ago
In practice this matters for some people and not to others. My wm so far largely ignores the ICCCM and will never implement most of it. I have no reason to (heck, I haven't read all of it, and have no plans to - I've read parts and may apply parts, though some parts I'll just take mild inspiration from). The previous WM I used (I now use my ~7 day old WM; dog-fooding a piece of software which may or may not restart is fun, but with a little bit of care I haven't "lost" any open windows since the Reparenting Disaster Of Last Wednesday) was bspwm which certainly is not compliant either. And that's fine. What I have in few hundred lines works well enough for my needs, and already does some things closer to how I want them than bspwm (bspwm is great; I have odd expectations) I don't want my machine to work like a friends. I want it to work in the way that best suits me. Nobody else is going to use it - and thanks to smart phones there is less need than ever to let anyone. I don't need a lot of applications to run - a terminal (my own), a file manager (my own), an editor (my own, and running in the terminal), a browser, and image viewer and a PDF viewer add up to pretty much everything I run that isn't a web app or on the command line. But Wayland doesn't fix the described mess. By deferring nearly everything to extensions, it has fragmented the space far more than X wms ever did. The level of boilerplate to talk to a Wayland compositor makes an X client look trivial (you can of course, and should, use a toolkit if trying to talk to Wayland; with X it's a lot closer to optional, at least if you only care about running on modern servers where you can insist on expecting XRender and the availability of an RGBA visual it guarantees and pretend the rest doesn't exist) Then again, as I said, to RHEL customers that probably doesn't matter. They're not going to be likely to be anarchic places full of not quite interoperable diverse window managers. For them Wayland is probably fine. Or rather a specific Wayland compositor and a curated set off apps known to work with it will likely be fine. (As always I love your historical links and quotes, though)
- DonHopkins 3y ago
  I love your dedication to customizing your own environment! 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/OpenDoc https://en.wikipedia.org/wiki/Cyberdog 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 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_interface_designer_for_java https://techmonitor.ai/technology/marimba_offers_bongo_inter... https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html 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/dp/1575212544 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 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 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.lisp 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://donhopkins.com/home/archive/NeWS/owm.ps.txt https://news.ycombinator.com/item?id=29094938 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 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-goodnews-99f411e58ce4 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... https://news.ycombinator.com/item?id=24787166 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 https://schneegans.github.io/news/2020/08/13/flypie http://schneegans.github.io/news/2020/10/10/flypie3 http://schneegans.github.io/news/2020/10/10/flypie3 http://schneegans.github.io/news/2018/05/31/openpie http://schneegans.github.io/news/2018/05/31/openpie http://schneegans.github.io/gnome-pie http://schneegans.github.io/gnome-pie http://schneegans.github.io/news/2017/07/09/gnome-pie-071 http://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2012/10/10/bachelor-thesis https://schneegans.github.io/news/2012/10/10/bachelor-thesis https://vimeo.com/51072812 https://vimeo.com/51072812 https://vimeo.com/51073078 https://vimeo.com/51073078 https://news.ycombinator.com/item?id=38235871 https://news.ycombinator.com/item?id=38235871 DonHopkins 16 days ago | parent | next [–] [...] Gnome-Pie (wikipedia): https://en.wikipedia.org/wiki/Gnome-Pie https://en.wikipedia.org/wiki/Gnome-Pie Gnome-Pie (github): https://schneegans.github.io/gnome-pie https://schneegans.github.io/gnome-pie Gnome-Pie 0.6.1: https://vimeo.com/125339537 https://vimeo.com/125339537 Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor! https://www.youtube.com/watch?v=sRT3O9-H5Xs 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 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 https://www.youtube.com/watch?v=ZTdfnUDMO9k Follow and support the project on Ko-Fi: https://ko-fi.com/schneegans https://ko-fi.com/schneegans Kando on GitHub: https://github.com/kando-menu/kando 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 https://schneegans.github.io/news/2012/10/10/bachelor-thesis The Trace-Menu: https://vimeo.com/51073078 https://vimeo.com/51073078 The Coral-Menu: https://vimeo.com/51072812 https://vimeo.com/51072812 More of his great stuff: https://schneegans.github.io/ 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 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 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 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 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 https://ko-fi.com/post/Introducing-Ken-Do-L3L7L0FQ2 [...]

vidarh 3y ago

In practice this matters for some people and not to others. My wm so far largely ignores the ICCCM and will never implement most of it. I have no reason to (heck, I haven't read all of it, and have no plans to - I've read parts and may apply parts, though some parts I'll just take mild inspiration from). The previous WM I used (I now use my ~7 day old WM; dog-fooding a piece of software which may or may not restart is fun, but with a little bit of care I haven't "lost" any open windows since the Reparenting Disaster Of Last Wednesday) was bspwm which certainly is not compliant either. And that's fine. What I have in few hundred lines works well enough for my needs, and already does some things closer to how I want them than bspwm (bspwm is great; I have odd expectations) I don't want my machine to work like a friends. I want it to work in the way that best suits me. Nobody else is going to use it - and thanks to smart phones there is less need than ever to let anyone. I don't need a lot of applications to run - a terminal (my own), a file manager (my own), an editor (my own, and running in the terminal), a browser, and image viewer and a PDF viewer add up to pretty much everything I run that isn't a web app or on the command line. But Wayland doesn't fix the described mess. By deferring nearly everything to extensions, it has fragmented the space far more than X wms ever did. The level of boilerplate to talk to a Wayland compositor makes an X client look trivial (you can of course, and should, use a toolkit if trying to talk to Wayland; with X it's a lot closer to optional, at least if you only care about running on modern servers where you can insist on expecting XRender and the availability of an RGBA visual it guarantees and pretend the rest doesn't exist) Then again, as I said, to RHEL customers that probably doesn't matter. They're not going to be likely to be anarchic places full of not quite interoperable diverse window managers. For them Wayland is probably fine. Or rather a specific Wayland compositor and a curated set off apps known to work with it will likely be fine. (As always I love your historical links and quotes, though)

DonHopkins 3y ago
I love your dedication to customizing your own environment! 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/OpenDoc https://en.wikipedia.org/wiki/Cyberdog 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 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_interface_designer_for_java https://techmonitor.ai/technology/marimba_offers_bongo_inter... https://people.apache.org/~jim/NewArchitect/webtech/1997/10/note/index.html 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/dp/1575212544 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 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 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.lisp 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://donhopkins.com/home/archive/NeWS/owm.ps.txt https://news.ycombinator.com/item?id=29094938 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 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-goodnews-99f411e58ce4 https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g... https://news.ycombinator.com/item?id=24787166 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 https://schneegans.github.io/news/2020/08/13/flypie http://schneegans.github.io/news/2020/10/10/flypie3 http://schneegans.github.io/news/2020/10/10/flypie3 http://schneegans.github.io/news/2018/05/31/openpie http://schneegans.github.io/news/2018/05/31/openpie http://schneegans.github.io/gnome-pie http://schneegans.github.io/gnome-pie http://schneegans.github.io/news/2017/07/09/gnome-pie-071 http://schneegans.github.io/news/2017/07/09/gnome-pie-071 https://schneegans.github.io/news/2012/10/10/bachelor-thesis https://schneegans.github.io/news/2012/10/10/bachelor-thesis https://vimeo.com/51072812 https://vimeo.com/51072812 https://vimeo.com/51073078 https://vimeo.com/51073078 https://news.ycombinator.com/item?id=38235871 https://news.ycombinator.com/item?id=38235871 DonHopkins 16 days ago | parent | next [–] [...] Gnome-Pie (wikipedia): https://en.wikipedia.org/wiki/Gnome-Pie https://en.wikipedia.org/wiki/Gnome-Pie Gnome-Pie (github): https://schneegans.github.io/gnome-pie https://schneegans.github.io/gnome-pie Gnome-Pie 0.6.1: https://vimeo.com/125339537 https://vimeo.com/125339537 Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor! https://www.youtube.com/watch?v=sRT3O9-H5Xs 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 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 https://www.youtube.com/watch?v=ZTdfnUDMO9k Follow and support the project on Ko-Fi: https://ko-fi.com/schneegans https://ko-fi.com/schneegans Kando on GitHub: https://github.com/kando-menu/kando 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 https://schneegans.github.io/news/2012/10/10/bachelor-thesis The Trace-Menu: https://vimeo.com/51073078 https://vimeo.com/51073078 The Coral-Menu: https://vimeo.com/51072812 https://vimeo.com/51072812 More of his great stuff: https://schneegans.github.io/ 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 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 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 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 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 https://ko-fi.com/post/Introducing-Ken-Do-L3L7L0FQ2 [...]