Vstupní metody aneb Japoncům ASCII nestačí (diskuse)

[🇵🇸]

Ó, tisíceré díky za článek!

Pokračování popisující a porovnávající různé metody vstupu by fakt bodl. Co já si užil s Cannou a s rozbíháním SCIMu v KDE... Ostatně, nějak rozebrané non-SCIM metody třeba v KDE (tzn. bez tahání si do čistého systému gnóma apod. -- ukamenujte mě), porovnání jejich střev se SCIMem a tak... to by také nebylo od věci.

[napetsy]

ありがとごさいます。 Tusite zda existuje moznost rozpoznavani kanji znaku podle jejich rucniho kresleni (funkce dostuplna v MS Windows pro Japonstinu)?

Dekuji

[vch]

ありがとうございます。

[vch]

Jinak, takovy program by byl fajn, taky ale zadny bohuzel neznam.

[🇵🇸]

Co Tegaki? (Nezkoušel jsem, jenom vím, že to existuje.)

[Andrej Herceg]

Také niečo vie napr. kanjipad (je to aj samostatný program a býva aj súčasť iných programov), prípadne, rôzne programy používajú iné, ale podobné metódy.

[Andrej Herceg]

A existuje aj Tomoe (má aj verzie pre uim a scim).

[elenril]

Hezký článek, snad mi pomůže konečně zprovoznit japonštinu. Ale doufal jsem ve víc teorie -- na jaké úrovni a jak všechny ty metody pracují, jaké jsou mezi nimi rozdíly, proč tu kterou zrovna vybrat a tak.

[Dancer]

Nu, škoda, že takový článek nevyšel před rokem, kdy jsem tuhle věc řešil pro svou japonskou ženušku. Nakonec jsem nainstaloval celé Ubuntu v angličtině, takže se SCIM nainstalovalo automaticky. Nyní alespoň vím víc pro případnou budoucí rekonfiguraci. Tímto autorovy posílám své díky!

[Dancer]

Oprava - nainstaloval jsem Ubuntu v japonštině + anglickou a českou klávesnici.

[Jan Zahornadsky]

Koukám na ten gcin (teda na jejich trac) a nevypadá úplně špatně. Zdá se, že umí Boshiami (nebo jak se to píše) i nějakou Tchajwanštinu, ale to podle mně je úplně mimo zaměření kteréhokoli Čecha (a taky velké části Tchajwanců). Asi jediné, co by z toho průměrný člověk použil by byl ten 注音 a proto mě zajímá, nevíte někdo, jaký je rozdíl mezi tím gcin注音 a 新酷音 (chewing)?

[petr_p]

Článek není špatný, ale chtělo by to více teorie nebo alespoň podrobnější vysvětlení, na co je jaká konfigurace dobrá, a ujasnit si názvosloví.

Za prvé vstupní metoda není xim nebo gcim nebo scim, ale prostě algoritmus pro zadávání znaků. gcim je jen konkrétní implementace (program) algoritmu, scim je sjednocující kontejner pro různé implementace metod (proto se do něj instalují tabulky definující vstupní metody) a xim je protokol X input vrstvy.

Tady totiž chybí teorie, že možnost využít vstupní metody je přímo zabudovaná do X11 a to skrze protokol xim. Tudíž máme-li implementaci vstupní metody, která tento protokol umí (například scim), můžeme zadávat složené znaky do „libovolné“ xové aplikace.

Proto se definuje proměnná XMODIFIERS, která říká, že aplikace může skrze libX11 přefiltrovat vstupní symboly přes vstupní metodu a nechat si unést okno programem implementujícím metodu (například XMODIFIERS=@im=SCIM xterm).

Výše jsem použil uvozovky, protože xim má svoje omezení a mimo jiné sada widgetů aplikace musí trochu spolupracovat. (Vývojáři Xorg si toho jsou vědomi a hodlají spolu s opuštěním příšerné definice klasických rozvržení klávesnice xkeyboard-config vytvořit nový způsob, který bude lépe řešit i vstupní metody.)

Proto také velké knihovny widgetů jako GTK nebo Qt mají vlastní rozhraní pro vstupní metody a implementace vstupních metod implementují i jiné rozhraní než xim.) Proto je třeba definovat proměnné GTK_IM_MODULE a QT_IM_MODULE.

Zatímco GTK (GTK_IM_MODULE=scim gtk-demo) je v tomto směru stabilní, Qt s přechodem na verzi 4 věci překopalo. Qt3 fungovalo přes protokol scimu a nefungovalo s ximem, Qt4 funguje jenom s xim. Protože Qt4 obsahuje emulaci Qt3, je asi na pořadu dne používat XMODIFIERS=@im=SCIM QT_IM_MODULE=xim qtconfig (QT_IM_MODULE je možné odstranit).

Nakonec je třeba vysvětlit, že řetězec SCIM identifikuje program implementující vstupní metodu, proměnná XMODIFIERS se používá i na jiné věci než na vstupní metody, proto ten @im=.

