Over the last few weeks I've hacked together a partial APL implementation, for use as a way of specifying lists of numbers etc. when passing commands between computers implementing a large distributed system. For test purposes I've compiled it on Linux as a command-line app and am using FPC's keyboard unit to implement a layout similar to http://www.aplusdev.org/keyboard.html, with Alt as meta and Esc to go into composition mode (use cursor keys to move between the glyphs on each key). Internal storage is in widestrings, external files etc. UTF-8.

I now want to move the parser and evaluator into an LCL-based app, which will ideally allow at least partial editing of APL-style expressions rather than reading everything from configuration files.

What is the situation with LCL editing components, Synedit, Cmdline and so on? Is there a single underlying keyboard component, or at least a uniform interface?

In short, where do I start? :-)

On Windows you'd write an IME (Input Method Editor), that allows to compose strings from keystrokes. Don't beat me - I only know that something like that exists ;-)

The display should not be a problem. AFAIR is the APL charset part of Unicode, so that you can use SynEdit. Write an APL syntax highlighter for it, if you like.

Commandlines? Perhaps using the IME, provided that you can tell the console to use it ;-)

DoDi

No only niggle- and this is a minor one- is that some of the odder characters I'd have liked to have been able to use (in particular, German blackletter) are outside the 16-bit Unicode range.

Commandlines? Perhaps using the IME, provided that you can tell the console to use it ;-)

I'll start digging in and see where I get to, but any suggestions- particularly relating to Linux- will be welcome.

Not sure if it helps:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22339

Microsoft Keyboard Layout Creator 1.4

I'll start digging in and see where I get to, but any suggestions- particularly relating to Linux- will be welcome.

Under X11 you can modify your keyboard to your likings. 4 levels per key are standard using Shift and 3 lvl key (Altgr on most non-Eglish kbd but configurable to any key). Keys can be defined with their unicode code (Uxxxx format).
A nice howto here:
http://people.uleth.ca/~daniel.odonnell/Blog/custom-keyboard-in-linuxx11 . As usual, locations of the kbd files differ from distribution to distribution and even between versions.

Ludo

Thanks Ludo. I'm already doing a bit of custom stuff to get A+ running (arguably the largest free APL that still uses the original characters). But the question remains: once inside a Lazarus app, can I hook keycodes using a custom procedure, translate them to Unicode, and inject them into the currently-focussed edit-capable control?

Take a look at the OnKeyDown and OnKeyUp events. Their "Key" argument is a "var" one. You can "cancel" the default routine of the control the handler is assigned to by setting the "Key" to "0" after you processed it.

E.g.

procedure TForm1.Edit1KeyDown(Sender: TObject; var Key: Word; Shift:
TShiftState
   );
begin
   Key := 0;
   Edit1.SelText := #$e2#$9b#$a4;
end;

This will insert a "pentagramm" at the current cursor position of "Edit1" (you'll only see it if you have a font that contains that character).

You will then need to implement things like "key is hold down thus insert character until released" yourself using a timer and OnKeyUp.

Also you can assign one event handler to multiple TEdits (or other controls that support OnKeyDown/-Up) so you have only one routine which uses the "Sender" parameter to differentiate the action to do.

PS: Maybe this is not the best solution (I never needed to do something like this), but it should work.

Regards,
Sven

Thanks Sven, doesn't sound too arduous. I'll investigate, it reminds me of some keyboard handling I wrote for a Delphi comms app based on a standard grid control.

I've got no intention of doing large-scale data entry or anything like that, so I don't think I really need to consider things like Synedit at this point. But it would be useful to be able to enter expressions into e.g. a grid, a particular example- and what I'm going to use as the next test app- being "shorthand" to populate tables for a filter that transposes notes in a MIDI data stream.

Lazarus uses utf8. If your system is also using utf8 you shouldn't be doing anything special to get these characters inside a control (apart eventually from the font not being able to display the special characters). If I do a 'setxkbmap -layout ru' on my en_GB.UTF-8 machine, I get russian characters everywhere, including lcl controls.

Ludo

Although setxkbmap assumes that somebody with admin rights has set up the appropriate files: I'm fairly certain that there's not a standard one for APL (which is, at best, a minority interest). You can do a bit with xmodmap, but things rapidly start getting messy: X has been rather halfhearted in its embrace of Unicode.

These guys did it :
http://mail.python.org/pipermail/python-list/2011-March/1267379.html. Cut and paste ;)

Ludo

Except that that's /not/ Unicode at the application level, it's 8-bit KAPL encoding. This whole area is somewhat messy, since most APL implementations- not to mention the software that they execute- go back to the days of Selectrics and EBCDIC card punches. Apart from the things I've been tinkering with over the last few weeks the only other implementation that I know is based on UTF-8 is Paraplegic http://code.google.com/p/paraplegic/, the rest are mired in backwards compatibility issues.

You probably didn't notice that a few weeks ago I asked whether FPC could handle things like ? as a function name. At the time I was wondering whether APL's functionality could be supplied as Pascal functions, I've got various numeric analysis jobs where a fusion of APL and a grid containing the result of a database query could be very useful.

I've found a couple of possible issues relating to Unicode handling in (Sorokin's) TRegExpr and in TStringList, I'll try to get them reported with test code over the next few days now that I've got the bulk of the parser/evaluator out of the way, and before I start on the Lazarus app with probable refactoring.

