Ruby version of UMENU

[Steve Litt]

Hi all,

If anyone wants a keystroke-only menu system that works on any kind=20
of *nix box, UMENU is the answer. Originally written in Perl, I=20
just ported UMENU to Ruby, have been using it for several days, and=20
it appears to work perfectly, although the error handling is crummy=20
and documentation nonexistant.

If you'd like to try it out, it's here:

http://www.troubleshooters.com/projects/umenu.rb/downloads/0.01/


It requires Node.rb, which can be downloaded from here:

http://www.troubleshooters.com/projects/Node.rb/index.htm


=46or documentation, you can read the perl version UMENU docs here:

http://www.troubleshooters.com/umenu/index.htm

=46rom a user standpoint, the ruby version is pretty much identical to=20
the perl version.

If you want an easy way to create menu definition files, you can use=20
EMDL:

http://www.troubleshooters.com/projects/emdl/index.htm

EMDL is still Perl only.

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Gregory Brown]

Hi all,

If anyone wants a keystroke-only menu system that works on any kind
of *nix box, UMENU is the answer. Originally written in Perl, I
just ported UMENU to Ruby, have been using it for several days, and
it appears to work perfectly, although the error handling is crummy
and documentation nonexistant.

Interesting. However, what advantages would this have over using HighLine?
(Aside from being able to use EMDL files originally meant for perl programs=
,
which is certainly neat)

http://highline.rubyforge.org/

 

[Steve Litt]

Interesting. However, what advantages would this have over using
HighLine? (Aside from being able to use EMDL files originally
meant for perl programs, which is certainly neat)

http://highline.rubyforge.org/

Short answer: I don't know enough about Highline to answer this=20
question authoritatively.

Longer answer: Highline appears to be a programming tool, used by a=20
programmer, to quickly assemble the user interface for a command=20
line app. UMENU is a program, used by a user, to implement a menu=20
system that calls other programs. This menu system can easily be=20
assembled with an editor, either in native UMENU .mnu files, or in=20
EMDL converted to .mnu.

Highline has ALL elements of user interface -- menus, picklists,=20
edits, validation. UMENU has only a keystroke driven menu, with=20
optional prompted argument substitution, where the menu asks the=20
user for an argument and the user types it in.

My impression would be that a programmer would apply Highline to one=20
specific program, or a small group of programs. UMENU would be=20
applied by a user (granted a literate one) to all the programs=20
he/she uses frequently.

The advantages of UMENU would be speed of integration and minimum=20
debugging, as well as being doable by a mere power user. The=20
advantages of Highline would be the ability to craft a complete=20
user interface for an app.

=46rom what I read about Highline, Highline and UMENU are totally=20
different tools that can't really be compared. Indeed, I could=20
easily forsee several Highline-enabled apps called from a UMENU=20
menu system.

That's the long answer

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Gregory Brown]

Short answer: I don't know enough about Highline to answer this
question authoritatively.

I'm one of the HighLine developers, I was just curious as to what
UMENU did. Now that i've read through the source a little bit more,
my comment was kind of misguided. Still... there are some
interesting points here....

Longer answer: Highline appears to be a programming tool, used by a
programmer, to quickly assemble the user interface for a command
line app.

Yes, that's what it is.

UMENU is a program, used by a user, to implement a menu
system that calls other programs. This menu system can easily be
assembled with an editor, either in native UMENU .mnu files, or in
EMDL converted to .mnu.
Cool.

Highline has ALL elements of user interface -- menus, picklists,
edits, validation. UMENU has only a keystroke driven menu, with
optional prompted argument substitution, where the menu asks the
user for an argument and the user types it.
Gotcha.

My impression would be that a programmer would apply Highline to one
specific program, or a small group of programs. UMENU would be
applied by a user (granted a literate one) to all the programs
he/she uses frequently.

Yes, that's correct. Highline is a programmer's tool. Also, after
reading the source a bit for UMENU, i understand a bit better what it
is used for. Nifty.

The advantages of UMENU would be speed of integration and minimum
debugging, as well as being doable by a mere power user. The
advantages of Highline would be the ability to craft a complete
user interface for an app.

