:: [DNG] Menus: Was: What not to back …
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: [DNG] Menus: Was: What not to back up
Olaf Meeuwissen said on Wed, 24 Nov 2021 20:39:18 +0900

>Hi,
>
>Steve Litt writes:


>> * The UMENU2 menu structure.
>
>I have no such thing as far as I am aware of.
>Don't even know what UMENU2 is :-?
>
>Ah, http://troubleshooters.com/projects/umenu2/ explains. Don't have
>it, then. For my needs, dmenu and *sh-completion suffice.


As far as I'm concerned, dmenu is an absolute must for all
touch-typists. I use dmenu about 100 times a day to launch programs. I
use dmenu in vertical mode, taking its input from the executable path,
to choose what to run. With 3 to 5 keystrokes you can run any program
you want, without ever reaching for the mouse.

Unfortunately for me, dmenu is made with direct-to-X calls, no Gtk, no
Qt, no xforms, no tk, just calls to X. What this means is that when I'm
finally forced to move to Wayland, dmenu stops working. At that time
I'll need to go into the dmenu source code, replace all X calls with
calls to a layer of abstraction, and code that layer to work with
Wayland. The dmenu source code is pretty ugly because it's a mish-mash
of list handling plus X calls almost completely mixed together. I
know this because I once tried to make a CLI (or maybe nCurses) version
of dmenu and failed.

I haven't used it too much this way, but dmenu is also an outstanding
input facility for shellscripts. You can type in a value and capture
its value, or pick a value out of a list, or a little of both. Dmenu is
one of the best applications I've ever come across. It's a work of
genius.

What UMENU2 adds to the mix is the ability to run whole command lines,
including arguments, even with the possibility of UMENU2 querying for
those arguments. UMENU2 shines in the following situations:

* Command lines you don't use enough to memorize
* Command lines you use so often you want to reduce keystrokes
* Front ending a lots-of-possible-arguments executable to make it user
friendly.
* Creating a simple, menu driven application from UMENU2 internal
shellscripts, or from a shellscript DSL (Domain Specific Language).
* Working remotely over a slow network line.

Unfortunately, UMENU2 is, as systemd aficionados would say about other
init systems, "not ready for prime time" because specifying menus and
commands is not easy. Right now you have to do these specifications
with a file manager or with a couple of programs I wrote, but none of
this is all that simple. Some day, when I retire, I'm gonna add a
"config mode" to UMENU2, so that you can do specifications within the
UMENU2 work environment, so everything will be prompted and
discoverable. But that's at least a week's work, and I have books to
write in order to pay the rent.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques