Terminal based browser
A terminal based browser should be based on the traditional browser, that means that you should have multiple divided window:
| -------source------------- |
Ctrl-Tab? would cycle the windows, clipboard functions will use the "normal" shortcuts.
The class hierachy could be displayed using ascii-grapics.
A next step will be to implement some sort of window management like in Turbo Vision. Then we have the ability to implement a windowed transcript and let an error window or debugger pop up on errors. Later on, mouse support could be implemented.
It would be nice if we could hack a ncurses-base for blox :-).
Interfacing ncurses using the C-callout mechanism of GNU Smalltalk is relatively simple. I did a "Hello World" using a ncurses window one day while learning to use the callout mechanism (don't ask me, no backup). You could write wrappers for the ncurses types and functions. (Btw: I don't know if the input of ncurses-based applications have to be polled? And how about mouse-support of ncurses? Or should libgpm used for terminal based mouse support, as done in midnight commander (mc) or links (textmode browser))?
Another question is, if, compared to java, we should use an "awt-" or "swing-like" approach. "Awt" would mean to support many different, in c coded widgets and functions, while the "swing-like" approach would mean that we have to provide positioning, output, input - the rest would be done by GNU Smalltalk.
I think the "swing-like" approach is easier to maintain but I'm open for criticism.
For "awt-like" approaches, I looked at:
- http://dickey.his.com/cdk/cdk.html seems a bit like something we could use. It provides some widgets, but no windows. The advantage is that it's written in C, that means no extra wrappers beyond DLD-Classes.
- Turbo Vision is written in C++. That means extra wrappers and scripts exporting the C++-Classes to C structures. I don't have the skill to write such scripts, but maybe an awk-hacker will read this :-)
There is an issue between portability and function. I have watched the development of a text-based windowing system called twin.
which has widgets and layout management. It is limited to the Linux console and X11 environments (at least according to the web page). This is not as broad as an ncurses implementation.
David S. Cargo (email@example.com)
In my opinion, twin is nice, but a bit to complicated, isn't it? I did a "hello, world"-label with cdk and DLD, but stuck at the moment because of difficulties with the CObject-hierarchy.
From my actual point of view, I think it would be best just to support some features of the ncurses and then panels libraries. Higher level logic should be implemented in GNU Smalltalk.
Markus Fritsche (Fritsche.Markus@gmx.net)
Wednesday, 5 May 2004, 11:27:35 am bnfnnh
Wednesday, 29 October 2003, 1:46:28 pm
Friday, 2 August 2002, 3:12:53 pm The question is: Would it be possible to implement a tui (textmode user interface) without mouse compatible with Blox, or should the system implement it's own hierarchy? I have to take a closer look at Blox, the class hierarchy and the functionality. A little bit annoying is that it is hard to browse the blox class hierachy without a running browser :-)
Tuesday, 3 August 2004, 7:39:12 am .,.,/
- (If possible - I had not looked at it yet) Blox integration
- If we're using the ncurses-bindings: Define a hierarchy of wrapper-classes.
Here is a bit of code. Unpack it, it will generate a directory called ncurs-dist. Then run "gst -Q ncurs-sym.st", that will generate st-ncurses.st, st-ncurses.c and st-ncurses.so. Be sure to use gcc-3.0, because gcc-2.95x dislikes my code (no idea why) :-). Then you could run "gst -Q nctest.st", and you should get a demo application running (pressing "O" should show an "Ok"-Window, "q" quit it, any other key should hide the window).
It's very basic and low level!
If you run "gst nctest.st", it won't run, as gst seem to forget the loaded libraries. ncurses-bindings.tar.gz
Markus Fritsche last edited on 3 January 2003 at 8:22:14 pm by pD958B080.dip.t-dialin.net