Perhaps HighLine would be helpful for simplifying the code that makes
UMENU work.
This would solve the weak fault tolerance currently in UMENU without
reinventing the wheel.

From what I read about Highline, Highline and UMENU are totally
different tools that can't really be compared. Indeed, I could
easily forsee several Highline-enabled apps called from a UMENU
menu system.

Yeah, I kind of misjudged the purpose of UMENU when I read through the sour=
ce.
It does look pretty neat, and would probably be a great wrapper for
HIghLine applications, though building menus is easy enough to do in
pure ruby using our system

I do like the fact that you support a sort of intermediate
configuration setup for menus so an admin or power user can build
them. That's very cool.

You might consider offering YAML configuration support, if you haven't alre=
ady.

 

[Chad Perrin]

My "short answer" would have been another perspective on the above
paragraph: "What are the advantages of using an orange crate over an
apple?"

Yes, it's true you can't eat an orange crate, but but it sure does make
it easy to carry oranges around. Unless I'm way out in left field, my
impression is that UMENU is basically a replacement for something like
the K menu in KDE, or the Start menu in Windows, but designed to be used
with window managers for X when the user doesn't like to use his/her
mouse for choosing applications from a menu. I don't see how that makes
UMENU and Highline comparable at all.

Please let me know if I misunderstood the purpose of UMENU, Steve.

Yeah, I kind of misjudged the purpose of UMENU when I read through the source.
It does look pretty neat, and would probably be a great wrapper for
HIghLine applications, though building menus is easy enough to do in
pure ruby using our system

I do like the fact that you support a sort of intermediate
configuration setup for menus so an admin or power user can build
them. That's very cool.

. . and I still don't think you understand UMENU's purpose. That, or
I don't.

 

[Gregory Brown]

Yes, it's true you can't eat an orange crate, but but it sure does make
it easy to carry oranges around. Unless I'm way out in left field, my
impression is that UMENU is basically a replacement for something like
the K menu in KDE, or the Start menu in Windows, but designed to be used
with window managers for X when the user doesn't like to use his/her
mouse for choosing applications from a menu. I don't see how that makes
UMENU and Highline comparable at all.

Please let me know if I misunderstood the purpose of UMENU, Steve.

That's what it sounds like. I don't think that this was unclear after
Steve's (or my) last post.

. . . and I still don't think you understand UMENU's purpose. That, or
I don't.

Are you just looking to argue, or did you not read my last post?

It is some sort of command line based menu for executing applications.
It can benefit greatly from using HighLine under the hood. The
source was not exactly 'inviting' to read as it's pretty much a direct
port of some perl. My comment was that HighLine could help that (in
my second post).

It 'would' be a great way to string together a bunch of HighLine
programs. I will probably use UMENU at work in the near future. =20
Though I mostly abhor character based menus, it'll make a few of my
co-workers very happy to have a menu to work with.

However, I might take the time to write the user interface over in
HighLine, because then I'm getting the validation and error handling
for free. (And not to mention ways to make it look spiffy and format
nicely) If I do this, I will certainly send Steve my code.

 

[Steve Litt]

I'm one of the HighLine developers, I was just curious as to what
UMENU did. Now that i've read through the source a little bit
more, my comment was kind of misguided. Still... there are some
interesting points here....


Yes, that's what it is.


Yes, that's correct. Highline is a programmer's tool. Also,
after reading the source a bit for UMENU, i understand a bit
better what it is used for. Nifty.


Perhaps HighLine would be helpful for simplifying the code that
makes UMENU work.
This would solve the weak fault tolerance currently in UMENU
without reinventing the wheel.

The weak fault tolerant stuff is just that I'm not yet really
comfortable with Ruby exceptions. Basically, I need to handle "file
not found" exceptions, "not enough command line arguments"
exceptions, and "can't write file" exceptions. I'd anticipate it
would be no more than 50 lines of code.

Yeah, I kind of misjudged the purpose of UMENU when I read
through the source. It does look pretty neat, and would probably
be a great wrapper for HIghLine applications, though building
menus is easy enough to do in pure ruby using our system

I do like the fact that you support a sort of intermediate
configuration setup for menus so an admin or power user can build
them. That's very cool.

