I remember in the late 90s when there were so many alternative interfaces for PCs. It was a great time for exploration on what could be done.
Kando is very pretty, and it can be fun to use an interface like this, but in terms of practicality, text inputs are better.
For example, on my desktop, there's an icon on my taskbar for Firefox, but most of the time, I get my screen to the search bar and type "F" and my system knows I probably want Firefox. Done.
There's a game I play, Astroneer, and it uses a pie interface. I often wish I could just type in what I want. It'd be faster.
I want to love this, but I can type on a keyboard so much faster, and use up so much less cognitive energy doing so than switching my hand to the mouse, pulling up a menu, reading the symbols (even if I have their location memorized) and pulling my wrist/arm in the right direction.
schneegans 22 days ago [-]
If you have both hands at your keyboard, that's 100% true. However, it really works well with workflows which rely on mouse, stylus, touch, or controller input.
Especially when used for "creative" or "artistic" tasks (e.g. painting, video editing, 3D modelling, etc.) pie menus can really have a benefit because you have your hand at the stylus or at the mouse most of the time anyways.
dr_kiszonka 21 days ago [-]
Kando looks incredible - congrats! And I can see how it works well for the use cases you described. Maybe it would be possible to add keyboard support? One could use left and right arrow keys to highlight an item and the up arrow key to select it.
layer8 20 days ago [-]
Radial menus never worked for me with a mouse pointer, even though I like(d) the idea in theory. It’s somehow easier to reliably hit traditional rectangular menu items arranged linearly, then some wedge in an angle.
hju22_-3 22 days ago [-]
I agree, but I also really like the pie menus. Personally, I'd like the ability to simply write to match, but otherwise working as demonstrated. E.g. like the Windows search works when you've hidden the search bar. I'd prefer both, in other words.
snapplebobapple 22 days ago [-]
Rofi has that search to match but iant a pie menu
dingnuts 22 days ago [-]
ideally you have a button on your mouse to summon this, and use it when you are already using your mouse, and summon a different interface for typing from your keyboard, when your hands are there
woolion 22 days ago [-]
It looks a bit like the Krita right-click palette menu, which is made with a similar idea that you want to be fast while only access to a tablet stylus.
I've seen that it has controller support, which is great; it's a cheap 'shortcut enabling' device that is readily available to most people.
It would be a bit easier to have a video on the homepage that is a whirlwind tour of the program rather than the latest changelog.
Although I have a motivation to find it useful (using a stylus restricts keyboard use), I've already set up a Tartarus with Input remapper to act as custom shortcuts etc, and it seems complicated to find how it would simplify or improve my existing setup.
viraptor 20 days ago [-]
As much as I like the concept and it's a nice execution... It's an electron app. It's a 100+MB package that displays one widget. It runs a browser engine to displays icons on your screen. This is madness.
I think there's a lot of unjustified prejudice against using web technology for desktop applications...
nine_k 20 days ago [-]
Not an unjustified prejudice, but an unjustified spending of resources, when such resources are not always readily available.
It's like creating a really nice set of Christmas lights, which only comes with a complete car as a part of the package, because it's powered by the car's engine. Indeed, a car's engine is a really good, well-engineered engine, and it works everywhere. But often one would really appreciate a string of Christmas lights that works from a wall power socket, and is 1000x lighter.
I find Kando a brilliant prototype of a future useful tool, which would have the size, complexity, and attack surface commensurate with the functions it provides.
I want to use something like Kando, but probably not Kando directly yet. I also suppose that Kando's approach, and most of the code, can be reused in proper web apps.
arghwhat 20 days ago [-]
To be fair, toolkits do come with full multiplatform renderers with capabilities not too dissimilar to a browser these days - see gtk4 and Qt for example. It's a lot of work for toolkits to replicate what browsers have spend ages getting right - efficiently displaying complex widget trees on numerous platforms and hardware configurations. And yes, that is in fact needed to draw efficiently.
So, it is not a question for car or not car, but SUV vs. compact, and several copies of the SUV at that as everything bundles the bloody thing. Normally I prefer static linking, but it's a bit much for a browser.
nine_k 20 days ago [-]
> toolkits do come with full multiplatform renderers with capabilities not too dissimilar to a browser
This is correct. But a menu does not need the entire set of capabilities of a toolkit like GTK4 or Qt6. It might take as much as Xlib or GL, which give you a way to draw simple shapes and text over a full-screen transparent window.
Most importantly, they usually do not include a bunch of things Javascript engines and even mere https clients, at least not easily accessible. (Though e.g. conformant XML parsers are always a hazard. And of course Qt6 does include a JS engine, but hopefully it's a bit more isolated.)
arghwhat 20 days ago [-]
GL is only a drawing API. Then you need to handle fonts (layout, rendering), input and focus (including compose and input methods), actual window management, ...
Things quickly become quite a lot less trivial than it initially seemed, and then you end up needing an actual toolkit.
You can certainly pick a more minimal one than a browser, but any application now requires a non-trivial toolkit.
> Qt6 does include a JS engine, but hopefully it's a bit more isolated.
I wouldn't expect Qt and Gtk's JavaScript engines to be better isolated than Chrome. They're just more avoidable.
nine_k 20 days ago [-]
> GL is only a drawing API. Then you need to handle fonts (layout, rendering)
Exactly. It should suffice. Render text on a texture using FreeType or, if you feel fancy, using HarfBuzz.
> input and focus (including compose and input methods), actual window management,
No, not for a circular menu which is 100% mouse-driven. It's much closer to a game than to a desktop app. It should be about as complex in its functionality as dmenu, driven by config files. An optional nice GUI configurator for it could be a self-contained web app.
> They're just more avoidable.
Exactly: it's harder to access them from non-programmatic context, e.g. from a maliciously crafted menu item or .desktop file. Or so I hope at least.
schneegans 20 days ago [-]
90% of Kando is not the menu itself, but the very complex WYSIWYG menu editor. For this you definitely need a framework.
But also the menu itself... I guess I could draw it using OpenGL. Proper antialiasing and font rendering will be tough, but not impossible.
Then I want transitions and animations. Have you implemented something like this before, where a user can quickly switch between various states, animations need to be aborted, restarted right in the middle and so on? It's awfully complex.
Then I want this to be themeable. Users should be able to completely define the look and feel of the menu. Themes in Kando can drastically change the way the menu looks and behaves animations wise. Why should I spend weeks or months implementing something like this from scratch even if it will never be as good as CSS?
And I haven't written about international font rendering, emojis, touch, stylus, or controller input so far. Plus you get extremely powerful debugging and performance analysis tools as part of the framework...
It all boils down to the question: Do I really want to spent months or maybe years reimplementing stuff which is already there just to save 100MB?
nine_k 19 days ago [-]
The more eye candy you want, the larger are the requirements. I compared it to dmenu or rofi, which offer little eyecandy, but allow for very simple and fast operation.
The GUI config utility can run anything fancy, a browser, an Unreal engine, etc. It runs at configuration time, and can be much more demanding than at an arbitrary menu use time, especially on a busy machine.
The problem is not the 100MB spent for a download. The problem is 100MB that need to be resident in RAM for the operation of the menu.
This only means that this implementation does not solve my problems. If it solves someone else's, it's unironically great. I wish the project to prosper.
amelius 20 days ago [-]
> Not an unjustified prejudice, but an unjustified spending of resources, when such resources are not always readily available.
Maybe it is still in the experimentation phase in which case spending more resources is 100% justified.
viraptor 20 days ago [-]
I wrote my own version of system-wide pie menu in swiftui in around 2 days (with no previous experience of swift), so I can say the tech/effort is not a limitation.
On the other hand, the performance/resources can't be really analysed in isolation. There's too many apps that say "everyone can afford 100MB app and 250MB of ram, right?"... then that menu app and that tiny updater and that printer helper and slack and dicord and VPN app add up and we're at 3GB of ram usage already. (Yes yes, some of it can be reclaimed temporarily and then swapped back from files... but we shouldn't need to in the first place)
v3ss0n 20 days ago [-]
Cute.. now let's see if it works on Linux, and then windows.
viraptor 20 days ago [-]
It doesn't. The point is that for tiny apps it doesn't matter - you can replicate that interface in 3 toolkits very easily.
Same applies to applications that want to display 3 edit boxes, an image and 2 buttons. Just do it in the native framework 3 times. It's not that much work.
schneegans 20 days ago [-]
Well, the WYSIWYG menu editor of Kando is one if the most complex nonstandard UI elements I have written so far. That's an aweful lot more than a few buttons.
Also, there is usually no ready-made pie menu widget in native frameworks. So you will have to draw the menu yourself with low-level shapes like boxes, circles, and text. If you want these to be themeable, if you want to have a powerful animation engine, and if you want that your scene is efficiently drawn even at high resolution with several hundreds of said shapes moving around your screen, things get quickly much more complex than you may think...
And soon you will realize that CSS and modern browser engines are exactly optimized for this.
exe34 20 days ago [-]
I have so many things open for several months at a time, I really don't want anything that doesn't optimise for usefulness per MB of ram.
v3ss0n 20 days ago [-]
Who the hell cares about 100mb while it gives cross platform rendering capabilities, high performance GPU support and stability?
You haven't tried other none web rendering engines and how many head aches it gives if you are saying this.
BeefWellington 20 days ago [-]
> while it gives cross platform rendering capabilities
This is useful primarily to the author, not the user.
This could easily be done cross-platform in a few other ways that don't require a full-fledged browser implementation.
> high performance GPU support
Browser GPU support is not high performance.
> and stability
Do you mean stability of execution, e.g.: not crashing? Or stability in terms of development target?
viraptor 20 days ago [-]
> You haven't tried other none web rendering engines
You responded to my comment where I did. I hate all the GUI frameworks the same and know a few of them. It's still unnecessary to use electron in a lot of places where it's used today.
madduci 20 days ago [-]
I personally care. And misusing a browser engine for this is just terrible.
It could have been a native UI application, there are many cross platform native UI frameworks out there, just saying
amelius 20 days ago [-]
But what if it actually was an improvement?
anon115 20 days ago [-]
u ever tried to build an app on tauri bro?
v3ss0n 20 days ago [-]
And do you realize that it uses system browser that you have zero control, which could even be worse than electron?
20 days ago [-]
that_guy_iain 20 days ago [-]
My feedback is "Be precise" tagline seems wrong. It makes me think I need to aim at small dots instead of just going in a direction.
danr4 20 days ago [-]
If you have a mac use charmstone.app
I cannot go back to life without it.
So maybe it could be converted to different formats...
oulipo 22 days ago [-]
yes, I was thinking more of having a kind of "dotfile" approach to all my configs for automation on macOs, as there are so many different overlapping apps like BTT, KeyboardMaestro, skhd, Kando, Alfred, etc
I'd love to have a `.automation` folder in my home where I can add descriptions of all my menus, keyboard shortcuts, scripts, Shortcut App scripts, BTT config, etc, and each time I modify them it updates in the app
It would be nice to have a kind of overview of all my automations
Also I'd like it that each file is some kind of "executable markdown" container which can contain textual description, images, etc, and the scripts/configs themselves, and the bindings
Something like this
--
name: emoji-picker
author: xxx
description: Various emoji-related bindings
version: 1.0
url: xxx
license: ...
--
```@deps
ts: mdex>=1.0,<2.0
```
```@deps test
// deps only for testing, etc
```
```@include
// can seamlessly include other .mdex, libs, code, repos, etc
```
# Open emoji picker
The Raycast emoji finder is clean and easy to use, so I'll use it instead of the system picker
```@code ts openPicker
const openPicker = async (prompt: string = "") => {
api.url.open(`raycast://extensions/emoji?prompt={prompt}`);
}
```
```@test
// define some code to run tests and ensure everything works
```
## Trigger on `fn` key
```@binding key
trigger: @on(platform == "darwin") key=[fn]
action: code openPicker @(openPicker();)
# equivalently, action: api open("raycast://...")
```
## When called as a CLI, allow to pass an optional prompt to the emoji picker
This installs an `emoji` cli, which parses with an optional prompt
```@binding cli
name: emoji
args: [prompt=""]
action: code openPicker @(openPicker(prompt);)
```
## Add custom bindings through extensions
```@binding ext:alfred
keyword: emoji [query=""]
action: code openPicker @(openPicker(query);)
```
## Every hour, refresh the emojis
```@binding cron
every: 1h
action: code openPicker @(refreshEmojiData();)
```
## Create an UI
```@binding ui
name: emoji-ui
layout: ...
html: ...
css: ...
```
## Usage:
```sh
mdex list emoji
mdex info emoji-picker
mdex install @user/emoji-picker
mdex install emoji-picker.mdex # install or refresh script, install deps, setup key-bindings
mdex test emoji-picker.mdex
emoji "clown" # cli
mdex uninstall emoji-picker
# or trigger the `fn` shortcut
mdex logs emoji-picker
```
klibertp 20 days ago [-]
The first thing I'd do would be to try to theme it with textures from Planescape: Torment...
Joking aside, I've been hearing that radial menus are bad UX for decades, but I never understood why. For me, it was always much easier to build muscle memory with menus like that vs. traditional ones.
philjackson 20 days ago [-]
Great docs and website!
v3ss0n 20 days ago [-]
I would rather type.. smart auto completion or just fuzzy search + recency based run boxes are far superior than remembering gestures
Beijinger 20 days ago [-]
"Kando is a cross-platform open source"
This normally means it is slow.
What does it do? It replaces my window manager? Or is an addition? I use the Moksha Desktop.
DonHopkins 20 days ago [-]
Simon, not only do you totally get the inherent advantages and joys of pie menus, and have the skills and persistence to implement them well and iterate on the design by continuously using and refining them over many years (at least a dozen years since you made trace and coral menus, right?), but you also have an impeccable sense of design and creativity, and they look really great!
And the best part is that you've implemented an easy-to-use elegant wyziwyg drag-and-drop editor so anybody can edit and design their own pie menus, without writing json, xml, or code. Which is extremely important because everyone has their own personal use cases and important commands they need to select quickly.
Thanks for all your work, and for making it open source, and going the extra mile to make it cross platform (which is extremely difficult)!
I've written about how much I like your previous work before:
I really love how the little nubs preview the structure of the sub-menus, and how you can roll back to the parent menu because it reserves a slice in the sub-menu to go back, so you don't need to use another mouse button or shift key to browse the menus.
That looks like a nice visual representation with a way to easily browse all around the tree, into and out of the submenus without clicking! I can't tell from the video if it's based on a click or a timeout. But it looks like it supports browsing and reselection and correcting errors pretty well! (That would be something interesting to measure!)
There's another useful law related to Fitts's law that applies to situations like this, called Steering Law:
The steering law in human–computer interaction and ergonomics is a predictive model of human movement that describes the time required to navigate, or steer, through a 2-dimensional tunnel. The tunnel can be thought of as a path or trajectory on a plane that has an associated thickness or width, where the width can vary along the tunnel. The goal of a steering task is to navigate from one end of the tunnel to the other as quickly as possible, without touching the boundaries of the tunnel. A real-world example that approximates this task is driving a car down a road that may have twists and turns, where the car must navigate the road as quickly as possible without touching the sides of the road. The steering law predicts both the instantaneous speed at which we may navigate the tunnel, and the total time required to navigate the entire tunnel.
The steering law has been independently discovered and studied three times (Rashevsky, 1959; Drury, 1971; Accot and Zhai, 1997). Its most recent discovery has been within the human–computer interaction community, which has resulted in the most general mathematical formulation of the law.
Also here's some interesting stuff about incompatibility with Wayland, and rewriting Gnome-Pie as an extension to the Gnome shell:
Hey Don, thanks for the kind words! And yes, with the latest updates we (and I can say "we" since various discord users collaborated on this) focused a lot on refining the "brand" of Kando. With the new website and the new logo, things are taking shape really nicely!
I am really proud if it because it fits so nicely.
The big next step will be to significantly improve the usability of the settings window. While the WYSIWYG editor is nice, it also has some issues which need to be fixed. It's always a full screen window (which is annoying) and it does not scale well to smaller screens.
jimmySixDOF 17 days ago [-]
Have you seen anyone port this to XR (VR/AR/MR) ? These radial menus are a good fit and a lot of designers work with them as a theme. Kando would be great in a library like Three.js or Babylon.js
I am running RPi OS with GNOME 43.9 and was wondering if you have a release build for Arm (Pi 5)?
Teever 20 days ago [-]
I wonder what HN user Don Hopkins thinks about this.
schneegans 20 days ago [-]
He replied already above :)
rickdg 20 days ago [-]
Tauri rewrite when
schneegans 20 days ago [-]
I tried using Tauri (would be very cool), but sadly they have severe performance issues on Linux which make an app like Kando impossible at the moment.
bella964 22 days ago [-]
[dead]
TripleChecker 22 days ago [-]
[flagged]
schneegans 22 days ago [-]
Thanks for the typo pointers! It uses DOM elements. This makes it really easy to develop themes with CSS. I also did some experiments with alternatives to Electron, but found that the advantages of Electron clearly outweigh the disadvantages in this case. Here is some background information: https://github.com/orgs/kando-menu/discussions/58
retrochameleon 21 days ago [-]
Thank you for addressing the Electron discussion thoroughly on Github. I am always very disappointed to see an application I am interested in using Electron. It is often enough of an issue for me to immediately write it off as something I will never use. I hope to see more Tauri instead, but you also addressed some minor issues about that option.
I'll have to play around with this application.
schneegans 21 days ago [-]
Yeah, Tauri would be great. But I think it will take quite some time until the fundamental rendering performance issues [1] under Linux can be fixed. There seem to be rough plans to bundle CEF on Linux [2], but AFAICS this seems to be only a discussion at this point.
If they are bundling cef then it is rebuilding electron
schneegans 20 days ago [-]
If I got it correctly, they would only do this on Linux to face the performance issues of the native webview. Also, there are ideas of a shared installation: https://github.com/chromiumembedded/cef/issues/3836
Kando is very pretty, and it can be fun to use an interface like this, but in terms of practicality, text inputs are better.
For example, on my desktop, there's an icon on my taskbar for Firefox, but most of the time, I get my screen to the search bar and type "F" and my system knows I probably want Firefox. Done.
There's a game I play, Astroneer, and it uses a pie interface. I often wish I could just type in what I want. It'd be faster.
I want to love this, but I can type on a keyboard so much faster, and use up so much less cognitive energy doing so than switching my hand to the mouse, pulling up a menu, reading the symbols (even if I have their location memorized) and pulling my wrist/arm in the right direction.
Especially when used for "creative" or "artistic" tasks (e.g. painting, video editing, 3D modelling, etc.) pie menus can really have a benefit because you have your hand at the stylus or at the mouse most of the time anyways.
It would be a bit easier to have a video on the homepage that is a whirlwind tour of the program rather than the latest changelog. Although I have a motivation to find it useful (using a stylus restricts keyboard use), I've already set up a Tartarus with Input remapper to act as custom shortcuts etc, and it seems complicated to find how it would simplify or improve my existing setup.
I think there's a lot of unjustified prejudice against using web technology for desktop applications...
It's like creating a really nice set of Christmas lights, which only comes with a complete car as a part of the package, because it's powered by the car's engine. Indeed, a car's engine is a really good, well-engineered engine, and it works everywhere. But often one would really appreciate a string of Christmas lights that works from a wall power socket, and is 1000x lighter.
I find Kando a brilliant prototype of a future useful tool, which would have the size, complexity, and attack surface commensurate with the functions it provides.
I want to use something like Kando, but probably not Kando directly yet. I also suppose that Kando's approach, and most of the code, can be reused in proper web apps.
So, it is not a question for car or not car, but SUV vs. compact, and several copies of the SUV at that as everything bundles the bloody thing. Normally I prefer static linking, but it's a bit much for a browser.
This is correct. But a menu does not need the entire set of capabilities of a toolkit like GTK4 or Qt6. It might take as much as Xlib or GL, which give you a way to draw simple shapes and text over a full-screen transparent window.
Most importantly, they usually do not include a bunch of things Javascript engines and even mere https clients, at least not easily accessible. (Though e.g. conformant XML parsers are always a hazard. And of course Qt6 does include a JS engine, but hopefully it's a bit more isolated.)
Things quickly become quite a lot less trivial than it initially seemed, and then you end up needing an actual toolkit.
You can certainly pick a more minimal one than a browser, but any application now requires a non-trivial toolkit.
> Qt6 does include a JS engine, but hopefully it's a bit more isolated.
I wouldn't expect Qt and Gtk's JavaScript engines to be better isolated than Chrome. They're just more avoidable.
Exactly. It should suffice. Render text on a texture using FreeType or, if you feel fancy, using HarfBuzz.
> input and focus (including compose and input methods), actual window management,
No, not for a circular menu which is 100% mouse-driven. It's much closer to a game than to a desktop app. It should be about as complex in its functionality as dmenu, driven by config files. An optional nice GUI configurator for it could be a self-contained web app.
> They're just more avoidable.
Exactly: it's harder to access them from non-programmatic context, e.g. from a maliciously crafted menu item or .desktop file. Or so I hope at least.
But also the menu itself... I guess I could draw it using OpenGL. Proper antialiasing and font rendering will be tough, but not impossible.
Then I want transitions and animations. Have you implemented something like this before, where a user can quickly switch between various states, animations need to be aborted, restarted right in the middle and so on? It's awfully complex.
Then I want this to be themeable. Users should be able to completely define the look and feel of the menu. Themes in Kando can drastically change the way the menu looks and behaves animations wise. Why should I spend weeks or months implementing something like this from scratch even if it will never be as good as CSS?
And I haven't written about international font rendering, emojis, touch, stylus, or controller input so far. Plus you get extremely powerful debugging and performance analysis tools as part of the framework...
It all boils down to the question: Do I really want to spent months or maybe years reimplementing stuff which is already there just to save 100MB?
The GUI config utility can run anything fancy, a browser, an Unreal engine, etc. It runs at configuration time, and can be much more demanding than at an arbitrary menu use time, especially on a busy machine.
The problem is not the 100MB spent for a download. The problem is 100MB that need to be resident in RAM for the operation of the menu.
This only means that this implementation does not solve my problems. If it solves someone else's, it's unironically great. I wish the project to prosper.
Maybe it is still in the experimentation phase in which case spending more resources is 100% justified.
On the other hand, the performance/resources can't be really analysed in isolation. There's too many apps that say "everyone can afford 100MB app and 250MB of ram, right?"... then that menu app and that tiny updater and that printer helper and slack and dicord and VPN app add up and we're at 3GB of ram usage already. (Yes yes, some of it can be reclaimed temporarily and then swapped back from files... but we shouldn't need to in the first place)
Same applies to applications that want to display 3 edit boxes, an image and 2 buttons. Just do it in the native framework 3 times. It's not that much work.
Also, there is usually no ready-made pie menu widget in native frameworks. So you will have to draw the menu yourself with low-level shapes like boxes, circles, and text. If you want these to be themeable, if you want to have a powerful animation engine, and if you want that your scene is efficiently drawn even at high resolution with several hundreds of said shapes moving around your screen, things get quickly much more complex than you may think...
And soon you will realize that CSS and modern browser engines are exactly optimized for this.
You haven't tried other none web rendering engines and how many head aches it gives if you are saying this.
This is useful primarily to the author, not the user.
This could easily be done cross-platform in a few other ways that don't require a full-fledged browser implementation.
> high performance GPU support
Browser GPU support is not high performance.
> and stability
Do you mean stability of execution, e.g.: not crashing? Or stability in terms of development target?
You responded to my comment where I did. I hate all the GUI frameworks the same and know a few of them. It's still unnecessary to use electron in a lot of places where it's used today.
It could have been a native UI application, there are many cross platform native UI frameworks out there, just saying
On osX BetterTouchTool can also do radial menus!
Would there be a way to import/export a menu configuration from your tool as a .json?
So maybe it could be converted to different formats...
I'd love to have a `.automation` folder in my home where I can add descriptions of all my menus, keyboard shortcuts, scripts, Shortcut App scripts, BTT config, etc, and each time I modify them it updates in the app
It would be nice to have a kind of overview of all my automations
Also I'd like it that each file is some kind of "executable markdown" container which can contain textual description, images, etc, and the scripts/configs themselves, and the bindings
Something like this
Joking aside, I've been hearing that radial menus are bad UX for decades, but I never understood why. For me, it was always much easier to build muscle memory with menus like that vs. traditional ones.
This normally means it is slow.
What does it do? It replaces my window manager? Or is an addition? I use the Moksha Desktop.
And the best part is that you've implemented an easy-to-use elegant wyziwyg drag-and-drop editor so anybody can edit and design their own pie menus, without writing json, xml, or code. Which is extremely important because everyone has their own personal use cases and important commands they need to select quickly.
Thanks for all your work, and for making it open source, and going the extra mile to make it cross platform (which is extremely difficult)!
I've written about how much I like your previous work before:
https://news.ycombinator.com/item?id=17106453
DonHopkins on May 19, 2018 | parent | context | favorite | on: Pie Menus: A 30-Year Retrospective: Take a Look an...
I'm very impressed by Simon Schneegans' work on Gnome-Pie: http://simmesimme.github.io/gnome-pie.html
And especially his delightful thesis work:
Trace-Menu:
https://vimeo.com/51073078
I really love how the little nubs preview the structure of the sub-menus, and how you can roll back to the parent menu because it reserves a slice in the sub-menu to go back, so you don't need to use another mouse button or shift key to browse the menus.
Coral-Menu:
https://vimeo.com/51072812
That looks like a nice visual representation with a way to easily browse all around the tree, into and out of the submenus without clicking! I can't tell from the video if it's based on a click or a timeout. But it looks like it supports browsing and reselection and correcting errors pretty well! (That would be something interesting to measure!)
There's another useful law related to Fitts's law that applies to situations like this, called Steering Law:
https://en.wikipedia.org/wiki/Steering_law
The steering law in human–computer interaction and ergonomics is a predictive model of human movement that describes the time required to navigate, or steer, through a 2-dimensional tunnel. The tunnel can be thought of as a path or trajectory on a plane that has an associated thickness or width, where the width can vary along the tunnel. The goal of a steering task is to navigate from one end of the tunnel to the other as quickly as possible, without touching the boundaries of the tunnel. A real-world example that approximates this task is driving a car down a road that may have twists and turns, where the car must navigate the road as quickly as possible without touching the sides of the road. The steering law predicts both the instantaneous speed at which we may navigate the tunnel, and the total time required to navigate the entire tunnel.
The steering law has been independently discovered and studied three times (Rashevsky, 1959; Drury, 1971; Accot and Zhai, 1997). Its most recent discovery has been within the human–computer interaction community, which has resulted in the most general mathematical formulation of the law.
Also here's some interesting stuff about incompatibility with Wayland, and rewriting Gnome-Pie as an extension to the Gnome shell:
http://simmesimme.github.io/news/2017/07/09/gnome-pie-071
I've written something about the new logo and icon here: https://ko-fi.com/post/A-New-Icon-for-Kando-X8X317HVLF
I am really proud if it because it fits so nicely.
The big next step will be to significantly improve the usability of the settings window. While the WYSIWYG editor is nice, it also has some issues which need to be fixed. It's always a full screen window (which is annoying) and it does not scale well to smaller screens.
Here are two people experimenting with radials in XR: https://x.com/Volorf https://x.com/dmvrg
I'll have to play around with this application.
[1] https://github.com/tauri-apps/tauri/issues/3988 [2] https://github.com/tauri-apps/wry/issues/1064