Vlákno názorů k článku GNOME 2.16: V jednoduchosti je síla od Drom - "V seznamu změn Gnome terminálu nyní rovněž najdete...
-
Drom (neregistrovaný)"V seznamu změn Gnome terminálu nyní rovněž najdete i podporu plné transparentnosti, tedy nejen obrázek pozadí jako doposud."
Pruhlednost umi gnome-terminal uz od nepameti (moji nepameti), ta hlavni zmena je, ze pouziva "nativni" pruhlednost, pokud je dostupna (XGL a podobny ptakoviny). Vyznelo to tak, ze do ted pruhlednost neumel :) -
Darm (neregistrovaný)Jde o to "plné transparentnosti, tedy nejen obrázek pozadí". Nevím jak vám, ale mě vždy vykreslil pouze ten výřez pozadí plochy nad kterým se nachází. Plnou průhedností si představuji tak že zkrz něj bude vidět vše pod ním, tzn. i ikony a okna.
A chápu to dobře tak že nový gnome-terminal to bude umět i bez XGL? -
Yenya (neregistrovaný)V cem je problem? Vykopiroval jsem si z gnome-character-map par znaku, a zobrazily se dobre. Je pravda ze kdyz jsem zkopiroval z browseru Vase jmeno, tak se mi do gnome-terminalu zkopirovalo pozpatku. Ale to je mozna jen o tom ze gnome-terminal (nebo mechanismus selection obecne?) ma nejaky problem s pravolevym textem.
A teda, kdyz uz mate s gnome-terminalem nejaky problem: jake je presne id teto chyby? Prosel jsem zbezne otevrene chyby gnome-terminalu od GNOME 2.10 dal, a na nic podobneho jsem tam nenarazil. Report nothing, expect nothing. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)Som to skusal este davnejsie, ale nie v gnome-terminali, ale v gnome character map. Je to celkom sranda, jak to preskakuje zo strany na stranu, ked sa miesaju lavoprave s pravolavymi ;-) IMHO to jednoznacne riesenie nema, ked zacnem miesat napr. latinku s hebrejskymi znakmi, tak ako by to malo byt spravne?
-
Řešení je, že pokud příznak směru napsaného znaku a aktuálního směru řádku souhlasí, znak se přidává na správný konec řádku správným směrem. Pokud směry nesouhlasí (arabština v textu v latince, latinka v hebrejském textu,...), pak před sebou "tlačí" znaky napsané obráceným směrem a znak se přidává jakoby doprostřed řádku. Takové řešení umožňuje psát v jakémkoliv jazyce věty od začátku do konce, a to dokonce i pří střídání jazyků.
V XTermu kombinované znaky fungují, ale příznak směru zde také nefunguje.
V Gecku naopak funguje správně směr písma, ale zato má problémy s kombinovanými znaky. -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)OK, to znie rozumne a pouzitelne. Ale je tam (minimalne) este jeden hacik backspace vs. delete.
gucharmap aj gedit (2.12 a tusim som testoval este 2.14) sa spravaju tak, ze zmazu pri zmacknuti backspace znak v nahodnom smere, priklad:
abcdef<kurzor>האצק
FF mi tiez nejak prehadzuje poradie medzier (doslova mi preskakuju). Otazka: ked sa stlaci backspace na mieste kurzora, ktory znak by to malo zmazat? Napr. v gucharmape/gedite ked mi funguje backspace "dolava", tak nefunguje "delete" do prava. Ak funguje backspace "doprava", tak funguje delete "dolava".
Samozrejme mozme definovat, ze backspace maze dolava a delete doprava, ale neviem ako to pouzivaju useri pravolavych pisem (arabic/hebrew).
Toto ani neviem ci patri do bugreportu, pretoze ja osobne by som userov s takymito dotazmi posielal niekam, kde nebudu mixovat na rovnakom riadku lavoprave s pravolavymi ;-) -
Backspace by měl mazat vždy zpět, Delete dopředu (myšleno v logickém směru textu). Z toho samozřejmě vyplývá, že při odmazávání na přechodu LTR a RTL kurzor najednou poskočí, protože logicky předcházející znak se fyzicky nachází jinde.
Jinak to ani není možné. Když píšete hebrejsky a spletete se, Backspace by měl smazat právě napsaný znak. Jistá nekonzistence vzniká pouze mezi funkcí Backspace/Delete a mezi šipkami. Při pohybu šipkami by poskakování kurzoru a pohyb v protisměru nedával význam. Z toho vyplývají drobné odlišnosti – u LTR textu platí Backspace ≡ ← + Delete, u RTL textu Backspace ≡ → + Delete
V mezinárodně použitelném terminálu musí LTR/RTL přepínání chodit – jak jinak přeložit např. „/usr/bin/foo: No such file or directory“?
Stejně tak kombinované znaky jsou nutností – na rozdíl od češtiny, která dostala tu výsadu, že všechny kombinované znaky v ní používané jsou zároveň samostatným UNICODE znakem, jiné jazyky takové štěstí neměly (třeba proto, že používaných kombinací je příliš mnoho) – pak se vám snadno stane चतना (čátná) z चेतना (čétná). -
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)S tymi kombinaciami v poslednom odstavci to chapem spravne, ze sa kombinuje LTR s RTL? Alebo ide o to, ze niektore znaky sa skladaju napr. z dvoch unicode "polznakov"?
Ale ak spravne chapem, nasledovne je bug: napisem zopar RTL znakov, nalavo od nich (cize vlastne na konci riadka) napisem par LTR znakov, napr. abcdefﭯ. Ked dam kurzor medzi "abc" a "def", a vlozim RTL znak, tak vysledok vidim ako defەabcﭯ v gucharmap, ale po pastnuti do FF je vysledok ﭯabcەdef.
No mam z toho riadny zmatok. Nasiel som si "How to create bi-directional documents", hadam z toho budem mudrejsi. -
Kombinované znaky se skládají z několika znaků. V gucharmap je poznáte podle přikresleného kolečka, které definuje, jak se spojuje s hlavním znakem. I české znaky lze psát pomocí kombinovaných znaků: např. č (kombinovaný znak), č (jeden znak UNICODE).
Zde asi bude problém v tom, jak je definován implicitní směr textu na daném řádku. gucharmap ho definuje podle prvního znaku na řádce, takže vložením RTL znaku mezi latinské znaky řetězec rozseknete a abc se objeví jako první, tedy zprava. FF si zřejmě implicitní směr textu odvodil jako LTR, a tak sekal sekvence zleva doprava. Natolik HTML neznám, abych věděl, jak se tam tento údaj definuje.