The real coolness that lies therein is that a single EMDL file can
drive a UMENU menu system, a HighLine menu system, an IceWM menu
system, etc, so all those menus would have the same structure and
choices. So far I've written only EMDL to UMENU, but a simple
writer object for each output format would do the trick.

You might consider offering YAML configuration support, if you
haven't already.

I'm not familiar with YAML. What does it stand for, "Yet Another
Markup Language" or something like that? What does it do?

Thanks

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Steve Litt]

My "short answer" would have been another perspective on the
above paragraph: "What are the advantages of using an orange
crate over an apple?"

Yes, it's true you can't eat an orange crate, but but it sure
does make it easy to carry oranges around. Unless I'm way out in
left field, my impression is that UMENU is basically a
replacement for something like the K menu in KDE, or the Start
menu in Windows, but designed to be used with window managers for
X when the user doesn't like to use his/her mouse for choosing
applications from a menu. I don't see how that makes UMENU and
Highline comparable at all.

Please let me know if I misunderstood the purpose of UMENU,
Steve.

You pretty much got it, although there are some additional usages
beyond a K menu/Start menu:

1) Can be used as a persistent menu that does NOT terminate after
the user runs a program, but instead returns for the user to run
yet another program and another...

2) Can be used as the user's shell in /etc/passwd in order to "jail"
the user to specific commands.

3) Can be used as a front end to a command with lots of command line
arguments, thereby relieving the user of having to remember the
command's exact syntax. This is where prompted argument
substitution really shines.

4) Because it outputs only printable characters and linefeeds, and
inputs only printable characters, it can be used on ANY UNIX
terminal including an ancient teletype terminal. It "refreshes" by
printing 25 newlines

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Gregory Brown]

The real coolness that lies therein is that a single EMDL file can
drive a UMENU menu system, a HighLine menu system, an IceWM menu
system, etc, so all those menus would have the same structure and
choices. So far I've written only EMDL to UMENU, but a simple
writer object for each output format would do the trick.

That is cool.

I'm not familiar with YAML. What does it stand for, "Yet Another
Markup Language" or something like that? What does it do?

YAML support is built into ruby, and it's a great way to represent
configuration data.

It provides a simple way to serialize ruby objects as well as to load
in datastructures and things like that.

This is generally better and easier than parsing config files.
Google it... I'm sure you'll find plenty o' resources.

That having been said, if you provide a sane YAML format for UMENU, I
will try to create some sort of menu generation for HighLine that is
compatible with it. (After running it by James, of course).

 

[Steve Litt]

YAML support is built into ruby, and it's a great way to
represent configuration data.

It provides a simple way to serialize ruby objects as well as to
load in datastructures and things like that.

This is generally better and easier than parsing config files.
Google it... I'm sure you'll find plenty o' resources.

That having been said, if you provide a sane YAML format for
UMENU, I will try to create some sort of menu generation for
HighLine that is compatible with it. (After running it by James,
of course).

Hmmm,

It looks to me like standard UMENU .mnu files are almost YAML
anyway. It looks to me like one could indent everything between "L"
lines, put dashes in front of the "L" lines, and place one new line
(Menu) at the top, and it would conform to YAML.

In .mnu files, column 1 is the key, column 2 is ignored, and
everything column 3 and beyond is value. In a YAMLized version, the
first column after whitespace would be the key, the second would be
a colon, and everything else would be value.

You mentioned that Ruby supports YAML. Would that mean that UMENU
would not need to parse the YAMLized version of .mnu files, but
instead Ruby would parse it for us? If so, what would be the format
within memory?

There might be a temptation to place an entire menu SYSTEM within a
single file, instead of the current UMENU method of one file per
menu. For performance reasons, that would be a bad idea, as a huge
file would need to be read from disk and parsed every time someone
pressed Ctrl+9 (for example) to bring up a start menu. My menu
system has 613 command choices in 152 submenus, and takes over 2
seconds to parse on an Athlon XP2600+ with 1.5GB of RAM.

Also, keeping an entire menu system in memory at once could prove
problematic on low-memory systems, and in every other respect,
UMENU is designed to run in a very small footprint.

