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...
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.
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.
Maybe it is still in the experimentation phase in which case spending more resources is 100% justified.
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.
You haven't tried other none web rendering engines and how many head aches it gives if you are saying this.
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?