Show HN: Kando – A cross-platform pie menu for your desktop (kando.menu)

I'll have to play around with this application.

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

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

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)

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.

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

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?