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.
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
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.
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.
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)
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 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.
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.
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
```
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
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.
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 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
Over the past year, I have been developing Kando. 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. It now runs on Windows, macOS and most Linux desktop environments.
I hope you enjoy Kando as much as I enjoyed developing it!
Exactly this. And in addition, I think there's lots of potential for touch screen users. As soon as you do not have easy access to a physical keyboard, pie menus can provide a great alternative to keyboard shortcuts.
When you press-and-hold, the menu pops up, and you swipe in a direction for an action. Think of it more as gesture navigation with an on-screen aid to show you what gestures you can do.
There used to be a thing nearly a decade ago to do this on Android, before the current gesture navigation:
touchscreens don't have to be small. one of the only pie menus I can really think of in the wild is Adobe Illustrator on iPad, which is relatively interesting because its an "ipad first" app of sorts. its separate than their desktop apps, and was designed for the larger tablets, not a small phone.
the menu itself is pretty good, especially with the Apple Pencil, which you'd be using to draw on the iPad. Image editing/3d modeling software tends to need a lot of UI, and I think it makes sense for the most part. these tools are hopefully used by everyone. that means more sporadic use — if I'm only opening your app a couple times a week for a couple minutes, I probably won't remember the keybaord shortcuts. not to mention people who are unfamiliar or don't use keyboard shortcuts at all. anyways, bit of a rant since it doesn't answer your original question, but we should consider how to make our computers computable by all users.
I am more thinking about tablets and convertibles. But even on a phone a similar concept could work: You summon the menu with some kind of gesture (for instance dragging over a screen edge). The menu pops up in the center of the screen and you can select an item with just a single directional swipe. If the selected item is a submenu and contains some child items, it will slide to the center of the screen and you can do another swipe to select one of the children.
So you could select an item extremely quickly with just two swipes. And there are already quite a few items at level two! If your top-level menu has eight submenu items and each submenu again contains seven items (+one to go back to the root) you have already 56 possible items in this menu. And you could select one of them in well beyond a second, even without looking at the screen!
