[arghwhat]

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]

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

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]

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

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]

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.