Submenus and sliders

[dCo3lh0]

When you activate a pie menu, you have options, but what if those options are in fact submenus, like lets say Pie-Menu > Random Category > dozens of options.

In a new pie menu using random category as center. Thats it.

Another one is Sliders, you could have a slider attributed to two hotkeys which would increase or decrease a slider. But what if programs from now on instead of execute functions by hotkey, you attribute a function script with a value, for example, lets say.

blender --brush-size=X

so the pie menu will have New function:
Binary: /path/to/binary
Arguments: --brush-size={X}
Value Range {x}:
Minimum Box: 0
Maximum Box: 100 (355. 1000, 10000,55 (whatever)).

Just rambling here, than you would have a slider: that could be:
a circle slider around the icon, a flat slider with a toggle, ooooor, center of icon minimum value holding mouse click and going away from the function icon circle increase value.

[Schneegans]

Hey there! While I do not plan to add such a feature to Fly-Pie, I have planned this for my follow-up project. Ken-Do will be a cross-platform pie menu for which I plan to add check-boxes, radio-buttons, and sliders. You can read more here: https://ko-fi.com/post/Introducing-Ken-Do-L3L7L0FQ2

[dCo3lh0]

i've seen you will use electron and rust for it, have you seen that Pop_OS are using a framework called iced with rust for their new system? Its a outsider competition to GTK and Qt, and their purpose is the same to be cross platform as well, look it up, there is slint as well.

Iced: A cross-platform GUI library for Rust
https://iced.rs/

Slint: The Rust GUI Toolkit
https://slint.rs/

[Schneegans]

I have considered using various toolkits. I did a thorough test using Rust+Gtk4 and looked into iced, slint, tauri, and Qt. All of them could be used, I guess (maybe with the exception of tauri which is currently very slow on Linux).

So why did I choose Electron? Here are some potential drawbacks I considered:

• Large application bundle size. The package will be around 100MB. With the other toolkits I may squeeze it into 20MB or so.
• Large RAM usage. Maybe about 150MB with Electron and 50MB with the others.
• You find many people arguing that Electron apps have a worse performance when compared to native applications. I did some tests and I found that especially the 2D rendering of many animated shapes (which is very important for Ken-Do) is extremely well optimized. It performed similar to Qt for me. I would expect a superior performance of native toolkits when it comes to large data processing, however this is not required for Ken-Do.

On the flip side, there are a couple of advantages which all boil down to one key advantage: Much higher development speed with Electron. I only have about one hour / day to spent on my open source projects. So this is extremely important! I am sure that I will be able to create a first working prototype in a couple of months using Electron while it would take me definitely more than a year using the other toolkits. Here are some of the reasons:

• Hot-reloading. Edit a source file and the running app will instantly reflect the changes.
• CSS transitions. Setting up rich and fluent animations is done with just a few lines if code. And it will be very easy to support custom themes. Thus would be waaaaay more complicated using the other tools.
• Huge ecosystem and excellent documentation.
• Easy bundling and publishing. With Electron, I can easily create packages and installers for various distributions. Have you tried creating a windows installer with auto-update functionality? Or a flatpak package? All of this takes a lot of time if done from scratch.
• Last but not least, I would have to learn Rust (or Python+Qt). While this is no problem in itself, it will take time as well.

In addition, there are a couple of other benefits of Electron:

• Very large user base which could contribute plugins and themes. I am sure that there are much more developers confident in JavaScript and CSS than in Rust or Qt.
• Portability to other platforms: The menu rendering code of Ken-Do will be encapsulated into a node module. This way you could easily integrate pie menus for instance into games which use the chromium embedded framework for ui rendering.

So I think that it is well worth the couple of MB's. Else there would be a very realistic chance that Ken-Do would never exist.

Do you see another drawback of Electron except for the couple of MBs?

[dCo3lh0]

None, i just thought that as you said electron for being web-based have worse performance compared to Qt and GTK, maybe thats a preconception of me because I've heard it as well, that's all i thought of. Nothing much.

[ghost]

Hi @Schneegans! That's for continuing work on Ken-Do! Just curious, but will this be portable to the XFCE environment? Also, can you link the repository so that I can have a look at what code you are working on?

Just asking, but between javascript and rust, what is a better language to learn?

[Schneegans]

The repository is here: https://github.com/kando-menu/kando. I am currently testing this on GNOME, KDE and Windows. I would love to get some feedback regarding other environments! In theory, it should work without issues on most X11-based environments.

Regarding the languages... I think there is no definitive answer. It all depends on your goals and applications. IMHO JavaScript is much easier to learn but with Rust you will be much more of an "expert" (everybody can code in JavaScript 😛).