From: Eric Auer
Date: Fri, 7 Feb 2003 09:55:17 +0100 (MET)
To: Hennie Brugman / Peter Wittenburg of MPI
Subject: stand van zaken input method editor

Hoi, hier een wat uitgebreidte mail over de stand van zaken
met mijn stage project. Zo te zeggen ipv. bijpraten, maar
eigenlijk heb ik ook nog genoeg TODOs en een niet te vage
idee van welke kant op ik programmeer op mijn eigen agenda.
Maar lees zelf (hoef je niet per se uitgebreidt en snel te
lezen, feedback heeft tijd tot volgende week en mijn mail
is sowieso over work in progress):

Ik heb even een zip van mijn work in progress op /home/ericauer/editIM.zip
gezet. De inhoud is te compileren met:
javac -classpath .:guk/resources/ -extdirs .:guk/resources/  guk/Editor.java guk/editIM/*.java
En te "runnen" met:
java -cp .:guk/resources/ -Djava.ext.dirs=".:guk/resources/" guk.Editor
(steeds in de map waar het zip ontpakt wordt)
Als er een bestand of symlink naar arialuni.ttf in deze map is, wordt deze
gebruikt (nuttig als eigentlijk geen Arial Unicode op een systeem geinstalleerd
is). Bijvoorbeeld heb ik een kopie in:
/home/ericauer/linuxbin/share/yudit/fonts/arialuni.ttf (24MB!)

Er is al veel GUI LOOK maar nog niet veel GUI feel. De look is ongeveer
zelf-uitleggend. Centraal staan de twee tabellen (key sequence to glyph
boven, en key sequence to glyph sequence beneden) en de glpyh preview
button.

Men kan links (TODO: werking... ik heb sowieso echt problemen, GUK zonder
gebruik van .../lib/ext/*.jar te gebruiken!) een van tien top tien input
methods kiezen waarmee men dan tekst in de tabellen zou invoegen, en het
is mogelijk, aan de tien buttons een willekeurige keuze van IM toetekennen.
De menu punten onder Virtual Keyboard zullen GUK sturen, maar...
...tenminste als guk met mij praat, ben ik van plan, de mogelijkheid
toetevoegen, meerdere virtuele keyboards tergelijk te zien, indien dit
nuttig lijkt.

De twee Unicode menus bieden de mogelijkheid, per "afdeling" van Unicode
(soms ook in kleinere delen gedeelt, indien nuttig) de zichtbaarheid in
de tabel boven aan en uit te zetten. Als je iets op zichtbaar zet, scroll
je ook automatisch daar in de buurt (buggy, zou precies daarheen zijn).
In het Unicode I menu kun je verder nog alle niet gebruikte glyphs op
onzichtbaar zetten, dwz. alle waarvoor geen key sequence gedefineerd is.
In de tabel boven kan men trouwens niet de glyphs bewerken, dat kan slechts
in de tabel beneden. Boven is er gewoon een stuk van ieder bestaande
Unicode glyph.

In de tabel beneden kun je aan een key sequence een hele glyph sequence
toekennen. Daarvoor kun je gebruik maken van de glyph button (volgt steeds
de selectie boven) als clipboard (met history) (TODO: invoegen vanuit de
glyph button is nog niet geactiveerd). Als je de laatste regel selecteerd,
komt er automatisch een nieuwe regel bij. Als je een regel helemaal leeg
haalt dmv. bewerken, wordt deze verwijdert (door selecteren angemaakte lege
regels worden pas na bewerking indien leeg verwijdert).
Om wat overzicht toetevoegen, worden de IM buttons (slechts ruimte voor de
2 letter taal afkorting) en de glyphs boven afhankelijk van hun Unicode
"afdeling" en locale naam ingekleurd. Verder is er nog gedetailleerde bubble
hulp / tool tips.

In het veld tussen Unicode II en help kun je of een unicode glyph of een
escape (\u1234, waarbij 1234 hexadecimaal is) ervoor intikken, om een plek
in de tabel boven te bereiken.

Bij file kun je (nog niet dus! TODO!) mappings (key sequences naar unicode)
in verschillene bestandsformaten (ik dacht aan GUK, MPI, en misschien nog
Yudit, Emacs, ...?) lezen en schrijven (dus ook omtoveren van X naar Y...),
van en naar de glyph tabellen. Misschien (???) gaat het ook mogelijk zijn,
mappings uit draaiende GUK IM instanties te lezen, is dat nuttig??? Ik ben
niet meer van plan, live nieuwe mappings in GUK IM te creeren (Locales zonder
bestanden dus), MAAR ik denk het zou een idee zijn, live EEN actuele GUK IM
instantie te updaten terwijl je de tabellen bewerkt. Zou zoiets nuttig zijn?
Ik denk slechts dan, als er een test-veld is of nog beter als mijn editor zich
aan een draaiende GUK instantie van iets anders kan koppelen (of natuurlijk
als een "editor aware" ding zoals toekomstige ELAN / EUDICO versies een
instantie ter bewerking aan mijn editor doorgeeft).

Nog verdere problemen (behalve problemen, client en niet slechts beheerder
van een GUK IM instantie te zijn!): De hulp kan wat langer / leuker worden,
ik moet nog onderzoeken, waarom Java de Linux KDE clipboard functie helemaal
negeerd (echt lastig! anders had ik bijv. uit Mozilla wat Japaans in de
tabel beneden kunnen kopieren, of natuurlijk de glpyh preview button naar
clipboard functie kunnen activeren...), en waarom het me niet lijkt te
lukken, de "top 10 locale buttons" aan hotkeys te koppelen.

elangrijkste TODOs: conversie key events van/naar string (in de formaten
human readable/tabel, GUK IM bestand, ... bestand), editor voor tabel
beneden (glyph preview button cut and paste...), import/export tussen
GUK IM, MPI IM (.u8), ... bestanden en editor (tabellen) en misschien
draaiende GUK instanties, misschien inclusief live-update bij bewerking
van de tabellen.
Minder belangrijk: Alles wat met communicatie met draaiende
GUK IM (en algemeen IM, ook MPI enzo.) te maken heeft - mappings in
bestanden bewerken is ook nuttig.
Weinig belangrijk: GUK virutal keyboard
en FSM bewerken als mogelijkheid, dingen in de editor te tikken EN/OF
als feedback (misschien met meerdere keyboard versies tergelijk op scherm),
maar daarvoor zou een "test intik veld" nodig zijn. Zo'n veld doe ik
misschien beter uit eigen kracht dan dmv. communicatie met GUK, daar ben ik
nog niet zeker over.
Gebruik van het systeem-clipboard en diens communicatie met Java vindt ik
dan ook belangrijker (voor nu) dan problemen met live-instanties van GUK).

Omdat er toch wel wat mogelijkheiden voor de beschrijving van key events
zijn, stel ik voor, een uitgebreidte versie van het GUK IM mappings bestands
formaat te bouwen en GUK in staat te zetten, dit te gebruiken. Hoe de key
events dan te verzamelen zijn is het andere probleem: Dit hangt sterk
ervan af, hoe nuttig een "ctrl-altgr-muismidden-h-a-l-l-o" zou zijn en hoe
lastig het is, dit met knippen en plakken en escapes in de editor te tikken
(syntaxis is ongeveer: \k+control button2 pressed ALTGR+hallo\k+control
button2 released ALTGR+ of erger, maar natuurlijk hoeft niet het hele "hallo"
met ctrl altgr button2 getikt te woorden. Bijv. is het al interessant, alle
ingangen van glyph-strings met betekenis "steden" met key sequences van de
soort ctrl-alt-s ctrl-alt-t te beginnen en de rest van de stadsnamen gewoon
uit gewoon intikbare tekens te bouwen, zodat ^^s^^t een soort van poort/slot
tot deze strings voorsteld. In DIT geval is het dan makkelijk, het ^^s^^t
gedeelte met knippen en plakken te verspreiden.

Als een ding direkt of met behulp van een bestaande input method intetikken
is, kun je het direkt als key intikken. Ctrl en Alt met iets werken ook
gedeeltelijk, daar kan ik waarschijnlijk know how van GUK overnemen. Verdere
rare soorten shift (zoals altgr) worden misschien moeilijk, maar op de andere
kant zou het ook mogelijk zijn, alle keyboard events tot ENTER aftetappen en
in \k+...+ syntaxis aan de editor doortegeven (probleem: dan wordt een horiz.
scrollbar waarschijnlijk nodig...).

Zover dus mijn bericht tot incl. deze week, ik ga dan maar voortijdig tot
weekeind over (maar heb deze week wel al heel wat gedaan, natuurlijk).
Feedback kan altijd, maar ik verbouw natuurlijk niet graad helemaal alles
weer. En ik kan ook gewoon met nauwelijks feedback op de weg van mijn eigen
planningen blijven doorgaan. Trouwens, ook al heb ik GUK nog niet verandert,
heb ik toch al de bronnen en documentatie ervan gelezen, dus zou het met
lezen/schrijven van GUK/MPI keymap bestanden wel meevallen.
En tenslotte natuurlijk: Hoe zou ik mijn tijdplanningen inrichten? Liever
klein en af of liever de interfaces voor latere uitbreiding (door mij,
Hennie, of iemand anders) vrij houden voor "the big picture"?

Groeten, Eric.


