[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Curses RAD executables
Re: Curses RAD executables
Mon, 10 May 2004 08:46:04 -0400
On Monday 10 May 2004 08:01 am, Eric Lenio wrote:
> 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
> * 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
> 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?
Founder and acting president: GoLUG
> 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
- Curses RAD executables, Steve Litt, 2004/05/09
- Message not available
- Message not available
- Re: Curses RAD executables,
Steve Litt <=