YUME(1) User Manuals YUME(1)
NAME
yume-plan - Plans for changes to yume menu system
SYNOPSIS
yume [commands] [-bu] [-do] [-ex] [-at geometry] [-in file] [-iv value]
[-la label] [-ti title] [-de valpair] [-bf] [-bg] [-bh] [-Y[aefghino-
tuvx]]
DESCRIPTION
As noted in the yume man page, yume creates and runs a menu based on
arguments given. This man page is a draft or outline of projected
changes to yume. For context, some parts of this page are copied
directly from yume(1). Many items in this page are ephemeral and will
be removed when feature is done or item resolved.
Option Codes currently in use (:) or planned (;)
a: -la label
e: -de valpair
f: -bf
h: -bg
h: -bh
n; -in filename
i: -ti title
o: -do
s; -bs sizelist
t: -at geometry
u: -bu
v: -iv
x: -ex
-in fn Include set of parameters from a file.
This is more-flexible (although slightly-more-verbose) than pre-
viously-thought-of -dr fn, which would have consisted of
attribute:value pairs rather than an ordinary-parameters form.
Also, have .yumerc in same form.
misc ephemera
need to set outer rectangle size to sum of button and do sizes
at end of add-ups
need to note re improvements process
set up a firefox define: example in um4
Various
figure out whether wait() is needed and/or whether current fork
- exec process results in some zombie processes
In yume-opttest, use fl_addto_command_log(const char *s); as an
optional way of tracking what commands are executed. Also in
yume-opttest, use fl_show_colormap(int oldcol); (or related) to
allow color-picking for form elements.
comment re avoid space after at end of continuation lines
lacs: create a lac-starter menu for current directory, possibly
with laccs wrapper
Another example: Drop a string onto a button and have it uniq
the text and for items with man pages, set up a stack of "man x
in xterm" commands for button click selection. Also with a word
dropped on a button, do "apropos word" and then the above.
More kinds of objects: Is it feasible to have a -ob switch,
which has a string of parameters to create
Box sizing: buQuanta allows making button sizes match up reason-
ably well, but perhaps need lists of permitted button sizes, or
some code to look at ranges of sizes, sort into order, and look
for breakpoints for binning the sizes. Could have a buNX df
that says how many bins to have. Eg, if df[buNX] is 3, sort the
sizes, then look for gaps between top third and middle third and
lower third of sizes. Alternately, could just let user define
box sizes via -bs 'sizelist' parameter, where sizelist is a list
of character count / box % settings.
Re: execval() and %
While the % processing in Rev.19 yume probably is nice in the-
ory, it doesn't seem particularly useful in practice. What I
want instead of % as now is use of a pseudotty or similar setup
such that commands are piped into a running program to augment
commands entered directly into the program. Also see "Better
execval() % approach ?" below.
Man pages re pseudotty items -- open_init_pty(8) getpt(3)
grantpt(3) irpty(3) posix_openpt(3) ptsname(3) pty(7)
unlockpt(3)
yume(1) says: "A command list that starts with a percent sign
(%) is handled somewhat differently." At the moment, POSIX rou-
tine wordexp() is used to perform a shell-like expansion of the
string with the % lopped off. This produces an array of parame-
ter values; see man 3 wordexp for details. yume treats that
array as a program name and its arguments.
For example, consider this menu with buttons labeled X1 and X2:
yume -bu -la X1 "/usr/bin/xterm -e xyz" \
-la X2 "%/usr/bin/xterm -e 'xyz'" &
When X1 is clicked, effectively
execv /bin/sh -c "/usr/bin/xterm -e xyz"
is performed, and when X2 is clicked, effectively
execv /usr/bin/xterm -e xyz
is performed. In this example, the final effect is identical,
except that X2 uses one less execve level.
------- Better execval() % approach ? -------
But perhaps instead % should be followed by string of #, -, @,
+, % to indicate what to do. Then %xterm... (for example) is
just a special case -- ie, the empty string case. Then
# indicates no-fork
- indicates no-shell
@ says to record result string within yume
+ says to interpolate recorded result string
% says %
| says something about pipes or pty
With this approach, "x" == "%x" unless x starts with any of #,
-, @, +, %. To actually issue a command that starts with a %,
just say %%command.
Eg, %@myprogram saves result (eg, "ITEM=473") of myprogram
and %%command23 interpolates result; eg "ITEM=473 command23".
Eg:
yume -bu -la 'Dir1' '%@echo "cd /dir1;"'\
-la 'Dir2' '%@echo "cd /dir2;"'\
-bu -la 'SA' '%%SA' -la 'SB' '%%SB' &
so that after clicking Dir1, buttons SA and SB operate in /dir1;
but after clicking Dir2, they operate in /dir2.
More gooder, have another text string that gets added to front
of every command. Or have %xc, where x is a digit, call for a
particular string (S0...S9) be interpolated before command c.
And %xyz...c where xyz... are digits, interpolates Sx, Sy, Sz,
... and have %c (where c starts with a letter) act the same as
%0c. Of course, for things like example-starter3 we can do ok
without % because the string we want at front of 1/3 of the but-
tons ( ./ or a specific path) can be done with menu-start-time
values, vs what S0...S9 address, which is menu-run-time values.
Alternately, let % tell yume to construct a command like with
sprintf and some particular var list. Or, construct every com-
mand that way, with command template in one string var, and list
of param names in another. Or, let %m%c introduce "meta-com-
mand" m before shell command c. %...% sequences would be
allowed anywhere within a command list. Use %% to insert a %
character. %...% form could be %x=c% or %x% where x is a var
name, and c is a shell command list whose result is stored in x
in yume's environment.
test %% non fork cases
Button mode notes
The next few items are about right-click button actions. The
general idea is that a right click on a button should pop up a
menu to allow changing the button command or label, etc., vs
current state of being unable to see command or to change either
command or label.
-bu Select default-type button mode.
That is, turn on -bu mode for commands that follow. Each occur-
rence of -bu, -bf, -bg, or -bh starts a new row of buttons.
-bf Select button mode, of value-is-fixed type
-bg Select button mode, of general value-can-be-varied type
-bh Select button mode, of value-is-hidden type
-bf, -bg, -bh
Intent: Select button mode, of value-is-fixed/general/hidden
type
Need right-click actions to support -bf, -bg, -bh, which at the
moment (Rev.19) just act like old-style yume1 -bu buttons.
Right clicking any item in yume2 should pop up a menu, which can
reveal the button command, unless it is a hidden command; or can
change the command, unless it is a fixed command.
So, right-click button actions will include (1) view and edit
label and command values of buttons, unless disallowed ; (2) put
button in or out of EE (entry execution) mode; and possibly (3)
define other commands on a button, for different actions upon
entry, exit, and left/middle/right clicks.
Could also select command or command modifiers with kbd shift or
alt keys. Ie, if shift or alt key or left or right or center
mouse button is pressed when mouse passes through box. EE could
cycle thru several command choices instead of being only off-on.
Would allow, eg, "enter with button 1 on" and other combination
events because these might speed up waving the mouse at an acti-
vator group with selection via which button is pressed.
-de and -dr
In Rev.19 yume, color constant names are BLACK, BLUE, ...,
WHITE, and YELLOW, as listed in the -de section of yume(1).
Consider allowing user to specify colors using standard X names,
and add the color specs in the spares section of xforms color
numbers.
In Rev.19, yume sets df[] entries when -de options are encoun-
tered in process_command_options(). Object creator
make_objects() uses df[] values and starts after process_com-
mand_options() and addup_sizes() finish. Thus, in Rev.19, -de
option settings affect all items, rather than just items later
in the command. Add fields (eg color, style, margins) to Lis-
tItem, set them with current df[] values in process_com-
mand_options(), and use data from those fields during
make_objects().
Also in -de section of yume(1), add note re case independence of
constant names.
Add a options for fixed button size and button size quanta. In
latter case, all widths are multiple of quanta.
Also in bugs or comments of yume(1), add note re parameters
appearing in ps output
In Rev.19 yume2, -de is not position sensitive. That is, its
effect applies to all parameters, not just to those that follow
it in the parameter list. This may be fixed in a later version.
To see current lists of attribute and constant names and their
values, use
yume-def-init -v
To see current default settings of yume, use
yume-def-init -d
Note, yume-def-init writes a file, yume-initV.h, when it runs.
Perhaps should provide constants for fonts listed in xforms man-
ual: 0 helvetica-medium-r, 1 helvetica-bold-r, 2 helvetica-
medium-o, Chapter 3: Defining Forms 28, 3 helvetica-bold-o, 4
courier-medium-r, 5 courier-bold-r, 6 courier-medium-o, 7
courier-bold-o, 8 times-medium-r, 9 times-bold-r, 10 times-
medium-o, 11 times-bold-o, 12 charter-medium-r, 13 charter-bold-
r, 14 charter-medium-i, and 15 Symbol.
Rev.19 -de does not recognize abbreviated names. It uses hash
values based on entire names to recognize names. The aim is to
keep yume's memory footprint small (eg 27KB for Rev.19) by using
only about 3KB for code and data to recognize names and set
default values.
Check out the overhead of yume-def-init keeping enough of the
leading text of names to distinguish them from each other, vs
current hashing method
A future version of yume will have a -dr option to read valpairs
from a yume resource file, and future routine yume-opttest will
allow interactive attribute settings. For now, if you want to
change button colors, sizes, etc. at runtime, -de is the only
way. -- Also consider yumec, that would accept a set of yume
options, and output source code that loads those options via an
array, to create single-menu programs that require no parame-
ters, thus not revealing them via ps; or that create a file of
object specs, that a single-parameter yumer can load.
Eg -- "yumer myVmenu" would binary-read the file myVmenu and
then go on with make_objects(). yumer would not need any of the
code in fix_option_codes(), process_command_options(), and
addup_sizes ().
-do Consider a one-line version of do-group. Consider rows of do-
groups, starting a new row when -do appears.
-at Re placement of menu pane: yume could have changeable defaults
to use when it calls fl_show_form(), like it uses for various
button colors and fonts, but Rev.19 does not do so. Such
defaults would be used to specify other window placement con-
trols than FL_PLACE_POSITION and FL_PLACE_FREE.
HISTORY
The source file of yume as documented in this man page is yume2.c.
yume2.c began as a translation of Tcl/Tk program yume.tcl into C, using
the xforms API. yume.tcl began as a program called me-me in October,
1997. In December, 1997 it was renamed to yume (a Japanese word that
tranlates to English as "dream"), and then released for public use in
1998; for example, several early releases appear at
http://yangtze.cs.uiuc.edu/~j-waldby/yume/ . Various small changes
have been made in yume since then, culminating in 2007 in the TCL/Tk
program yume.tcl that appears in the yume2/doc directory.
In mid-February 2009, yume2.c began as a translation of yume.tcl.
Development was based on notes in three files, note-y2-plan1, note-
y2-dats, note-y2-sizing in yume2/doc. Some information in those files
is obsolete, but the general ideas of the sizing algorithm used in
addup_sizes as expressed in note-y2-sizing still are accurate.
Revisions to date:
v0.00: Initial code with -bu, -do -- jiw 16 Feb 2009
v0.01: Add -at, -ex, and -ti options -- jiw 18 Feb 2009
v0.02: Add % code in execVal -- jiw 19 Feb 2009
v0.03: Add yume-def-init prog and df[] -- jiw 20 Feb 2009
Rev.19: Add -de, -bf, -bg, -bh, BuCur -- jiw 21 Feb 2009
Wrote man page yume(1) -- jiw 21-22 Feb 2009
v0.05: Fixed BuCur init bug -- jiw 23 Feb 2009
Wrote yume-examples and its man page
Wrote yume-plan man page, -- " "
removed most "future" refs from yume2 and yume.1, "
Rev.19: Add %% code in execVal -- jiw 24 Feb 2009
At this point (ca. 22:22 on 24 Feb 2009) set up svn repository
and will use that to track further changes
FILES
$HOME/.yumerc
[Future] User configuration file for yume default values
ENVIRONMENT
SHELL yume uses the value of environment variable SHELL as the shell
it invokes to perform commands. See discussion in COMMENTS sec-
tion.
BUGS
See yume(1) BUGS section
AUTHOR
James Waldby <j-waldby at pat7 dot com>, 23 Feb 2009
SEE ALSO
yume(1), yume-examples(1), yume-def-init(1), yume-meta(1), yume-
opttest(1)
Linux $Date:: 2009-03-13#$ YUME(1)