Show HN: Kando – A cross-platform pie menu for your desktop | Hacker News Reader

Show HN: Kando – A cross-platform pie menu for your desktop

kando.menu

102 pointsschneegans53 comments

Kando is a cross-platform open source pie menu which I am currently developing! It offers an unconventional, fast, highly efficient, and fun way of interacting with your computer! You can use it to launch applications, simulate keyboard shortcuts, open files, and much more. Let me know what you think about it!

Open articleView on HN

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.

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

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.

Rofi has that search to match but iant a pie menu

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.

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.

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.

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.

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.

You think so? I experimented with several toolkits. Some of my thoughts I wrote down here: https://github.com/orgs/kando-menu/discussions/58

I think there's a lot of unjustified prejudice against using web technology for desktop applications...

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)

Cute.. now let's see if it works on Linux, and then windows.

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.

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.

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.

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.

> 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.

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.

> 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.)

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.

> 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.

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?

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.

u ever tried to build an app on tauri bro?

And do you realize that it uses system browser that you have zero control, which could even be worse than electron?

But what if it actually was an improvement?

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.

> 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.

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

> 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?

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.

If you have a mac use charmstone.app I cannot go back to life without it.

Another macOS native pie menu is https://www.pie-menu.com

Really cool!

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?

Thanks! All menus are actually stored in a JSON file. The format is documented here: https://kando.menu/config-files/

So maybe it could be converted to different formats...

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
    ```

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.

Great docs and website!

"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.

I would rather type.. smart auto completion or just fuzzy search + recency based run boxes are far superior than remembering gestures

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:

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

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'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.

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

Here are two people experimenting with radials in XR: https://x.com/Volorf https://x.com/dmvrg

I am running RPi OS with GNOME 43.9 and was wondering if you have a release build for Arm (Pi 5)?

I wonder what HN user Don Hopkins thinks about this.

He replied already above :)

Tauri rewrite when

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.

Reply on news.ycombinator.com