Když říkám, že proměnné identifikují implementaci, tak to znamená že jich může běžet (ve smyslu procesu operačního systému) více na jednou a že je dobé mít nějakou puštěnou už od začátku desktopové relace (aby nebyl uživatel zdržován jejich spouštěním). Například scim se pouští jako démon scim -d.

Ještě je třeba upozornit, že scim má (měl?) svéráznou konfiguraci, která vyžaduje, aby locale aplikace měl vyjmenovanou ve volbě /SupportedUnicodeLocales v konfiguračním souboru /etc/scim/global (například /SupportedUnicodeLocales = en_US.UTF-8,cs_CZ.UTF-8) a aby samotný démon scim byl spouštěn v locale podporujícím všechny zamýšlené znaky (tedy stačí jakýkoliv s UTF-8).

Pro úplnost uvedu, že existují různé vstupní metody, některé jsou zazděné patenty, pro náruživé texniky existuje pro scim modul s texovými makry pro matematické symboly, takže mohou v libovolném textovém editoru například napsat \exists\alpha\in\Re a dostanou ∃α∈ℜ.

[Jan Zahornadsky]

Tak toto musím pochválit, tento příspěvek je informační hodnotou na samotný článěk! Díky.

[Yenya]

Souhlasim s timto komentarem, akorat jeste doplnim, ze v dnesni dobe zacit pouzivat scim neni dobre - aspon podle reakci vyvojaru na moje bugreporty (padajici scim-bridge za nejakych ne uplne deterministickych okolnosti). Reakce byla: pouzijte ibus. Coz jsem taky udelal.

Zprovozneni ve Fedore 12 a GNOME je jednoduche - proste se naklikne ibus v "<tlapka> -> System -> Preferences -> Input Method". Pro japonstinu je treba mit nainstalovane baliky ibus-anthy, anthy, a samozrejme nejake fonty.

それじゃね、

-Yenya

[Nicky726]

V KDE ibus taky fachá?

[Jan Zahornadsky]

Jo (jak Qt3, tak 4) a dokonce se mi zdá, že lépe než SCIM (i když taky má pár nepříjemných chyb).

[vencas]

Doufám že budoucí díly článku ibus zmíní, vedle ostatních. Není na první pohled jasné, které z input methods jsou zastaralé a které perspektivní. Používám (občas) scim+m17n, ibus zatím nepoužívám.

[Yenya]

Jen pro referenci: chyba scim-bridge a odpoved vyvojaru Fedory je tady (zrovna dneska to uzavreli s WONTFIX):

bug #466876

-Yenya, http://www.fi.muni.cz/~kas/blog/

[pc2005]

Hezký článek, rád bych věděl, zda jde pomocí vstupních metod udělat akci, kdy stisk jedné nebo více kláves vyvolá vypsání řetězce. Takže třeba pro "alt_r+p" by mě to mohlo vypsat přímo "printf(". Výhody jsou celkem zřejmé . Zatím se mě částečně povedla realizace pomocí Xtrap rozšíření X serveru, ale to prý končí .

[Jan Zahornadsky]

Zkus vim

Jinak mi ale přijde, že hlavním účelem vstupních metod je případ opačný -- stiskem několika kláves zadat znak jediný.

[pc2005]

Jo o vimu vím, ale myslel jsem kdyby to v X fungovalo univerzálně, třeba v Geany. Ty sice mají nějaké doplňování textu, ale tohle by bylo o řád rychlejší .

[Andrej Herceg]

V geany sa dá to doplňovanie dosiahnuť napr. pomocou pluginu embrace. Časť konfigurácie by (u mňa) vyzerala asi takto:

[c]
type=advanced
filetype=C
items=printf

printf=button;printf;;thorn
printf_template=printf(

(problém je, že v menu sa bude zobrazovať len p a nie <alt_r>p, ale inak to funguje)

[Andrej Herceg]

A zabudol som, že thorn je znak, ktorý sa u mňa vygeneruje keď stlačím <alt_r>p. Príliš na tom znaku nezáleží, dá sa to potom zmeniť v nastaveniach geany.

[pc2005]

No funguje to, ale že by to bylo zrovna hezký řešení to se říct nedá :-/.

Kupříkladu já mám pravý alt jako modeswitch a s jeho zmáčknutím mě třeba "p" vypisuje "p" (stejně jako bez zmáčnutí). Takže pak se nahrazuje i samotný "p" v textu :-/. Na Ctrl+Alt+něco je zase hodně systémových zkratek, stejně jako na Alt+něco a Ctrl+něco. Winkeys na klávesnici nemám .

V geany je pak vtipné i to, že samotnou Mode Switch to detekuje, takže mohu pouhým pravým altem vypisovat ty printfy, ale ModeSwitch+něco se už přeloží.

Můj nápad by byl, aby to šlo sestavovat na nějaké nižší vrstvě systému, nejlépe překladové scankódů. A to tak, že by šlo jednak sekvencí scankódů vygenerovat jeden symbol a nebo jedním scankódem vygenerovat řetězec symbolů. A nejlépe ještě závislost na fokuzované aplikaci .

[Laco]

Jedna z prvych veci co vzdy vyhadzujem bol SCIM, teraz je to iBus

[----]

velice pěkně napsaný článek.