[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Curses RAD executables

From: Steve Litt
Subject: Curses RAD executables
Date: Sun, 9 May 2004 11:28:07 -0400
User-agent: KMail/1.5.3

Hi all,

As you know, I'd like to create a RAD environment with three Curses 


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 

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 

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]