[Lazarus] RE : RE : RE : RE : LCL and custom keyboard layouts

[Ludo Brands]

> 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...


> 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.

Ludo