3 ms·

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

You think so? I experimented with several toolkits. Some of my thoughts I wrote down here: https://github.com/orgs/kando-menu/discussions/58 https://github.com/orgs/kando-menu/discussions/58 I think there's a lot of unjustified prejudice against using web technology for desktop applications...

viraptor 2y ago
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)
- v3ss0n 2y ago
  Cute.. now let's see if it works on Linux, and then windows.
  - viraptor 2y ago
    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.
    - schneegans 2y ago
      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.
exe34 2y ago
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.
nine_k 2y ago
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.
- amelius 2y ago
  > 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.
- arghwhat 2y ago
  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 2y ago
    > 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.)

viraptor 2y ago

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)

v3ss0n 2y ago
Cute.. now let's see if it works on Linux, and then windows.
- viraptor 2y ago
  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.
  - schneegans 2y ago
    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.

exe34 2y ago

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.

nine_k 2y ago

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.

amelius 2y ago
> 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.
arghwhat 2y ago
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 2y ago
  > 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.)