octotep / menugen Goto Github PK

Autoselection is in the spec, but is currently unimplemented. Autoselection would make navigating menus much quicker and easier.

Attempts to run menugen from other directories (including, for example, double-clicking the helloworld example) fail because line 31 of menugen expects menugenbase to be in the current directory. A patch that seems to work is changing line 31 to source $(dirname "$0")/menugenbase.

Rofi is great, but having this functionality in the terminal as well would be a huge plus!
(Also the terminal is a bit more portable)

fzf is a great, cli-based selector which functions similarity to rofi and would allow to run menumaker scripts in the shell.

Ideally menumaker should abstract any differences and provide a consistent interface between the two selector applications so that menumaker scripts can remain agnostic about which application they support.

This would be a nice touch, but is not immediately necessary.

Right now, menumaker complains that the input (which doesn't exist in the menu) has an unknown type and exits. menuaker needs a way to handle custom input.

Creating a separate tool which makes sure menumaker scripts are valid could potentially ease development and bug squashing. Some things to check:

• The script has a "main" menu
• Every begin statement has a matching end statement
• The end statement comes after the begin statement
• Every menu has a name (might be tricky)

Currently, menumaker uses fzf for its CLI interface and rofi for it's GUI interface.

rofi, while the most featureful dmenu clone I've seen, only works on linux, which is a huge drawback. (I don't think window GUI support would be appropriate, since there's no bash).
fzf works on both linux and OS X, but cannot work in cygwin (for windows).

It would be nice to find completely cross platform tools.

Other applications to look into:

• selecta
• heatseeker

It would be nice to instruct menumaker to print additional information about what it's receiving. This should help debugging scripts.

Hi,
This tool looks very cool, despite I just started tinkering with it.

I was curious of the formatted output generated but seems too difficult for me to manage catching such output...
Instead, do you think it could be possible to merge the 3 files used ? It would permit advanced configs for each created script.

I was thinking of cutting and pasting the menugenbase in the menugen(cli) but have no idea how to merge script...

I might end in duplicating the menugen files...

menumaker works great for small demos, but I need to test the viability of creating a larger script with it. A good POC would be to reimplement some already existing scripts to see what works well and what feels awkward/difficult.

Right now, fzf will not auto select a item even if there's only one left (using --select-1).

I am unsure of whether this is a bug in menugen, or a shortcoming of fzf

The API document should document all functions and variables which are reserved/exposed to the user.

It is my ultimate goal for menugen to run on OS X, however a few oddities prevent that.

1. bash is ancient. menugen requires at least version 4.0 for hash tables in bash. It also currently requires bash 4.2+ because of its declare -g statements, but they might be redundant. I will investigate that.
2. md5sum doesn't exist. You can install it via Homebrew with brew install md5sha1sum
3. Some sed commands might not work due to the difference between BSD utils and GNU utils. This might actually be fixable if reported. Alternatively, one could just install GNU sed.

Also rofi doesn't support OS X - only the CLI interface with fzf works.

Right now, there are very few menu options that can be set. It would be nice to expose more rofi options, either in the form of more variables, or a flags variable, which rofi will then use.

fzf does not support custom input. It would be nice if I could figure out a way to get the query from fzf in the event of no matches

Due to the current organization of the program, the "back" menu items are added before the menu's options are read. A good workaround would be to expose a series of append_* API calls.

For a program with many menus and options, it would be nice to start partway through it to cut down the time spent navigating.