Troubleshooters.Com
Presents
|
Linux Productivity
Magazine
Volume 2
Issue 8, August 2003
UMENU
|
Copyright (C) 2003 by Steve Litt. All rights reserved.
Materials from guest authors copyrighted by them and licensed for perpetual
use to Linux Productivity Magazine. All rights reserved to the copyright
holder, except for items specifically marked otherwise (certain free software
source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes
all risk and responsibility for any outcome.
[ Troubleshooters.Com
| Back Issues |Troubleshooting Professional Magazine
]
Heck, if I get 50 people wanting it,
I'll make the menu program myself.
-- Steve Litt (predicting the future in the April 1998 Troubleshooting
Professional Magazine)
|
CONTENTS
Editor's Desk
By Steve Litt
Are you better off than you were four years ago? Every four years this question
makes or breaks a president.
Now let me ask this question: Are you more productive on your computer than
you were 15 years ago? Is your current spreadsheet faster to use than Lotus
123 for DOS, or is it just prettier, mousier and more of a memory hog? Is
your current word processing software more productive than WordPerfect 5.1
for DOS or Wordstar for CPM, or do you waste inordinate time reaching for
a mouse?
15 years ago we worked with 10 nimble fingers -- today it's 1 clumsy arm.
We've come a long way, baby!
Don't get me wrong. Mice are productive for operations like huge selections
and aligning elements on a drawing. But for character based content, and
especially for picking choices from among alternatives, they're a productivity
black hole. Menus are great interfaces, but mice slow them terribly. That's
why UMENU exists.
UMENU is a keyboard driven menu system capable of running on a console, or
even a teletype printer. It's lightweight, touch typist friendly, and runs
on any UNIX clone, including, of course, Linux. Better yet, with the addition
of the EMDL to UMENU converter, it's probably the quickest menu system to
configure, or more importantly, reconfigure.
Consider the cost of using a mouse menu. How many keystrokes can you press
in the time it takes to reach and grab the mouse, and then reseat your hands
on home position? How many keystrokes could you press in the time it takes
to hover or click a choice with a mouse?
This issue of Linux Productivity Magazine discusses UMENU -- how to use it,
how to configure it, how to install it, and how to benefit from it. If you
want the technical nitty-gritty of UMENU and its Rapid Menu Development companion,
EMDL, the URL's are in the URL's section of this magazine.
So kick back, relax, and contemplate the difficulties and opportunities of
exidus from Windows XP. And remember -- if you enjoy, use, or write Open Source
software, this is your magazine.
Help Publicize
Linux Productivity Magazine
By Steve Litt
Loyal readers, I need your help.
For months I've publicized Linux Productivity Magazine, expanding it from
a new magazine to a mainstay read by thousands. There's a limit to what I
can do alone, but if you take one minute to help, the possibilities are boundless.
If you like this magazine, please report it to one of the Linux magazines.
Tell them the URL, why you like it, and ask them to link to it.
I report it to them, but they don't take it very seriously when an author
blows his own horn. When a hundred readers report the magazine, they'll sit
up and take notice.
Reporting is simple enough. Just click on one of these links, and report
the magazine. It will take less than 5 minutes.
If you really like this magazine, please take 5 minutes to help bring it
to a wider audience. Submit it to one of the preceding sites.
Using UMENU
By Steve Litt
This article assumes that you've configured your window manager so that Ctrl+9
instantiates UMENU. How to so configure your window manager will be discussed
in the next article, Installing UMENU.
When you press Ctrl+F9 the main menu comes up, as shown below:
You'll notice a few points about the preceding menu. The line with the asterisks
shows the menu's title (Main Menu in this case), as well as the menu's letter
string (s in this case). Below that line are a series of lines defining choices.
Each line has a letter to press, and text describing the choice. All but
the bottom choice (eXit) are preceded by elipses (...). The elipses denote
that this choice is itself another menu -- a submenu. The eXit choice is
set to return you to the operating system, terminating the menu system. The
following screenshot shows the result of pressing the I key:
The preceding has several distinctions from the main menu. First, the title
is different. Second, the menu's letter string is now two characters long
(sI instead of just s). The I represents the key you pressed to get into
this menu. Also, you'll notice that some of the choices have elipses and
some don't. Those that have elipses will bring up yet another submenu, while
those without elipses will run the appropriate app, or return to the calling
menu in the case of the Quit choice. The following screenshot shows the result
of pressing the B key:
In the preceding, there are no submenus, as shown by the absense of elipses.
The menu's letter string is sIB, meaning you got there by pressing I then
B from the main menu whose menu letter string was s. The following screenshot
shows the result of pressing the G key:
The menu spawned the browser, and then the menu terminated. This is one of
many ways you can configure UMENU to behave:
Behavior
|
Command line argument
|
Choice properties
|
Comment
|
Menu returns after spawned program termination
|
none
|
|
This is a persistent menu, and is typically used when
UMENU is the primary shell. This can be done to "lock" the user out of the
operating system, and is also helpful when not multitasking.
|
Menu does not return after spawned program termination
|
--terminate
|
|
This is your typical "start menu". You don't want used
menus cluttering up the desktop, so it's best to destroy them. Best choice
on a GUI system.
|
Spawned command line app runs in same window as UMENU.
A new menu appears on command termination
|
|
C: command
|
This is typically how you run command line apps from
UMENU.
|
Same as above, but a new command does not appear on
command termination
|
|
C: command
S: 1
|
The S: 1 causes UMENU to wait for a keystroke before
repainting the window with a new menu. This is essential when you want to
read the output of the command.
|
Spawned command line app runs apart from UMENU window,
but UMENU stops while spawned command runs.
|
|
C: xterm -e command
|
There is typically no reason to do this.
|
Same as above, but UMENU is fully functional while
spawned command is running:
|
|
C: xterm -e command
B: 1
|
This is typical of how you configure persistent menus
(not start menus).
|
Spawned GUI app
|
|
C: command
B: 1
|
The command runs, the menu remains functional. Note
that if UMENU was started with the --terminate argument, UMENU terminates.
In such case, had you not included the B: 1, in most cases the spawned
app would have terminated along with UMENU.
|
Spawled GUI app, alternative to above
|
|
C: nohup command &
|
Use this if the B: 1 doesn't work -- sometimes
this alternative will. However, the B: 1 is preferred. |
My UMENU menu system has 304 commands in 5 menu levels. UMENU is capable of
easily running huge menu systems.
Installing UMENU
By Steve Litt
UMENU is a Perl program. It, and all its configuration files, are stored in
a single directory. This article discusses the "standard" way to install it
-- there are many more ways.
The first step is to download UMENU. Get it from Troubleshooters.Com (see
URL's section). As of August 2003 the current version is 0.6.1. Downloadumenu-0.6.1.tar.gz,
into your home directory, then untar it to produce a umenu directory below
your home directory. Do the following, noting that it could very likely produce
an error:
cd $HOME/umenu/program
./umenu.pl x
It's very likely the preceding will produce an error something like the following:
[slitt@fester program]$ ./umenu.pl
Use of uninitialized value in pattern match (m//) at OS.pm line 173.
Use of uninitialized value in pattern match (m//) at OS.pm line 164.
Can't exec "ver": No such file or directory at OS.pm line 181.
dia ver =><
Fatal Error OS.pm: Cannot determine operating system! at OS.pm line 158.
[slitt@fester program]$
|
The preceding error is produced by UMENU's faulty operating system detection
feature. Disable this feature and strongarm the OS to LINUX, which should
work on any UNIX based operating system (but not Windows). Edit $HOME/umenu/program/OS.pm.
Here's the original:
package OS;
#The constructor is always called new(). It can take as many args
#as required.
sub new
{
my($type) = $_[0];
my($self) = {};
bless($self, $type);
if ($self->checkLinux) {$self->{'OS'} = 'LINUX';}
elsif ($self->checkUnix) {$self->{'OS'} = 'LINUX';} # for this version assume UNIX and Linux equvalent
elsif ($self->checkWin) {$self->{'OS'} = 'WIN32';}
else {$self->unknownOS;};
|
The following shows your changes marked in red:
package OS;
#The constructor is always called new(). It can take as many args
#as required.
sub new
{
my($type) = $_[0];
my($self) = {};
bless($self, $type);
# if ($self->checkLinux) {$self->{'OS'} = 'LINUX';}
# elsif ($self->checkUnix) {$self->{'OS'} = 'LINUX';} # for this version assume UNIX and Linux equvalent
# elsif ($self->checkWin) {$self->{'OS'} = 'WIN32';}
# else {$self->unknownOS;};
$self->{'OS'} = 'LINUX'; # ADDED TO FIX AUTODETECT BUG
|
Now rerun this command from the $HOME/umenu/program directory:
./umenu.pl x
It will probably work, but if it doesn't it's probably the $BSD_STYLE
variable, which you'll need to change in 2 places. Edit both OS.pm and getch.pl,
in each looking for the line that looks like this:
my($BSD_STYLE) = 1;
If set to 1, change to 0 and try again. If set to 0, set to 1 and try again.
Make sure both files agree on the value. UMENU will almost certainly work
correctly with one of those settings. If neither works, check that you really
have x.mnu in $HOME/umenu/menudir, (it ships with UMENU),
and that you've made no other errors. If you still can't find the problem,
a programmer will need to begin source code debugging techniques.
But probably it will produce a nice menu, in which case you can integrate
it into your operating system.
Integrating UMENU into your operating system
Start by copying the mm and mm_startmenu files from $HOME/umenu/program
to a directory on your path. Naturally, if that directory is not accessible
to your login, you'll need to do this as root. Now you can run UMENU simply
by typing mm (for a persistent menu) or mm_startmenu (for
a start type menu). Next, associate it with the Ctrl+9 keyboard combination
in your window manager:
Window
manager |
How to enable UMENU |
| Icewm |
- Place the following in ~/.icewm/keys:
key "Ctrl+9" rxvt -fg yellow -e mm_startmenu
where mm_startmenu starts UMENU in terminate-on-select mode.- Restart IceWM
by logging out and in, or by clicking the restart button in IcePref
|
| Sawfish |
- Center click the desktop
- Choose Customize
- Choose Bindings, and the "Sawfish configurator" window appears
- On the Context list, choose "Global"
- Click the "Add" button, and the "Edit Binding" window appears
- Click the "Grab" button, and press the Ctrl+9 key combination
- From the "Commands" list, choose "Run shell command"
- Notice that a field opens up for the command to run
- Into the command field type rxvt -fg yellow -e mm_startmenu
- Click the OK button on the "Edit Binding" window
- Click the OK button on the "Sawfish configurator window
- Ctrl+9 will now run UMENU
|
| Gnome |
Same as Sawfish!
|
KDE
|
Thanks to Noel Henson for this information!
- Run the /usr/bin/kmenuedit program.
- Click the new item icon from the toolbar.
- When prompted for the name, type UMENU and click OK. You'll be
brough to the menu information screen.
- Skip the comment unless you want one.
- The command should be: rxvt -fg yellow -e mm_startmenu
- Choose application for the type.
- Leave the work path field blank.
- DO NOT check the run in terminal box. The rxvt -e
in the command already runs it in a terminal, and the rxvt terminal
is lighter weight and faster to instantiate than the native KDE terminal.
- Click the current key button. Notice that you'll see an
input window like this:
- WARNING: NON-INTUITIVE: press the Ctrl+9 keyboard combination
and the input window terminates, leaving you back at the original menu edit
screen.
- Observe that the current key button now reads Ctrl+9.
- Click the Apply button.
- If you want the menu item in a less conspicuous place, observe
that on the left is a graphical tree represenation of the KDE menu system.
Drag the UMENU item to a less conspicuous place in the menu system.
- From the menu, File->Quit.
- Press the Ctrl+9 keystroke combination, and watch UMENU come up.
|
| Enlightenment |
- Right click on the desktop
- Choose "Legacy E-Conf Tool..." from the dropdown menu
- From the list, choose "shortcuts"
- Click the "New" button
- Click the "Change" button and press the "9" key
- Choose "Ctrl" from the modifier popup list
- Choose "Run Command" from the "Action to perform" list
- Type rxvt -fg yellow -e mm_startmenu in the "options
for action" field
- Click the OK button to enable your new hotkey
|
| fvwm2 |
The following is the high level plan for enabling UMENU:
- Create ~/.fvwm/.fvwm2rc if necessary
- Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+9
- Restart fvwm2
And the following are the specifics:
- Create ~/.fvwm/.fvwm2rc if necessary
- CAUTION: This procedure will overwrite your existing rc file.
- Leftclick->Setup
- Click desired check boxes (or none at all)
- Click "Copy Config File(s)" button
- Click the "Restart fvwm" button
- Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+9
- Find the "some simple default key bindings:" section
- Add the following line:
- Key 9 A
C exec rxvt -fg yellow -e mm_startmenu
- Find the "AddToFunc StartFunction" section followed by lines
starting with plus signs
- Add one more plus sign line like this:
- + I FuncFvwmFocusPolicyChange ClickToFocus
- This line changes focus from following the mouse to clicking
to focus,
- which is necessary to use UMENU as a start menu.
- Save and exit
- Restart fvwm2
- Leftclick->Exit Fvwm->Restart
|
Blackbox
|
Must be done with bbkeys. |
Fluxbox
|
Add the following line to $HOME/.fluxbox/keys:
Control 9 :ExecCommand rxvt -fg yellow -e mm_startmenu
Then restart fluxbox by right clicking the desktop and choosing restart. The
Ctrl+9 keystroke should bring up UMENU.
Note the special naming conventions for the fluxbox keys file modifier keys:
keys file designation
|
Common designation
|
Mod1 9
|
Alt+9
|
Control 9
|
Ctrl+9
|
Shift F12
|
Shift+F12
|
None 9
|
9
|
Control Mod1 9
|
Ctrl+Alt+9
|
|
WindowMaker
|
I've heard that you can assign an arbitrary command
to a keystroke in WindowMaker, but have never succeeded in doing it.
|
Once you've associated Ctrl+9 with UMENU, it functions beautifully as a start
menu.
Configuring Your UMENU
Menu System Directly
By Steve Litt
A UMENU menu definition file is named with its letter string (all lower case),
with extension .mnu. For instance, menu sIB is configured with sib.mnu.
These files are typically kept in $HOME/umenu/menudir. Each separate
submenu has its own menu definition file. That helps keep memory requirements
down.
A UMENU menu definition file starts with a line describing the menu itself,
looking something like this:
T_Browser Menu
The initial T stands for "Title", and the information after the underscore
is indeed the menu's title. This is the title that shows up on the menu.
Next come a series of choices. Each choice begins with a line starting with
the letter L, standing for "letter". This is the letter corresponding
to the key which will invoke the choice. From that line until the next line
beginning with L, or until end of file, all lines define that choice. Information
is categorized by the first character on the line. Common starting characters
include the following:
L
|
Letter
|
Letter that the user must press to invoke this choice
|
C
|
Command
|
Command run by this choice. There are also special
letters ~ indicating that this choice is a menu, and ^ indicating that this
choice will return to the calling menu (or terminate UMENU if this is the
top level menu).
|
D
|
Directory
|
The directory to cd to before running the command
|
P
|
Path
|
A path to prepend onto the existing path
|
B
|
Background
|
Run the command in the background, meaning that if
UMENU terminates, the spawned command will survive.
|
S
|
Stop
|
After the spawned command terminates (or if run in
the background, after control returns to UMENU), prompt for a keystroke and
wait for a keystroke. This enables you to view the spawned command's output,
rather than having this output overwritten by the next menu.
|
The following is an example of a UMENU menu definition file:
T_Internet menu
#___Menu created by EMDL to UMENU converter
#___Filename=si.mnu, EMDL key=0101.
L_I
T_IPCop
C_xterm -e ipcop.sh
B_1
L_F
T_Fetchmail
C_~
L_K
T_Kmail
C_nohup kmail &
D_~
L_D
T_DCOP
C_~
L_S
T_Stats for T.C
C_~
L_T
T_Transfer files
C_~
L_B
T_Browsers
C_~
L_V
T_vncviewer
C_vncviewer 192.168.100.5
D_~
S_1
L_Z
T_Zope menu
C_~
L_E
T_fEtchmail configuration
C_python /usr/bin/fetchmailconf
D_/home/slitt
L_Q
T_Quit
C_^
|
UMENU files use the pound sign (#) for comments. On every line, the
first character is reserved for a flag denoting the function of the line.
The second character is undefined and unsupported, except for a few ancient,
deprecated and nonfunctional scripts from the old days. Everything starting
from the third character is data. So each line is a key->value pair.
The top line describes the menu itself, whose keystroke in this example is
T and whose title in this example is Internet Menu. The
second and third lines are comments inserted by the EMDL parser (see next article).
Following the comments is data concerning the menu's choices. Each line starting
with begins a new choice, with all lines until the next Lor
end of file supplying data about that choice. The column 1 flag definitions
are enumerated earlier in this article.
So configuring your menu system is a simple matter of creating a menu definition
file for each submenu. Unfortunately, significant menu system structural modifications
are cumbersome in a multi-file configuration. For that reason I created EMDL.
Read on...
Configuring
Your UMENU Menu System with EMDL
By Steve Litt
As mentioned in the preceding article, configuring UMENU directly is cumbersome,
at least for large menu systems. I would never have been able to create and
maintain my 304 command, 5 level menu system by directly manipulating UMENU
menu definition files. So I created EMDL, which stands for Easy
Menu Definition Language.
You can download an EMDL to UMENU converter from Troubleshooters.Com (URL
in URL's section of this magazine).
EMDL is optimized for quick creation and modification. Like C, it's very terse.
It's line oriented, with no begin or end tags. In most cases, property names
are identified by a single letter (followed by a colon and space). Thus a
minimum of typing.
EMDL is an outline. That makes sense, because an outline exactly model hierarchies,
and a menu system is a hierarchy. At the top is the main menu. Below it are
each of its choices. There are two types of choices, submenus and commands.
All choices have a letter (keystroke) that invokes them, and text that identifies
them. In a graphic menu system, they can also have an icon file that identifies
them.
Command choices have many additional properties: a command to run, a subdirectory
to cd to, a path to prepend onto the existing path, whether to run the command
in the background, and stop for keyboard input before resuming menu operations.
The following is a swatch of EMDL to create a tiny menu system:
S:::Main Menu
Entertainment Menu:::Entertainment Menu
Sound Menu:::Sound Menu
aumix
param
C: aumix
D: /data/oldsongs
B: 1
xmms
param
C: xmms
D: /data/oldsongs
B: 1
realplayer
param
C: realplayer
D: /data/oldsongs
B: 1
^Quit
Games Menu:::Games Menu
Foul Eggs
param
C: kfouleggs
B: 1
Tetris
param
C: ksirtet
B: 1
^Quit
^Quit
Vim (graphical)
param
C: gvim
D: /home/slitt
^eXit
|
The preceding EMDL defines a menu system whose main menu contains three choices
-- a submenu and two commands (Vim and eXit). The carat starting the eXit
choice means it's a termination choice -- go back one level up or terminate.
The Vim choice has two properties: the command (gvim), and the directory
to cd to (/home/slitt).
The Entertainment submenu contains two submenus and a termination choice (Quit,
which starts with a carat). Each submenu contains command choices to run
sound programs or computer games. Notice that all these programs specify to
run the command in the background, so that if UMENU terminates, the command
will still survive.
The very first line is a special case -- it defines the menu letter and title
of the top level menu. Notice that it is on the same level as its submenus.
This inconsistency is justified by increased editability due to less indentation.
EMDL was built for easy creation and modification.
Menu choices contain a triple colon (:::). On the left of the colons is the
text appearing on the submenu. On the right of the colons is the title shown
on the submenu. They can be, but don't have to be, the same. The only children
a menu choice can legally have is other choices.
Command choices always have exactly one child, a line consisting of the word
param. Each param line has children corresponding to the
command choice's properties, such as command, directory, prepath, stop, background,
etc, but not menu letter, which is defined in the choice's main line. A command
line starting with a carat (^) returns to the calling menu, or terminates
UMENU if you're on the top level menu.
You'll notice in the EMDL snippet displayed earlier, that I haven't explicitly
specified each choice's choice letter. As part of its shorthand, EMDL has
a four step default system to determine the choice letter:
- The first character of the line, unless...
- The first upper case character in the line overrides the preceding,
unless...
- The first & followed by a non-whitespace, in which case the non-whitespace
is the activation letter, overrides all the preceding, unless...
- If the line starts with _LX_, where X stands for any letter, that letter
is the activation letter and overrides all the preceding.
In practice I've never gone past #2.
Installing the EMDL Parser
Simply download the EDML parser into your home directory. As of August 2003
the file is emdl-0.5.0.tar.gz. Untar it to produce the $HOME/emdl
tree. It's now installed.
Creating and Modifying EMDL
EMDL was specifically crafted to be useful with a simple text editor. Text
editors maximize productivity by limiting input to keyboard activities. The
menu system structure can quickly be modified with cut and paste operations
and insertion/deletion of leading blanks. The Vim editor is especially good
at this.
Better yet, the Vim editor can be made to expand and collapse subtrees using
foldmethod=indent.
Best, you can use the VimOutliner outline processor (downloadable at Troubleshooters.Com,
URL in URL's section of this magazine) to effect lightning quick changes.
Creation of additional menus often takes the form of cut and paste. This minimizes
the chance for indentation errors, or leaving out a paramline, or
other common errors.
Compiling EMDL
You can download an EMDL to UMENU converter from Troubleshooters.Com (URL
in URL's section of this magazine). This converter is a Perl program that
parses the EMDL file, creating corresponding UMENU menu definition files for
the main menu and each submenu. The current version of the converter has
excellent error detection and error messages, such that you can quickly and
easily find and correct errors. Typical errors include:
- Over or under indentation of a line
- Forgetting to insert a param line between a command choice
and its properties
Typical warnings include:
- Two choices on the same menu sharing the same choice letter
- No termination choice on a menu
Some menu systems allow or even encourage same-letter choices on a single
menu. Such menu systems typically toggle between same-letter choices, requiring
the user to press Enter to choose one. Later versions of EMDL parsers might
make this warning configurable.
Lack of a termination choice can be legitimate on menus intended to be shells,
so later versions of EMDL parsers might make this warning configurable.
My menu system has command choices for all UMENU configuration:
|
Umenu ::: Umenu Configuration Menu
Persistent Umenu menu
param
C: xterm -e ./umenu.pl scu
D: ~/umenu/program
B: 1
Maintain s.emdl file
param
C: gvim /data/s.emdl
S: 1
Error report on S EMDL file maintenance
param
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./emdl2umenu.pl /data/s.emdl | grep ERROR
S: 1
Warning report on S EMDL file maintenance
param
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./emdl2umenu.pl /data/s.emdl | grep WARNING
S: 1
Compile s.emdl file
param
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./emdl2umenu.pl /data/s.emdl
S: 1
Transfer S EMDL files
param
D: ~/umenu/menudir
P: ~/emdl
C: cp -f ~/emdl/s*.mnu .
Standard Umenu (x)
param
D: ~/umenu/program
P: ~/umenu/program
C: ./umenu x
S: 1
Vi in menudir
param
D: ~/umenu/menudir
C: gvim
scripts/mm edit
param
D: /scripts
C: gvim /scripts/mm /scripts/mm_startmenu
icewm keys configuration ::: Icewm keys config menu
edit icewm keys
param
D: ~/.icewm
C: gvim keys
Append example
param
D: ~/.icewm
C: echo 'key "Ctrl+9" rxvt -fg yellow -e /scripts/mm_startmenu' >> keys
^Quit
^Quit
|
Therefore, whenever I want to change my menu, my menu itself is the front
end for editing, compiling, and transferring the files. But what happens if
you don't have a functional menu? If you try to run UMENU on a nonfunctional
menu system, you'll get the following screen:
In that case, you use the pumpprimer.sh script included with the
EMDL parser package. You can either completely or partially bootstrap from
pumpprimer.sh.
Complete bootstrap
Get into your EMDL directory. Make sure that your UMENU setup is in a tree
starting at $HOME/umenu. If not, change pumpprimer.sh accordingly.
Then run the program from within your EMDL directory (typically $HOME/emdl):
./pumpprimer.sh
Now, get into your umenu/program directory (typically $HOME/umenu/program),
and type this command:
./umenu.pl e
You should now get a UMENU menu system including entries to change your existing
e.emdl and compile (parse) it, and transfer the newly compiled .mnu
files to your umenu/menudir directory. Build your menu system from there.
Partial bootstrap
If you already have an EMDL file, you can simply modify pumpprimer.sh
to compile and transfer that EMDL file.
First, edit the script and change the e.emdl to the fully pathed
filename of the EMDL file you want to compile. Next, you change the e
in e*.mnu to the main menu's choice letter as defined by the first
character of the first line containing a triple colon. If your UMENU installation
isn't in the ~/umenu tree, change directory specs accordingly. Then, from
the EMDL directory (which is typically ~/emdl), run the pumpprimer.sh
script, and you'll obtain a working UMENU based on the EMDL file.
Future EMDL Parsers
You'll notice that little in EMDL is specific to UMENU. EMDL captures the
vast majority of information needed by any menu system, and can be used to
define almost any menu system. Unfortunately, the current EMDL parser has
so much UMENU inspired code that it's almost impossible to adapt for other
types of menu systems. However, one day per month I've been working on a
tool called Node.pm, which can parse an outline into a structure
very much like a DOM tree. This pseudo-DOM tree can easily be programmatically
manipulated into almost any type of output.
At the LEAP Installfest on 8/2/2003 I got the new, Node.pm equipped
converter running. The new program has almost no UMENU specific code outside
the small UMENUwriter module, and it converts 4 times faster than the current
version.
I anticipate a time in the not too distant future when, from one EMDL file,
you'll be able to built a UMENU menu system, an Icewm menu system, a KDE menu
system,and a Gnome menu system. Creating other menu system output filters
will be as simple as subclassing a class. This makes your menus "write once,
run everywhere".
Front Ending a Command
or Application
By Steve Litt
Need a front end to a complex command but have only 10 minutes to make it?
Need to write an app but don't want to take the trouble to write a user interface?
Let UMENU do the front-ending for you.
UMENU has a feature called prompted argument substitution. You can
configure a menu choice to prompt for an argument to the command being run.
For instance, the following real-life menu choice prompts me for my weight,
and for a comment, and passes these to them both to weightrecord.sh.
L_R
T_Record todays weight
C_./weightrecord.sh %1%Weight please%% "%2%Comment please%%"
D_/d/p/weight
S_1
|
In the preceding, arg0 is weightrecord.sh, arg1 is whatever the user
enters after UMENU prompts him with Weight please", and arg 2 is
whatever the user enters when prompted with Comment please. As written,
the weight prompt would be presented to the user before the comment prompt.
But the presentation order to the user could be reversed by reversing the%1%
and %2%. Such reversing does not change the order of the arguments
presented to the command. A prompt is delineated on the left with a percent
sign, a sort character, and another percent sign. It's delineated on the
right with two percent signs.
Look at the opportunity this presents. You can now build an entire app out
of various shell commands and simple, no user interface scripts. Database
access can be via the psql program. Reports can be presented in Mozilla
or via enscript to the printer, depending on which menu item you
select. Form input could be through a Perl-TK program or via an old fashioned
command line cycle-through script.
About the only thing this scenario is missing is a picklist. Hey -- wait a
minute -- didn't I see one of those in the March 2003 Linux Productivity Magazine?
(URL in URL's section).
So you can quickly write a few simple and completely modular scripts, and
then turn them into a user friendly app with UMENU. At least twice in my life
I was contracted to quickly (a couple days) create a simple version of an
app that the company's employees needed a month to complete. In one
of those cases I wrote the prototype in Perl while the employees struggled
with Java. I wonder if someone could hire themselves out as a professional
prototyper and make a living. Hmmmm...
Life After Windows: Why UMENU?
Life After Windows is a regular Linux Productivity Magazine column,
by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's
Windows to Linux conversion.
By Steve Litt
UMENU doesn't run on Windows, although at least one person modified a former
version enough to run on Windows. So it's ironic that if it did run on Windows,
it would help Windows users much more than Linux users. Unlike Windows, many
Linux window managers are very keyboard friendly. IceWm's menu system is
easily manipulated from the keyboard. So why do I use UMENU instead of the
IceWM menu system?
One reason is ease of configuration. With EMDL, in minutes I can make structural
menu changes that would take hours using IcePref or MenuDrake. But what about
manually editing IceWM's menus? IceWM's menu definition file might be OK for
a programmer, but for a casual menu system user it's a horror, with begin
and end tags and non-intuitive space dependencies. Once again, EMDL configures
much faster.
I like the fact that, via EMDL, UMENU can be configured with any text editor.
No front end program to screw up. The compiler's a fairly simple Perl script.
Contrast this to the various menu front ends. If they break or malfunction,
you're out of luck. Imagine configuring KDE manually. KDE's menu structure
is a directory structure. You'd need a pretty slick file manager to quickly
configure it by hand.
Then there's data integrity. Make no mistake about it -- when you've tweaked
your menu system exactly how you want it, it's data -- valuable data. You
want to back it up. Of course, most menu systems could be backed up by backing
up your entire home directory, but for those of us not wanting to back up
hundreds of web cache files and maybe a local Star Office installation, it's
much nicer to have a single file (which can be kept anywhere), to back up.
And of course there's replication. With one single EMDL file you can go to
any computer with EMDL and UMENU, and compile up a menu identical to the one
on your regular computer. You could easily and quickly install the same menu
on a few hundred computers.
I'm mostly in GUI mode on my desktop computer, but every once in a while I'm
in the command line interface, and when there, I'm glad I can run UMENU.
UMENU is extremely lightweight. I once put together a chess playing computer
using an ancient, memory starved Pentium box, Red Hat 5.2 (when 7.3 was the
current version), Window-managerless X, and UMENU. In /etc/passwd
I specified the user's shell as UMENU. Worked great!
I think UMENU is a great addition to Linux.
Steve Litt is the author of the courseon
the Universal Troubleshooting Process. He can be reached at Steve Litt's email address.
Letters to the Editor
All letters become the property of the publisher (Steve Litt), and may
be edited for clarity or brevity. We especially welcome additions, clarifications,
corrections or flames from vendors whose products have been reviewed in this
magazine. We reserve the right to not publish letters we deem in bad
taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure
the subject reads "Letter to the Editor". We regret that we cannot return
your letter, so please make a copy of it for future reference.
How to Submit an Article
We anticipate two to five articles per issue, with issues coming out monthly.
We look for articles that pertain to the Linux or Open Source. This can be
done as an essay, with humor, with a case study, or some other literary device.
A Troubleshooting poem would be nice. Submissions may mention a specific
product, but must be useful without the purchase of that product. Content
must greatly overpower advertising. Submissions should be between 250 and
2000 words long.
Any article submitted to Linux Productivity Magazine must be licensed
with the Open Publication License, which you can view at http://opencontent.org/openpub/.
At your option you may elect the option to prohibit substantive modifications.
However, in order to publish your article in Linux Productivity Magazine,
you must decline the option to prohibit commercial use, because Linux Productivity
Magazine is a commercial publication.
Obviously, you must be the copyright holder and must be legally able to
so license the article. We do not currently pay for articles.
Troubleshooters.Com reserves the right to edit any submission for clarity
or brevity, within the scope of the Open Publication License. If you elect
to prohibit substantive modifications, we may elect to place editors notes
outside of your material, or reject the submission, or send it back for modification.
Any published article will include a two sentence description of the author,
a hypertext link to his or her email, and a phone number if desired. Upon
request, we will include a hypertext link, at the end of the magazine issue,
to the author's website, providing that website meets the Troubleshooters.Com
criteria for links and that the author's
website first links to Troubleshooters.Com. Authors: please understand we
can't place hyperlinks inside articles. If we did, only the first article
would be read, and we can't place every article first.
Submissions should be emailed to Steve Litt's email address, with subject
line Article Submission. The first paragraph of your message should read
as follows (unless other arrangements are previously made in writing):
Copyright (c) 2003 by <your name>. This material
may be distributed only subject to the terms and conditions set forth in
the Open Publication License, version Draft v1.0, 8 June 1999 (Available
at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability
at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version
is presently available at http://www.opencontent.org/openpub/).
Open Publication License Option A [ is | is not] elected,
so this document [may | may not] be modified. Option B is not elected, so
this material may be published for commercial purposes.
After that paragraph, write the title, text of the article, and a two
sentence description of the author.
Why not Draft v1.0, 8 June 1999 OR LATER
The Open Publication License recommends using the word "or later" to describe
the version of the license. That is unacceptable for Troubleshooting Professional
Magazine because we do not know the provisions of that newer version, so
it makes no sense to commit to it. We all hope later versions will be better,
but there's always a chance that leadership will change. We cannot take the
chance that the disclaimer of warranty will be dropped in a later version.
Trademarks
All trademarks are the property of their respective owners. Troubleshooters.Com(R)
is a registered trademark of Steve Litt.
URLs Mentioned in this Issue
- MISC URLs
- UMENU and EMDL URLs