[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 16 Feb 2007 10:21:41 -0700
I will see about making it compile as a stand alone again, As I mentioned in
my email, I broke the standalone ability after this last re-write. I will let
you know when I got something for you to compile.
I really just included SH to demonstrate how you would interact with the
On Friday 16 February 2007 4:55 am, you wrote:
> I tried to compile some of this up - but there seems to be some missing
> header files ?
> $ gcc -c sh.c
> shvar.c:29:25: bstrlib.h: No such file or directory
> shvar.c:31:33: ../uc/eng_types.h: No such file or directory
> shvar.c:32:26: ../uc/uc.h: No such file or directory
> shvar.c:33:32: ../uc/eng_utf8.h: No such file or directory
> shvar.c:37:26: ../fh/fh.h: No such file or directory
> shvar.c:38:27: ../ph/ph.h: No such file or directory
> FWIW - this would be really useful to help 'webify' our Aubit4gl
> (http://aubit4gl.sourceforge.net) - if you fancied lending a hand ;-)
> On Thursday 15 February 2007 16:58, Ricardo Cantu wrote:
> > The concept is quiet simple. We have what is called "the screen handler"
> > (sh), which in the past started off being a ncurses clone then was
> > re-written to utilize ncurses for all screen manipulation. Recently, I
> > re-wrote it again to handle both legacy terminals and FireFox (That's
> > right, only FF, I got tired of cross browser support, it was worst than
> > cross terminal support, you think we would have learned from the mistakes
> > of the past). The SH actually compiles as a separate object that is
> > suppose to be able to link into any application that needs to enteract
> > with the world. I broke this when I re-wrote this last time. I intend to
> > add this ability back after the web ui stabilizes. Right now it requires
> > that the template for the screen resided on a MySql database in a
> > specific proprietary format. Later this will change back to accepting
> > templates that resided in simple text files.
> > Okay, here is the basic idea.
> > In your main app. create wrappers for functions that do not use the form
> > library to output information. In text mode these wrappers would just run
> > the normal NC routine and in web mode you would create a buffer of the
> > data that was going to be outputted. At the point where NC would be
> > outputting the screen (Where I call wrefresh for me) check for text/web
> > mode, if text just call wrefresh, if web, then create a web page using
> > all the data that was saved in the form lib and by your wrappers. Take
> > this text buffer that contains a valid web page and give it to fcgi
> > (Fast-cgi, google it) to hand it to the browser for processing by the
> > tries to setup a ncurses type environment that you can then use to
> > control what happens on the web page as users type. With this script you
> > have total control of everything the web browser does. All keys are
> > blocked from being interpreted by the browser this includes F-keys, tab,
> > enter, etc... Just like an ncurses application using the form lib. you
> > have to REQ_NEXT_FIELD to move the curser to the next field. Then at some
> > point the page is posted back to the server where fcgi receives it and
> > then you take this text buffer that contains all the information that was
> > keyed in on the page and populate the form driver with the data and fall
> > back into your normal processing of data that was supposedly captured by
> > ncurses in your app..
> > The java folder has a folder named jscurses, this is what I tried to
> > write to resemble the ncurses library. At best it loosly resembles the NC
> > lib. Then there is a folder named engine, this is what I wrote using the
> > jscurses routines just as if I was writing a normal ncurses program.
> > It is in beta testing now and running very nicely. I feel like it still
> > has a long way to go, but all the real hard work has been done already.
> > Let me know what you'll think.
3506 Buchanan St Suite C
Wichita Falls, TX 76308
- Message not available
Ricardo Cantu <=