GT Slang driver A GT Slang driver for Harbour (gtsln) is based on a S-Lang library written by John E. Davis. It was developed using Slang version 1.41, although prior versions of Slang up to 1.22 should also work, but they are not recommended because of some bugs they have. The main OS it is developed to be used on is Linux. Slang was ported to other OSes so it should be possible to use it on other systems too. I've also successfully compiled and tested gtsln under MS-DOS but I don't think it makes any sense to use it on that system instead of gtdos, due to its limitations and incompatibilities with CA-Cl*pper (see below), so I removed MS-DOS support. A gt Slang driver is a second driver which can be used on Unix based OSes. The first one is a gt driver based on a curses library (gtcrs). Due to the fact that curses is a standard library on Unix like systems, gtcrs should be considered as a primary gt driver for such OSes. Compiling a gt slang driver ... -------------------------------- The driver should be automatically compiled when you build Harbour from sources, regardless of what gt driver you've chosen by setting HB_GT_LIB. Successful compilation requires Slang library and Slang header files properly installed on your system. The driver expects Slang header files to be placed in /slang/ directory on Linux based systems ( this usually means /usr/include/slang on most of them ) and on other systems (which is usually /usr/include). To build programs (by using a bld.sh script from Harbour sources), which will use a gtsln, you need to : - have a Slang library and header files properly installed - set an environment variable HB_GT_LIB to gtsln - modify bld.sh by adding -lslang to a link command Generally you always need to add -lgtsln -lslang to your link libraries to build programs which are supposed to use a gt slang driver. Internationalization ---------------------- I made an attempt to support national characters handling, but I am not sure if it is done in a proper way. The implementation supports only one byte encoding, thus Korean and other two bytes encodings are not allowed. It assumes national characters are placed in an upper 128 bytes of ASCII table from a normal character set. "Normal" means not "alternate character set" here, because "alternate character set" is generally used to display graphics characters. It also assumes national characters can be entered for example by pressing an key and a particular key on a keyboard to get a desired national character. If this is impossible on some terminals due to their lack of possibilities, an alternate method which uses Dead keys, is implemented. To be able to see and to enter national characters one should : - have a proper font table loaded - optionally have a software installed to allow enter national characters in whatever way they should be entered - have an environment variable HRBNATIONCHARS properly set (see below) - optionally have a HRBNATIONDEADKEY defined (see below) An environment variable HRBNATIONCHARS should contain a list of character pairs. A first character from each pair should be a character from a lower 128 bytes of ASCII table, which should be pressed after a Dead Key was pressed, to get a desired national character. The second character is a national character itself. Those pairs should be defined even if a Dead key is not used (because a terminal supports other method of entering national characters - for example ). If a terminal does not support entering national characters by using an ALT key (or the other similar) an environment variable HRBNATIONDEADKEY can be defined. It should contain a character which should be pressed *before* a particular key on a keyboard is pressed to get a desired national character. The reason I am using HRBNATIONCHARS envvar is simple. I want to give a better graphics chars support when the same code is occupied by a nation char and by a graphics char. Because on terminals there are usually two glyph's character sets (normal and alternate) knowing nation's characters codes, I can switch to normal character set when a nation character code is encountered, while still being in an alternate character set for other characters. This way I can draw boxes properly using box drawing commands even though characters for box drawing occupy the same code a nation chars occupy. So commands like : @ Y1, X1 TO Y2, X2 [ DOUBLE ] @ Y1, X1, Y2, X2 BOX "" should write boxes well. However commands like : @ Y, X SAY Chr( ) will draw a nation char when it occupies the same code as occupies. I don't know a better solution in this case. Any ideas are welcome. This implementation works better than it would ever work in MS-DOS where there is no way to do such tricks (because there is only one glyph's character set without VGA tricks). Using environment variables gives a configuration flexibility to Harbour programs for different users and different code pages. To change a code page one should only change HRBNATIONCHARS var (if a Dead key is used) and this can be done from a script which runs a Harbour program. Let's see an example. Suppose one national language has three national characters : 'ĄĆĘ' which correspond to 'ACE' in a lower 128 bytes ASCII table. 'Corresponding' means that to get a 'Ą' nation char one has to press a special keyboard modifier (like ALT+R for example) plus an 'A' char. HRBNATIONCHARS should be defined as : HRBNATIONCHARS=AĄCĆEĘ where AĄ is a first pair, CĆ is a second pair and so on Suppose also we are working on a terminal which does not allow to enter national characters by pressing , , . Because we like a character '`' (\140 in octal), we arbitrary choose it as a Dead key. So we define HRBNATIONDEADKEY as : HRBNATIONDEADKEY=\` or in other way : HRBNATIONDEADKEY=`echo -ne '\140`' Now we can enter Ą by pressing ` and then A, Ć by pressing ` and then C, and so on. To get '`' character we need to double press `. Limitations, incompatibilities with CA-Cl*pper, errors ... -------------------------------------------------------- The driver is rather limited in comparison to other Harbour gt drivers and has many incompatibilities with CA-Cl*pper. Some of those limitations and incompatibilities are caused by an Unix behavior, others are caused by a Slang implementation. There are also some caused by a gt layer design. Not to mention that there are probably some caused by my lack of knowledge. Here is a (probably not complete) list of them : - a driver allows only 128 combinations of FgBg colors. It means you can use 16 colors for Fg, and only 8 colors for Bg. - you can't get intensity/blinking background mode working (this is in fact the previous problem, just worded differently) - you can't display characters with values below 32 (control characters). It is a very important limitation because you can't use many useful chars which you used under CA-Cl*pper. This is an OS limitation which Slang also inherits - displaying chars above 128 widely depends on terminal possibilities. Because of this on xterm I set all frame chars to a single frame (this means - double and mixed frames are shown as a single frame). You should not expect to see chars above 128 shown properly in all cases. - a screen is automatically cleared on program's startup (you can't inherit it from a system) and a cursor is set at 0,0 - when you run external programs a screen is restored after execution so there is no possibility to interact with screen handling between two programs - you can't expect cursor hiding and cursor style changing to work at all. Although on a text-mode Linux console it works, this is a Linux text-mode hack only and it is hardcoded. For example on xterm only cursor hiding works well. - it is not guaranteed that programs which use DispBegin() and DispEnd() will work well in all cases, although generally it should work - a screen size change does not work at all. This is a big problem on an xterm where you can change a window's size at your request. Doing this confuses a Harbour program - CA-Cl*pper programs which utilized PC hardware specifications about screen construction (an array of char+attr) (for example to make quick shadow on a screen) can't run properly. There is no hardware emulation at all - Tone() support currently works for Linux console only. - keyboard handling is VERY LIMITED. Generally you should not expect ALT+key, CTRL+F and CTRL+ combinations to work at all although they work on a text-mode Linux console. This is a very big problem and at least any solution should be developed to emulate this. One attempt is a Dead key workaround I've implemented for national characters and a Meta key to simulate Alt key. By default as a Meta key I've chosen ESC key pressed once (like in most Linux programs). - abort key is CTRL+\ not CTRL+BREAK on Unixes - to get an ESC key you have to press ESC twice. This is an issue related to OS behavior where ESC begins a control sequence - currently there is no mouse support. This is a TODO item - Out() functions do not work well. This is caused by a design of a gt layer where writing directly to STDOUT is done outside Slang, so Slang can't maintain screen changes properly. - redirecting Out() to a file results in writing control chars which were supposed to initialize a terminal, to that file - monochrome displaying support is currently broken Terminfo database ... ----------------------- Slang gt driver is based on a terminfo database so it is very important to have it properly set. Most problems are related to a broken terminfo file. I don't have general advice about that. You are supposed to help yourself. The only thing you should know is that you must not have sequences for and function keys set in a terminfo file if you want to use and keys (of course they all should be defined there). Why use gt slang driver ... ----------------------------- Well, personally I find only two reasons. When CA-Cl*pper compatibility and current limitations are not a problem, gtsln is a little bit faster than gtcrs and my experiences show that sometimes it works a little bit better than gtcrs on real terminals (tested on wy60 where gtcrs did not handle the keyboard well). TODO ------ - keyboard emulation on terminals with lack of possibilities - support for mouse on Linux text console and on xterm - fix a problem with redirecting output to a file or a pipe - find a way to inherit screen from a system at startup (is it possible at all ?) - sound support on Linux using native sound system (Alsa ?) - support for sound on other systems than Linux - fix working on monochrome terminals - add a PC video card hardware emulation Marek Paliwoda PS. I want to apologize for any English errors and any technical errors in this text.