Here are some thoughts about a menu redesign.
One goal is to have a uniform UI element that allows us to (1) close menu and (2) go up to a parent menu. This UI element should work from ssh and dwm/sway.
Another goal is to split up our massive sxmo_hook_contextmenu.sh into smaller and more manageable chunks. This will save some headache if someone customizes a small bit of menu and has to run sxmo_migrate.sh all the time (as is the case now).
One idea I currently have is something like this.
menus/main/sxmo_menu_main.sh menus/main/dialer/sxmo_menu_dialer.sh
We use lisgd swipe down to close menus and lisgd swipe up to go back up in the menu tree. But this won't work on ssh!
For ssh, we could populate the bottom two entries of every menu with "Close" and "Previous" --- a user can then use the narrow-as-you-type option in ssh to access these easily. They won't clutter up the UI for dwm/sway either since they'll be at the bottom.
Anyway, some thoughts for now. I can already think of problems.
Was looking into this, I suspect all the work I have been doing has been in vain but.
This line:
^ 0 ^and this^ 1 ^Has special meaning doesn't it? Ive been using the write_line function to print the lines out but modifying to be
iconfunction.Might take a pause on this until that part gets clarified. (As I've reached 40% through sxmo_hook_contextmenu.sh)
It means return to menu when done (or not)
Might be easier to start from scratch now.
That's put a dampener on my motivation.
On Mon, May 08, 2023 at 07:41:20PM +0000, ~hazardchem wrote:
Might be easier to start from scratch now.
That's put a dampener on my motivation.
Sorry!
Yeah, when I think about it, we already have a pretty solid system going in sxmo_appmenu.sh, it'd be a shame to scratch it and go with something else. We just need some more consistency and the ability to go "back" up a directory level.
-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)
Don't need to apologise! I should have checked first haha.
I wasn't trying to change things, was using the printf line from one of the scripts:
write_line() { printf "%s ^ 0 ^ %s\n" "$1" "$2" }And was removing the ^ 0 ^ or ^ 1 ^ so that will output. Thinking I might just printf each line without changing anything, will make things a lot quicker to modify. Can just use sed to append echo or printf to each line to automate it.
Once I pulled out the arguements for each CHOICE in sxmo_hook_contextmenu.sh I was calling a script called sxmo_menu_{case or elif call}.sh in it's stead.
I have started to address this with splitting up contextmenu.sh in this patch: https://lists.sr.ht/~mil/sxmo-devel/patches/41079
Apologies for being late to the party, but I wanted to make the participants aware of three patches to bemenu that may be useful in a rework of the menu system, available at https://git.sr.ht/~tetrakist/bemenu
a2785d86: adds the --dual option
This enables a dual-line mode in which each entry consists of two lines, the first being the displayed menu item, and the second being the returned value. I believe this has value because first, it allows us to encode more state in the menu item, rather than the menu (which should simplify the menu code somewhat) and second, it permits multiple lines in the menu to display the same text, but which performing different tasks. A trivial example being volume up/down items for multiple audio outputs (assuming a header menu item above each set of device actions).d6144605: adds the --exec [yes|no] option
This indicates whether the selected menu item (or its "value" in the case of --dual) should be executed. This offers the possibility of avoiding looping back through the menu shell code to execute a command, should that be useful.2a139647: adds the --selected-index option
This returns the numerical index of the selected menu item, rather than its text or value. This option is currently ignored if --exec=yes is set.The intent of these patches is to permit further simplification of the menu shell code and improve the overall flexibility of the menuing system. The patches are all quite minimal and would hopefully be easy to upstream if the maintainer is amenable.
NB: it has been a while since I wrote these, so rebasing against the official tree may be necessary. I haven't checked yet.
--tetrakist
Thanks for that tetrakist, they do look good!
My only question is how are would that be to merge with dmenu? As we wouldn't want to make something that only works on wayland based compositors.
I think it would be less resources for sxmo to not manage something else as well so upstreaming would be a great idea if they will accept it.
I really like this idea of the menu structure mirroring the directory structure. Reusing the filesystem to store state, which can just as easily be modified.
On the topic of merging with dmenu: don't. dmenu is for x11, slmenu (dead, lives on in the fork vis-menu[1]) is for the terminal, and bemenu chooses to support multiple. Users can decide which one they want.
I just had a play around with vis-menu, works really nicely!
Did see it outputting double strings but it could be a visual glitch.
echo '1' | sed 's|$|\n2\n3\n|' | vis-menu
Gives choices like below: 1 2 3
And once you select something: 11 1
But if its stored as a variable it is a single digit output so must just be a visual glitch.