I'm not trying to sell anything:) I'm just starting from the principle that whatever you can do on the keyboard layer is transparent for the app and is all benefit. Using OnKeyDown is a messy solution once you get into actually implementing it. The shift state is a serious complication. An example: I don't know if this is a bug but the 'AltGr' key (the lvl3 XKB key) is not showing up in the Shift:TShiftState on linux. So on my french keyboard I can 't make the distinction between 'e' and '?' or '(' and '['. Another difficulty is that the caps state isn't correctly reflected in the shift state. The caps key is correctly detected when pressed but the shift state doesn't reflect it. Hard to track if you don't know what its state is when you enter the app...

If you have characters outside the 16 bit range, why don't you stick to utf8? The utf8 routines in the LCL make parsing utf8 strings almost as easy as parsing widestrings. And TRegExpr and TStringList work fine with utf8.

Ludo

Ludo Brands wrote

> Except that that's /not/ Unicode at the application level, it's 8-bit > KAPL encoding. This whole area is somewhat messy, since most APL > implementations- not to mention the software that they > execute- go back > to the days of Selectrics and EBCDIC card punches. Apart from > the things > I've been tinkering with over the last few weeks the only other > implementation that I know is based on UTF-8 is Paraplegic > http://code.google.com/p/paraplegic/, the rest are mired in backwards > compatibility issues.> I'm not trying to sell anything:) I'm just starting from the principle that whatever you can do on the keyboard layer is transparent for the app and is all benefit. Using OnKeyDown is a messy solution once you get into actually implementing it. The shift state is a serious complication. An example: I don't know if this is a bug but the 'AltGr' key (the lvl3 XKB key) is not showing up in the Shift:TShiftState on linux. So on my french keyboard I can 't make the distinction between 'e' and '?' or '(' and '['. Another difficulty is that the caps state isn't correctly reflected in the shift state. The caps key is correctly detected when pressed but the shift state doesn't reflect it. Hard to track if you don't know what its state is when you enter the app...

Might be worth looking at xmodmap output. It's a long time since I've had to fiddle with this sort of thing (except in the context of APL), but even with UK keyboards I find a certain amount of variability particularly in the context of the Alt and Alt Gr keys.

> You probably didn't notice that a few weeks ago I asked whether FPC > could handle things like ? as a function name. At the time I was > wondering whether APL's functionality could be supplied as Pascal > functions, I've got various numeric analysis jobs where a > fusion of APL > and a grid containing the result of a database query could be > very useful.> > I've found a couple of possible issues relating to Unicode > handling in > (Sorokin's) TRegExpr and in TStringList, I'll try to get them > reported > with test code over the next few days now that I've got the > bulk of the > parser/evaluator out of the way, and before I start on the > Lazarus app > with probable refactoring.> If you have characters outside the 16 bit range, why don't you stick to utf8? The utf8 routines in the LCL make parsing utf8 strings almost as easy as parsing widestrings. And TRegExpr and TStringList work fine with utf8.

Noted, but there's also an outer parser which resembles Smalltalk more than APL, and that relies very heavily on lookahead and lookback- pretty nasty code to get it doing "the right thing" in most cases. What I've got is adequate to allow keywords/selectors to be defined in e.g. Far Eastern scripts, and I'm fairly sure UTF-8 would get very messy.

Anyway, after all this messing around perhaps my resistance to the idea of an EBCDIC-based FPC port is a bit more explicable :-)

All LCL applications use the TWinControl.OnKeyDown, OnKeyUp, OnKeyPress and OnUTF8KeyPress events which give almost all information about the keyboard. There is also LCLIntf.GetKeyState, but is less used. All of those in the end are calls to the underlying widgetset which does the real work, we just convert the result from the widgetset into the formats supported by the LCL.

So you should not be thinking initially at LCL support for your keyboard, but instead in supporting for example X11 (supposing we are talking here only about Linux). I have no idea how X11 interfaces with the keyboard, but the LCL interfaces with it via X11 (the most direct relationship is only in the LCL-CustomDrawn widgetset, but I think that Gtk and Qt use X11 too for their keyboard code). So if your keyboard interfaces correctly with X11 then it should work with LCL apps too.

Except for this the other idea which I would have is hacking the LCL widgetset code to make use of your custom keyboard directly, but then it won't work for pre-compiled applications. Doing this in the LCL-CustomDrawn widgetset might be the easiest because it is the smallest, but its X11 version still has no text support.

Thanks for that Felipe. So if I'm reading you correctly, as a crude hack I should be able to start by hooking OnKeyDown etc. as exposed by (instances of) descendants of TWinControl. But there's probably more ethical ways to do it based on at least partial replacement of elements of the LCL.

Mark Morgan Lloyd wrote

Thanks for that Felipe. So if I'm reading you correctly, as a crude hack I should be able to start by hooking OnKeyDown etc. as exposed by (instances of) descendants of TWinControl. But there's probably more ethical ways to do it based on at least partial replacement of elements of the LCL.

Maybe I am missunderstand here, but you want to send keyboard events from the hardware to the LCL application correct? If yes, then No, you dont want to hook to OnKeyDown. OnKeyDown is what the control handles (actually usually the KeyDown virtual method), but is not the first step in the event chain.

If you want to simulate a keyboard you have to send LM_KEYDOWN / LM_KEYUP and UTF8Char messages to controls. Convenience routines for sending those messages are located in the unit lcl/LCLMessageGlue.pas in these routines:

function LCLSendKeyDownEvent(const Target: TControl; var CharCode:
Word; KeyData: PtrInt; BeforeEvent, IsSysKey: Boolean): PtrInt;
function LCLSendKeyUpEvent(const Target: TControl; var CharCode: Word;
KeyData: PtrInt; BeforeEvent, IsSysKey: Boolean): PtrInt;
function LCLSendCharEvent(const Target: TControl; var CharCode: Word;
KeyData: PtrInt; BeforeEvent, IsSysKey, ANotifyUserInput: Boolean):
PtrInt;
function LCLSendUTF8KeyPress(const Target: TWinControl; AUTF8Char:
TUTF8Char; IsSysKey: Boolean): PtrInt;

So these are the routines you want to use for a LCL-only solution.

For a system wide solution you would need to figure out how to get your keyboard messages to X11.

No. I don't want to simulate a keyboard, I want to be able to pick up an Alt or Meta shift so that if my keyboard was engraved like http://www.aplusdev.org/keyboard.html I could get the extra characters into editing controls as UTF-8.

I've got something acceptable working with pure FPC, and envisage this notation being useful internal to a program to specify ranges of numbers etc.

I didn't follow this thread in detail, so if I got the wrong end of the stick, please ignore this message.

I use "Programmer Dvorak" layout - which can be applied to any OS and any keyboard - does this for me. No programming required from my side. Programmer Dvorak supports many extra keys via Alt and Meta.

They original author of Programmer Dvorak supplies drivers or keyboard layout profiles for Linux, Windows, Mac etc. So maybe you could learn something from what he did? Just a thought.

http://www.kaufmann.no/roland/dvorak/

Thanks, but there's still the issue there that it would need stuff installed outside of the single binary, and it's unclear whether it could originate 16-bit characters.

As a summary, at the level of an individual control (specifically, synedit) hooking OnKeyDown and OnKeyUp and using those to toggle a flag for the AltGr key (which my system at least lumps in with Alt as far as the shift parameter is concerned) allows me to see the non-standard key combinations. A lookup table converts to the applicable UTF-8 characters, which I can then inject using the target control's IntfUTF8KeyPress(), noted your suggestion of LCLSendUTF8KeyPress() but that's only available in trunk.

I've not yet investigated the behaviour of Solaris, which has a compose key for dieresis etc.