Brady Montz <bradym_at_cs.arizona.edu> writes:
> "Patrick K." <patrick_at_mail.boxsoft.com> writes:
>
> > Sometime in the late 1900s it was said:
> > <MENU NAME="Root-Menu">
> > <MENUITEM NAME="Xterm"
> > ACTION="xterm -T $LOGNAME_at_$HOSTNAME">
> >
> > <SUBMENU NAME="Utils">
> > <MENUITEM NAME="Top" ACTION="rxvt -T Top -n Top -e top">
> > <MENUITEM NAME="Xload" ACTION="xload -fg green -bg black -hl red">
> > <MENUITEM NAME="Calculator" ACTION="xcalc">
> > </SUBMENU>
...
much too cumbersome. I want to be able to read the damn thing (that's why I
can't convince myself to use FvwmM4).
the signal / noise ratio is too low for html code to read.
> It's simpler (and parsers already exist) to just do this the scheme way:
>
> ("Root-Menu"
> ("Xterm "xterm -T $LOGNAME_at_$HOSTNAME")
> ("Utils"
> ("Top" "rxvt -T Top -n Top -e top")
> ("Xload" "xload -fg green -bg black -hl red")
> ("Calculator" "xcalc")))
looks pretty efficient typeing-wise.
> If you want to have more flexibility, then you can have classes for menu,
> submenu, and menuitem, and use constructors (example in python, will work in
> any language with objects):
> # defined internally in fvwm:
>
> class Menu:
> def __init__ (self, name, menulist=[]):
> self.name=name
> self.menulist=menulist
>
> def __repr__ (self):
> return "{Menu = <%s, %s>}" % (self.name, self.menulist)
>
> class MenuItem:
> def __init__(self, name, action=""):
> self.name=name
> self.action=action
>
> def __repr__ (self):
> return "{MenuItem = <%s, %s>}" % (self.name, self.action)
ok, so the average user doesn't have to touch this, but exportable classes
do help pretty much, if you want to extend fvwm.
> # defined in fvwmrc
>
> M = Menu("Root-Menu",
> [
> MenuItem("Xterm", "xterm -T $LOGNAME_at_$HOSTNAME"),
> Menu ("Utils",
> [
> MenuItem ("Top", "rxvt -T Top -n Top -e top"),
> MenuItem ("Xload", "xload -fg green -bg black -hl red"),
> MenuItem ("Calculator", "xcalc")
> ])
> ])
> With appropriate cleverness in the __repr__ functions, you could make it print
> out the menus in the current fvwm syntax. The nice thing of using a real
> language for this, rather than an HTML like syntax, is that it just falls out
> that the user can create new types of objects to put in a menu. Probably you
> just require than all menu items have to have a certain base class which
> contains the member functions to exec the action. If you export some graphical
> functional to the scripting language, then you could even allow the menus and
> menuitems to be responsible for drawing themselves. This would make trivial
> such things as constructing a menu which automatically finds the the list of
> available fonts, and draws each font with the appropriate typeface.
I do think that this on-the fly menu-generation & interpretation isn't an
issue on any decent machine (>=pentium), that's able to run MS word
(isn't that interpreted in winbasic - at least it's as lame)
And I simply wouldn't use that menu on our sparc IPC. :-)
I'd like this pretty much.
> If the language supports eval() (which I don't believe java does, right?) then
> you can do even more wild things, with modules generating menus dynamically by
> sending the magic strings to fvwm (like a menu for all xterms on the current
> desktop).
I strongly support this route.
I've never met anything more flexible than emacs with its hook functions.
--
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them? To die: to sleep;
No more; and by a sleep to say we end
The heart-ache and the thousand natural shocks
That flesh is heir to, 'tis a consummation
Devoutly to be wish'd. To die, to sleep. -- Shakespeare: Hamlet
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Tue May 05 1998 - 07:28:20 BST