Ruby version of UMENU

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Ruby version of UMENU

Steve Litt-2
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.

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


For documentation, you can read the perl version UMENU docs here:

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

From a user standpoint, the ruby version is pretty much identical to
the perl version.

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

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

EMDL is still Perl only.

SteveT

Steve Litt
http://www.troubleshooters.com
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Gregory Brown
On 12/22/05, Steve Litt <[hidden email]> wrote:
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Steve Litt-2
On Thursday 22 December 2005 01:56 pm, Gregory Brown wrote:

> On 12/22/05, Steve Litt <[hidden email]> wrote:
> > 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/

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

Longer answer: Highline appears to be a programming tool, used by a
programmer, to quickly assemble the user interface for a command
line app. 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.

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 in.

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.

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.

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.

That's the long answer :-)

SteveT

Steve Litt
http://www.troubleshooters.com
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Gregory Brown
On 12/22/05, Steve Litt <[hidden email]> wrote:

> 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 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Chad Perrin
On Fri, Dec 23, 2005 at 06:51:00AM +0900, Gregory Brown wrote:
> On 12/22/05, Steve Litt <[hidden email]> wrote:
>
> > 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.

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.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Gregory Brown
On 12/22/05, Chad Perrin <[hidden email]> wrote:

> 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.

> > 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.

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.  
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.

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Steve Litt-2
In reply to this post by Gregory Brown
On Thursday 22 December 2005 04:51 pm, Gregory Brown wrote:

> On 12/22/05, Steve Litt <[hidden email]> wrote:
> > 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.

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.

>
> > 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 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Steve Litt-2
In reply to this post by Chad Perrin
On Thursday 22 December 2005 08:16 pm, Chad Perrin wrote:

> On Fri, Dec 23, 2005 at 06:51:00AM +0900, Gregory Brown wrote:
> > On 12/22/05, Steve Litt <[hidden email]> wrote:
> > > 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.
>
> 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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Gregory Brown
In reply to this post by Steve Litt-2
On 12/23/05, Steve Litt <[hidden email]> wrote:

> > 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.

That is cool.

> > 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?

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).

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Steve Litt-2
On Friday 23 December 2005 02:08 am, Gregory Brown wrote:
> On 12/23/05, Steve Litt <[hidden email]> wrote:
[clip]

> > 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).

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
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Ezra Zygmuntowicz-3
>
> 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
 >> require 'yaml'
=> true
 >> hash = {:name => 'Steve Litt', :list => 'rubytalk', :topic =>  
'UMENU'}
=> {:list=>"rubytalk", :topic=>"UMENU", :name=>"Steve Litt"}
 >> y hash
---
: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
 >> x = YAML::dump_stream array
=> "--- \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

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

Gregory Brown
In reply to this post by Steve Litt-2
On 12/23/05, Steve Litt <[hidden email]> wrote:

> On Friday 23 December 2005 02:08 am, Gregory Brown wrote:
> >
> > 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).
> <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"
=> true
irb(main):002:0> a = YAML.load(File.read("foo.yaml"))
=> {"first_name"=>"greg", "last_name"=>"brown", "middle_name"=>"thomas"}
irb(main):003:0> a["last_name"]
=> "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.

Reply | Threaded
Open this post in threaded view
|

Re: Ruby version of UMENU

James Gray-7
In reply to this post by Steve Litt-2
On Dec 23, 2005, at 1:48 AM, Steve Litt wrote:

> 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