Didier Kryn said on Mon, 25 Dec 2023 18:48:13 +0100

>Le 25/12/2023 à 04:52, Steve Litt a écrit :
>> As far as launching apps, the way I do it is with dmenu from Suckless
>> Tools. If you're a keyboard kinda person, dmenu is by far the fastest
>> and most efficient way to launch apps.
>Le 24/12/2023 à 21:27, Gianluca Zoni via Dng a écrit :
>> over a decade ago I started using StumpWM. Desktop environments
>> are a waste of time: you have to gesture to make yourself
>> understood by the computer, when we can talk to it or give it the
>> right commands by typing key combinations in a single "musical
>> chord" on the keyboard. StumpWM is programmable and integrates
>> seamlessly with Emacs, Mutt, Conkeror, ... especially because
>> over the years I've built an entire system of scripts and
>> programs that I call the "zigzag system".
>
>     You both, what you achieved is the result of a lot of
> configuration
>and scripting work. Instead, any DE works almost fine out of the box
>and is configurable through a menu.

Yes, but...

I'll elaborate later in this email.

>
>     I think the general answer to the original question is that
> heavily
>using menus is less efficient than heavily using command-line,

I believe the opposite: I'm a huge fan of menus, for beginners and pros
alike. I'm the author of the UMENU and UMENU2 menu systems.

> but, on
>the other hand, a menu is self-documenting, therefore, more efficient
>for applications you rarely use.

Pre-Cisely!!! Menus rock!


>For example, a terminal emulator is
>the very interface for command-line, but do you like to spend days in
>customizing its apearance? No, this very task you do only once is more
>efficiently done through a menu.
>
>     In Xterm, everything is configurable through one zilion
>command-line options, which, in practice would imply to RTFM and write
>one's own script to start it, because it does not read a config file.
>Konsole, Gnome-terminal or Xfce4-terminal, what more are they than
>front-ends to Xterm with config files and menu-driven configuration.

Even though I don't use a Desktop Environment, I use lxterminal and
xfce4-terminal and Sakura regularly. I never did learn the ins and outs
of xterm.

>
>     For what regards Dmenu, in all DEs there is an application menu
> for
>all applications which are "integrated" in the Freedesktop sense,
>which just means they come with a .desktop file stored in
>/usr/share/applications/ .

I never knew that.

> Do you, Steve, find it feasible to
>automatically read all the .desktop files in /usr/share/applications/
>and build a Dmenu tree for all of them?

I could certainly do it no problem, but it's just not an itch I need to
scratch.

> Each .desktop file includes a
>"category" which drives the structure of the menu as a two-level tree.
>I think this kind of tool might boost the adoption of Dmenu.

Why only two levels? Why not indefinite? UMENU2 handles an indefinite
number of levels. Unfortunately, the guy who wrote UMENU2 (me) didn't
(yet) bother to make it easy to configure (by adding a configuration
mode), so I can't recommend it to most people.

Back to your original distinction between a lot of configuration and
working fine out of the box, configurable with a menu...

First of all, I'm a huge fan of menus. I hated it when Gnome and Unity
dispensed with menus in favor of Chicklets. And as somebody who must
maintain his wife's Windows box, I hate the Windows' Chicklet
interface. Menus are the way to go.

And of course you're right. My system took a lot of configuration, and
more than a little significant scripting. Once!

As one example, about 15 years ago I wrote a program to convert a tab
indented outline into a multi-level list of links (bookmarks). This is
where all my bookmarks are. None is in a browser. I can switch browsers
at the drop of a hat and have my (huge) outline of bookmarks. Using
Unbound, I've made them available across my LAN. http://littlinks.cxm .
This code is in my data directories, safe from overwrite by the
packaging system. Basically, I can install any Linux distro on any
hardware, tree copy my /d and /home directories, and have all my menus
and scripts to the point where, regardless of distro or WM or DE, my
workflow is the same.

For maybe 15 years I've used my Python script called makeHtmlToc.py,
that takes a well formed HTML file, and creates a table of contents
based on all the id's of the <h1> tags. A lot of my work is HTML
authoring, so this has saved me tremendous amounts of time and errors.

Was making this stuff a lot of work? Of course it was. But it was done
once. Meanwhile, I've had distro after distro go bad on me. First
Redhat back when Redhat was good, then Caldera for an easier install,
then Corel when anticipating using Linux as my daily driver, then
quickly Mandrake/Mandriva when Corel became about the dollars. Because
Mandrake/Mandriva was always a little shaky and sketchy, I switched to
Ubuntu for several years until Ubuntu's training wheels became a real
problem for me, then I switched to Debian just in time for the systemd
thing, and then switched to Void Linux. It would have sucked to redo my
workflow every time.

Likewise, I started with fvwm which was just too much for me to handle
at the time, then I switched to KDE until KDE's bloat slowed and
crashed my computers. Next was IceWM, which would have been great
except that its start menu was miserable to deal with and I didn't yet
know about dmenu. So I switched to Gnome3, which was great until it
became Gnome4, and I switched to Xfce, which worked great on OpenBSD
but was glitchy and intermittent in (Ubuntu, I think) Linux. Then came
LXDE, which is spectacular, but when I discovered dmenu I decided to
save some screen real estate and go strictly Openbox. From the moment I
discovered dmenu, my workflow has remained constant, except that when I
wanted to improve it, I did.

Not everybody's like me. Some haven't had so many distros implode on
them as I have. Some refuse to do a little shellscripting and
Pythonning. But I contend that whether you go in and menu-configure
changes every time you switch distros or DEs or somebody comes out with
a new version of something, as opposed to biting the bullet and
hand-assembling programs *once* that do one thing and do it well, tying
them together with shellscripts and the occasional Python program, over
the decades it's about the same amount of work.

One other thing that's different about me than some others. I'm a touch
typist who hates reaching for the mouse. Which is why I use the
qutebrowser browser so much. It's why I use dmenu and UMENU2. It's why
I use Vim (not as opposed to Emacs, but as opposed to several mousy
editors). My observation is that DE key-combos are really hard to
remembers, so I end up using the mouse, which slows me down immensely.
If I enjoyed using a mouse more than a keyboard, I'd probably use a DE.
My setup would be silly for those who prefer to use a mouse, or who
can't type at least 25 words per minute.

I'm attaching a screenshot of UMENU2, a CLI program I created that
I usually run in a terminal emulator. Like I said, I don't recommend it
because of the difficulty of building and maintaining your menu system.
I should create a configurator tool or configuration mode. But for me,
it sure comes in handy, even with this disadvantage. Note that the
ellipses indicate a choice is a menu instead of a command, and a carat
indicates that the choice goes back up to the previous level, or if at
the top level exits UMENU2.

SteveT

Steve Litt

Autumn 2023 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21