Subject: Re: menuc vs libmenu
To: Phil Nelson <phil@cs.wwu.edu>
From: Brett Lymn <blymn@baesystems.com.au>
List: current-users
Date: 07/25/2000 11:54:53
According to Phil Nelson:
>
>Actually, I initially started sysinst using libmenu with ncurses.
>I quickly fount that it was a real PITA to write the code to create
>the libmenu menus.

FWIW I find creating menus in anything a real PITA - there is a lot of
typing involved to get a little box with a few lines at the right
place on the screen...

>  I had done a menuc like system before and knew
>I found it much easier to provide all those specifications in a
>little language.

Mmmmm a small function that reads some static arrays and does the
menu creation is not hard in libmenu.

>  menuc was much simpler that the previous version
>I did just because sysinst didn't need much complexity.  
>

Yes, I understand that.  When I did the first reply in this thread I
was very concious that _at_the_time_ menuc was done things were very
different.

>There was one version of menuc that took a flag and generated 
>libmenu based code.  (It wouldn't take much of a change to do that
>even now.)

That could be a very interesting thing to have.

>  One reason that it didn't survive to this day was 
>because libmenu required ncurses, which we didn't want to use with
>sysinst.
>

We have our own libmenu now that does not rely on ncurses so perhaps
that functionality can be put back in?  I think that would be very
useful because it will allow us to automated the grunt work involved
in writing menus based systems.

>Just out of interest sake, do you see the design of menuc so flawed
>that "nothing could make it better" or could some added features
>and rework make menuc acceptable?   

I don't think the design was flawed.  I think the requirements for
menuc at the time were much narrower and the design reflects that -
which, in itself, is not a bad thing.  There are some implementation
details that could be fixed up (like the input key handling but your
comments in that code indicate that you would not argue with that ;-)
but if we start extending menuc it is going to move more towards what
libmenu looks like which begs the question "why not just use libmenu?"
Modifying menuc to build on the libmenu capabilities would be a cool
thing to do.

>
>One reason there was no man page was that I wanted to get sysinst
>working first before writing the man page ... and never got to the
>man page.  I will change that if it looks like menuc will survive.
>

Therein lies the problem, in all honesty I did think of using menuc
for a project I was looking at but in the end did not mainly because I
did not want to grovel through some code to try and work out how to
drive menuc.  If I had had a man page to refer to then I would have
been more likely to use menuc.  I understand perfectly that you had
other things to do and did not want to put work into something that
may not get used.  NOTE: I did not write libmenu because of this,
libmenu was written because people specifically (and repeatedly) said
they needed the functionality for sysinst - rather than bring ncurses
into the tree I volunteered to write libmenu and libform.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================