Re: Curses RAD executables

[Steve Litt]

On Monday 10 May 2004 08:01 am, Eric Lenio wrote:
[clip]

> I write a lot of perl code, so it is my language of choice.  My approach
> was module-based like this:
>
>  * Ncurses::LowLevelWidget
>      * Ncurses::Application (isa LowLevelWidget)
>      * Ncurses::Key (isa LowLevelWidget, stores keyboard events)
>      * Ncurses::Widget (isa LowLevelWidget)
>        * Ncurses::Field (isa Widget)
>            * Ncurses::DateField (isa Field)
>        * Ncurses::Label (isa Widget)
>            * Ncurses::Button (isa Label)
>        * Ncurses::Calendar (isa Widget)
>        * Ncurses::ButtonGroup (isa Widget)
>        * Ncurses::SelectionList (isa Widget, probably similar to your 
> picklist)
>        * Ncurses::Form (isa Widget)
>            * DBIx::Ncurses::Form.pm (isa Form, opens database via DBI)
>  * Ncurses::Logmsg (write status messages to a log file)
>  * Ncurses::Msgbox (simple message box widget)
>
>
> I haven't done menus, that will be added soon.

I might be able to help, if you need help with the menus. I can also help 
document.

> A Form object creates a standard ncurses form, but also it is tied to a
> ncurses panel (since the panel library handles layered forms and thus I
> don't have to think about it).  A Field object is a standard ncurses form
> field.  Other more complex widgets such as the Calendar object are composed
> of multiple Fields and Labels.  Since I use xterms all the time I added
> mouse support as well, albeit it is limited to clicking on a widget which
> forces it to get focus.
>
> The crux of the above is the DBIx::Ncurses::Form object which automatically
> builds Form objects by inspecting the database metadata and laying table
> data out in either a form-based or tabular-based way.  It also will split
> out into multiple Forms if needed (which happens when viewing a database
> table with lots of columns).
>
> The downside to my approach is that since perl is a scripted language the
> memory footprint can get quite big, around 16MB virtual memory is used to
> open a postgresql table.  

That sounds like a non-problem to me. 128MB of DDR costs about $30.00 IIRC.

> But it is still quite zippy to move around in, 
> the latency between key presses is almost always well under sub-second,
> the longest operation typically being the creation of a new Form object.
>
> Note: the above code will be released (GPL'd, via cpan.org) in the near
> future, once I get beyond alpha stages.

Please, please, puhleeeeze let me know when you release it. This sounds a lot 
like what I want to accomplish.

One question -- must an app created with your toolset be GPL, or could it be 
any license, including proprietary?

Thanks

SteveT
 
Steve Litt
Founder and acting president: GoLUG
http://www.golug.org


>
> On Sun, May 09, 2004 at 11:28:07AM -0400, Steve Litt wrote:
> > Hi all,
> >
> > As you know, I'd like to create a RAD environment with three Curses
> > executables:
> >
> > rad_menu
> > rad_form
> > rad_picklist
> >
> > Each of these three executables would be written in C, licensed GPL. Each
> > is completely data driven, such that every aspect of the form, picklist
> > or menu, both data and metadata, is defined in data passed via stdin or a
> > file. These executables are linked with business data and business logic
> > via a glue language such as Perl, Python, or even Bash, C or C++. Look at
> > the advantages:
> >
> > 1. Executables are more modular than any other type of linkage.
> > 2. Portable on any Nix box
> > 3. Fast development
> > 3.5  Ability to write front ends to create the data for these executables
> > 4. Ability to fully utilize Unix pipes and redirects in the application
> >
> > 5. The data driving the executables can be ANY license without
> > compromising the GPL of the executables themselves.
> >
> > The big challenge is creating a persistent Curses across all executables
> > and scripts. Here's my plan:
> >
> > I'll have a function called rad_dump() that dumps every window as a file,
> > and saves those files as a stack implemented as a doubly linked list. It
> > also saves various other data. Then the next executable calls a
> > rad_recall() that restores the exact environment of the preceding
> > executable. The rad_dump() uses the Curses putwin() to store each window,
> > pushing its filename on the stack. The rad_recall() function uses the
> > Curses getwin() to get the windows back.
> >
> > Unless I've overlooked something, this creates the equivalent of a
> > persistent Curses across various executables. And it doesn't just save an
> > 80x25 screen -- it saves all windows as windows so that windows created
> > in one executable can be destroyed in the next, revealing the underlying
> > window. In this way I believe that these glued together executables will
> > look to the user basically as a single executable.
> >
> > The executables described above are the interface to the user. I
> > anticipate the interface to the data being the psql executable (or mysql
> > if you swing that way). The business logic will be written by the
> > programmer, in Perl, python, etc. Forms and their contained fields will
> > have some business logic in the form of validation routines and fields
> > calling picklists.
> >
> > Comments are appreciated.
> >
> > SteveT
> >
> >
> >
> > _______________________________________________
> > Bug-ncurses mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-ncurses