EMDL (Easy Menu Definition Language) includes a whole menu system in
a single file. The theory is, the EMDL parser need be run only when
the menu system is changed. EMDL has been formulated specifically
for fast and easy construction, especially when using vimoutliner
(http://www.vimoutliner.org). An EMDL to YAML .mnu converter
wouldn't be hard, always assuming the YAML .mnu files are basically
just an indented and colonized version of the current .mnu files.

Curious -- just how much YAML support does Ruby give the programmer?

Thanks

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Ezra Zygmuntowicz]

Curious -- just how much YAML support does Ruby give the programmer?

Thanks

SteveT

Steve-

Ruby has great support for YAML its basically all parsed for you.
Here's a little irb session to show you. The "y" command is just like
the 'p' command you use to inspect an object. The 'y' just pretty
prints to yaml format:

ezras-powerbook-g4-17:~/Desktop/rimport root# irb'UMENU'}
=> {:list=>"rubytalk", :topic=>"UMENU", :name=>"Steve Litt"}---
:list: rubytalk
:topic: UMENU
:name: Steve Litt
=> nil

array = %w{ one two three four five six } => ["one", "two", "three", "four", "five", "six"]
y array

---
- one
- two
- three
- four
- five
- six
=> nil=> "--- \n- one\n- two\n- three\n- four\n- five\n- six"

There is plenty more goodness in there like yaml dumping your custom
ruby objects. There are a few limitations though, mainly you cannot
dump any code with procs or lambdas in them because they can't be
serialized to yaml.


Cheers-
-Ezra

 

[Gregory Brown]

<snip umenu discussion>
You mentioned that Ruby supports YAML. Would that mean that UMENU
would not need to parse the YAMLized version of .mnu files, but
instead Ruby would parse it for us? If so, what would be the format
within memory?

You can serialize the objects as arrays, hashes, an array of hashes,
or even Menu objects

There might be a temptation to place an entire menu SYSTEM within a
single file, instead of the current UMENU method of one file per
menu. For performance reasons, that would be a bad idea, as a huge
file would need to be read from disk and parsed every time someone
pressed Ctrl+9 (for example) to bring up a start menu. My menu
system has 613 command choices in 152 submenus, and takes over 2
seconds to parse on an Athlon XP2600+ with 1.5GB of RAM.

Also, keeping an entire menu system in memory at once could prove
problematic on low-memory systems, and in every other respect,
UMENU is designed to run in a very small footprint.

EMDL (Easy Menu Definition Language) includes a whole menu system in
a single file. The theory is, the EMDL parser need be run only when
the menu system is changed. EMDL has been formulated specifically
for fast and easy construction, especially when using vimoutliner
(http://www.vimoutliner.org). An EMDL to YAML .mnu converter
wouldn't be hard, always assuming the YAML .mnu files are basically
just an indented and colonized version of the current .mnu files.

Curious -- just how much YAML support does Ruby give the programmer?

It's in the standard library. So... the support is pretty good
See the other post about this and search the archives for more details.
but basically:

sandal:~ daedelus$ cat foo.yaml
first_name: greg
last_name: brown
middle_name: thomas
sandal:~ daedelus$ irb
irb(main):001:0> require "yaml"
=3D> true
irb(main):002:0> a =3D YAML.load(File.read("foo.yaml"))
=3D> {"first_name"=3D>"greg", "last_name"=3D>"brown", "middle_name"=3D>"tho=
mas"}
irb(main):003:0> a["last_name"]
=3D> "brown"

In the interest of further optimizing UMENU, if you use HighLine for
your line interface under the hood, you'll get platform
independence... which means it can concievably help you get UMENU
working on non unix platforms.

Plus... who wants to write validation code when something can already
do it for you?
Or write a platform independant getc, etc etc.

If you do decide to use it, let me know and I can try to help you some.

 

[James Edward Gray II]

My menu system has 613 command choices in 152 submenus, and takes
over 2
seconds to parse on an Athlon XP2600+ with 1.5GB of RAM.

Hmm, I haven't looked into your system at all, but that sounds a
touch slow to me. You might try loading a similar length YAML file
just to compare, and it's not a very fast parser either...

James Edward Gray II