Desktopová prostředí versus Tablet PC (1)

27. 12. 2012 | David Kolibáč | Recenze | Návody | 6592×

V posledních letech zažívají boom tablety, ovšem především jako jednoúčelová zařízení určená pro konzumaci obsahu. Vedle nich však existují grafické tablety (polohovací zařízení) a konvertibilní tablety (subnotebooky s otočným dotykovým displejem obvykle reagujícím na dotyk pera). Pojďme se podívat, jak se dají použít v kombinaci s linuxovým desktopem (prostředími a aplikacemi primárně určenými pro desktop).

Obsah

• Tablet PC
• Desktopová prostředí a aplikace
  • Aplikace
  • Ovládání

Tablet PC

Tento článek nebude o tabletech tak, jak je v podstatě definoval Apple svým iPadem. Dnešním tabletům předcházelo několik typů zařízení tak trošku paradoxně prosazovaných mj. Microsoftem. Byly to handheldy/PDA, UMPC a v neposlední řadě také Tablet PC. PDA byla postupně vytlačena „chytrými“ telefony, za přímého nástupce UMPC můžeme v podstatě považovat současné tablety a konečně Tablet PC? Sice se nikdy nedostala do mainstreamu, ale své místo na trhu si jistě našla. Co to vlastně takové Tablet PC je? V podstatě bežný laptop (nebo specifičtěji subnotebook), ovšem má dotykový displej, který je zpravidla otočný tak, že klávesnice se pod ním může schovat.

K čemu se takové zařízení hodí? Kromě běžného použití jako laptop se na něm díky dotykovému displeji dají pohodlně ručně zapisovat poznámky, črtat diagramy a vůbec kreslit. Také čtení na výšku se schovanou klavesnicí může být pohodlnější.

Co se týče podpory hardwaru pod GNU/Linuxem, je to kus od kusu. Obvykle potřebujeme vedle běžné funcionality laptopu také funkční

• digitizér,
• případná tlačítka na peru,
• tlačítka kolem displeje,
• rotování obrazu (přičemž pro každou orientaci obrazovky je třeba odlišná kalibrace digitizéru).

Jak jsem naznačil, situace se liší model od modelu — např. FS Lifebook P1510 vyžadoval notnou dávku práce, naopak thinkpady jsou poměrně dobře dokumentovány, třeba můj X200T fungoval v podstatě „out of the box“. Konkrétními postupy se zde zabývat nebudu.

Velmi podobného, byť ne tak elegantního, výsledku lze dosáhnout s běžným počítačem a grafickým tabletem jako polohovacím zařízením; na GNU/Linuxu jsou vcelku bezkonkurenční volbou tablety značky Wacom.

Nebudu se zde zabývat záležitostmi jako multitouch, jiné typy dotykových displejů apod. — řadu informací ovšem jde aplikovat i tam.

Desktopová prostředí a aplikace

Aby bylo uživatelské rozhraní možné ovládat pouze pomocí dotykového displeje (a příp. několika málo tlačítek navíc), potřebujeme

1. větší ovládací prvky (příp. s většími rozestupy);
2. minimalizovat pohyb po obrazovce (není pohodlné létat rukou z jedné strany obrazovky na druhou);
3. veškerou potřebnou funkcionalitu dostupnou skrze pohyby kurzoru a „kliknutí“.

První dva body (a samozřejmě i bod třetí) by měla řešit především uživatelská rozhraní určená právě pro zařízení s dotykovým displejem. Právě proto vznikají projekty jako Plasma Active, Marble Mobile nebo Krita Sketch. V následujícím textu se však omezíme na tradiční desktopová prostředí a aplikace pro ně určené, a to především z toho důvodu, že na konvertibilním tabletu člověk se obvykle k výhradně dotykovému ovládání uchyluje jen část doby používání.

Aplikace

Tablet PC se nabízí, jak bylo zmíněno výše, k několika věcem, a sice

• prohlížení dokumentů, čtení textů;
• práci s grafikou;
• psaní poznámek, dělání náčrtků apod.

Pokud jde o poznámky, na MS Windows je populární především OneNote, součást některých verzí balíku MS Office, a v základní výbavě verze systému Microsoftu pro Tablet PC je jednodušší Windows Journal. Svobodné alternativy pro GNU/Linux jsem rozebíral ve starším článku — za zmínku stojí hlavně Xournal, Jarnal a vlastně také Okular pro anotaci typicky PDF.

Co se prohlížení dokumentů týče, chceme v prvé řadě pohyb obsahem pomocí nástroje „ruka“ (uchop a táhni). V případě prohlížečů obrázků nebo PDF a podobných formátů to není až takový problém. Narazil jsem pouze u Evince, v němž je posouvání přiřazeno třetímu tlačítku polohovacího zařízení, které je s dotykovým displejem dostupné hůře nebo vůbec, a nejde to jednoduše změnit — musíme se tedy spokojit s výběrem textu, použitím obezliček nebo rovnou přechodem na jinou aplikaci, např. zmíněný Okular. Ve webových prohlížečích je ale situace složitější:

• Ve Firefoxu se musíme poohlédnout po rozšířeních jako Grab and Drag.
• Pro Chromium se hodí také rozšíření, a sice např. chromeTouch.
• V Opeře nebo Midori stačí aktivovat příslušnou volbu v nastavení aplikace.

Na tomto místě by také měla rozhodně padnout zmínka o aplikaci pro čtení knih FBReader, umožňuje nastavení ovládání vhodné pro dotykové displeje.

Ovládání

V běžném GUI určeném pro desktop se využívá toho, co nám poskytují klávesnice (obvykle s aspoň ~80 klávesami, z toho několika modifikátory) a polohovací zařízení se třemi tlačítky a kolečkem, typicky myš nebo méně často trackpad, trackpoint, trackball atd. Takové možnosti s tabletem obvykle nemáme, v krajním případě disponujeme pouze možností přesouvat kurzor a alternativou k primárnímu tlačítku myši. Potřebujeme tedy vyřešit nedostupnost

• dalších tlačítek polohovacího zařízení — např. pro vyvolání kontextové nabídky;
• kolečka pro posouvání v dokumentech;
• klávesnice pro zadávání textu (a příp. klávesové zkratky).

Samozřejmě, někdy máme k dispozici pero s více tlačítky nebo třeba kompaktní klávesnici, ale pokud toto zanedbáme, nabízejí se následující možnosti:

• emulace dalších tlačítek polohovacího zařízení např. „podržením kliknutí“
• gesta (specifické pohyby kurzoru pro vyvolání definovaných akcí)
• rozpoznávání rukopisu
• virtuální klávesnice

O emulaci aspoň sekundárního tlačítka užitečného pro přístup ke kontextové nabídce se nám mohou postarat části desktopového prostředí, které odpovídají za přístupnost hendikepovaným. (Bohužel, mezi nástroji KDE jsem tuto funkci nenašel.)

GNOME 2, MATE

Předvolby myši – Zpřístupnění – Spustit podružné kliknutí

GNOME 3, Cinnamon

Univerzální přístup – Ukazování a klikání – Simulované druhé kliknutí

Totéž umí mimochodem i virtuální klávesnice Onboard, na kterou se podíváme příště společně s dalšími podobnými aplikacemi — včetně např. CellWriteru, který poslouží i k rozpoznávání ručně psaného písma.

       

Komentáře

[Ondra]

skoda zes nenapsal vic, jak pouzivani tabletu funguje v tom novym GNOME 3, to by mohlo byt docela zajmavy

[ʚĭɞ 🍉]

Bude druhá část o virtuálních klávesnicích a zadávání textu vůbec.

O GNOME 3 toho moc napsat nemůžu, protože ho nepoužívám, ačkoliv jsem to chtěl aspoň zkusit — jenže třeba Wireshark se mi tam sekal tak, že byl zcela nepoužitelný, přitom v MATE a KDE Plasma Workspace v pohodě.

[Honz]

jednoúčelová zařízení určená pro konzumaci obsahu.
Co třeba takový papírový pytlík na svačinu? Je to taky jednoúčelové zařízení určené pro konzumaci obsahu...?
Já se z těch odporných termitů poperu...

[brk]

A splňuje papírový pytlík na svačinu definici zařízení?

[Conscript89]

A jeste navic neni urceny ke konzumaci, ale ke skladovani :)

[ʚĭɞ 🍉]

Ale tak třeba si Honz dá ke svačině dva tři pytlíky... Člověku se celulóza blbě tráví, ale volovi? ^_^

[Václav "Darm" Novák]

Hmm, absence funkce „podržením klikni“ v KDE mě docela překvapila, vzhledem k faktu že celé prostředí je jinak hodně tablet friendly.

[ʚĭɞ 🍉]

Možná to půjde řešit přes gesta, s těmi jsem si hrál jen krátce, ale přímo explicitně tam ta funkce není.

[Michnzee]

Díky za článek :) je to už delší dobu, co jsem ukořistil TabletPC od HP - TC1100 který je plnohodnotným (sice už poměrně starým) zástupcem právě této třídy. Nedám na něj dodnes dopustit - pravdou je to - že svým výkonem dnešní stroje jen těžko dohání, ale na prezentace a rychlou práci plně dostačuje. Provozuji na něm dualboot, co se týče ubuntu starší verze - 10.04 která šlape perfektně, vyšší verze s novým gnome už byla o něco problematičtější kvůli vyšším nárokům na technické prostředky. Na druhou stranu, tento Tablet PC byl odladěn přímo na WinXP tablet edition, kde šlape naprosto bezproblémově a hlavně není problém s přetáčením monitoru a dalšími featurkami, které HPčko má :) Každopádně možná by stálo za to provést upgrade a vyzkoušet novou verzi gnome a zkusit jak to celé pofrčí

[Stanislav Brabec]

Před pár lety jsem se pokoušel vylepšit libgtkstylus, aby byl rozumně napsaný, a uměl simulovat pravé kliknutí, a s modifikátorem i prostřední tlačítko.

Nikdy jsem to ale nedopsal tak, aby to chodilo se všemi aplikacemi. Úkol byl zdánlivě jednoduchý, ale při realizaci se ukázalo, že to zdaleka jednoduché není:

• Dlouhým stiskem emulovat pravé tlačítko, aniž by se rozbila interpretace levého tlačítka. Kdy poslat událost levého tlačítka? Lze událost levého tlačítka anulovat, aniž by se něco stalo, když se má vygenerovat událost pro pravé tlačítko? Lze poslat událost opožděně?
• Odchytit neplatné Enter/Leave události v případě, že není nikde stisknuto. Ovladače většinou ponechají polohu ukazatele tam, kde se naposledy dotklo obrazovky. Je však nesmyslné poslat Enter událost prvku, který vznikl právě v takovém místě (což například rozsvítí link v prohlížeči).

Nepodařilo se mi vymyslet, jak to implementovat, aby to nezmátlo žádnou desktopovou aplikaci.

[ʚĭɞ 🍉]

Událost se AFAIK zpravidla posílá při uvolnění tlačítka, nevzpomínám si, že bych to kdy viděl jinak.

[Stanislav Brabec]

Je pravda, že většina aplikací odchytává jen uvolnění tlačítka, ale zdaleka ne všechny. Některé aplikace zmate, pokud tyto událost nejdou do páru – tedy pokud pošlu jen GTK_BUTTON_RELEASE. A například cokoliv, co používá motion hints, událost stisknutí vyžaduje. A mimochodem, motion hints jsou v GTK+ špatně implementované.

[ʚĭɞ 🍉]

Nějaký příklad takové aplikace? Vyjma grafického editoru a možná nějakých her mě fakt nic nenapadá.

[Stanislav Brabec]

Motion hints používají téměř všechny prohlížeče map a většina prohlížečů obrázků, ale také textové editory na kopírování do schránky. Pokud se BUTTON_PRESS neposlal, nefungovaly.

Téměř každý GTK+ widget reaguje na BUTTON_PRESS (a dokonce in na ENTER/LEAVE) sám o sobě. Pokud je nedostane, dějí se uvnitř GTK+ podivné věci (bylo uvolněno tlačítko, které nikdy nebylo stisknuto, a mělo by se zrušit vykreslování tlačítka jako stisknutého). Navíc uživatel je zmaten, a myslí si, že aplikace nereaguje, když tlačítko po stisknutí nezmodrá.

Naopak, pokud se BUTTON1_PRESS pošle hned, nefungují aplikace, které na levé a pravé tlačítko implementují různou činnost.

Některé aplikace třeba nefungují správně, pokud se neposílají ENTER události Aplikace může zpracovávat BUTTON_PRESS globálně, a za pomocí ENTER/LEAVE eventů trasovat, kde se zrovna pohybuje myš. Takže události ENTER/LEAVE nejde jednoduše zahazovat.

[ʚĭɞ 🍉]

Drag'n'drop jsem si neuvědomil.

Onboard se chová tak, že primární klik je normální, ale když se drží ve stisknutém stavu dostatečně dlouho (a kurzor se nehýbe), kurzor (a všechno ostatní) se vrátí do původního, tj. nestisknutého stavu a vyvolá se pravý klik. Ještě jsem s tím nenarazil na problém,

[Stanislav Brabec]

To s tím asi museli více kouzlit, aby to ještě před tím nevygenerovalo levé kliknutí.

[Josef Kufner]

A co při detekci dlouhého kliku udělat leave, release a pak pravý klik? Schválně si klikni na tlačítko, uteč s myší a pak ho pusť – tlačítko na obrazovce se vymáčkne a událost se nespustí.

[Stanislav Brabec]

To pomůže aplikacím typu tlačítko. Aplikace typu „jedna akce na levé tlačítko, jiná akce na pravé tlačítko“ to nevyřeší. Ty už akci spustily v okamžiku, kdy přijaly kliknutí.

Jediným plně funkčním řešením je asi pozdržet událost levého kliknutí až do okamžiku, než bude jisté, že to není pravé kliknutí. Ale to vypadá ošklivě.

Dalším řešením je samozřejmě zásah hlouběji uvnitř GTK+, a řešit to případ od případu.

[Josef Kufner]

No, když jsem se teď podíval do menu androidího telefonu, tak tam to na zmáčknutí položku podbarví a při posunu prstu podbarvení zmizí a začne se posouvat. To celkem odpovídá tomu, že stisk levého tlačítka jde okamžitě a při pohybu se teprve řeší, co dál. Takže je otázkou, zda to zmáčknutí levého myšítka navíc vadí. Napadá mne jediný případ, kdy to bude vadit: kreslení štětcem v Gimpu, ale s tím lze v pohodě žít (je tam jiná cesta na vyvolání menu).

[Stanislav Brabec]

Jistě, jenže Android je již od začátku psaný pro dotykové obrazovky.

V GTK+ lze na změnu chování bez zásahu do libgtk použít pouze modul. A zde jsou možnosti omezené. Programátor modulu neví, zdali bude událost použita na podbarvení tlačítka, jako filtr pro budoucí události, jako součást série, nebo jestli se na ní něco stane. Ví jen to, že si aplikace nebo widget tento typ události objednaly. A je mnoho aplikací, které opravdu již na událost levého kliknutí něco dělají, když ne navenek, tak uvnitř.

Ba, co hůř, tou vnitřní událostí, kterou aplikace na kliknutí provede, může být grab. Pokud nepošlete událost puštění tlačítka (která provede již něco zcela viditelného), zůstane fokus zamčený v daném widgetu. Tedy situace, která je bez (bezpečnostně děravého) KillGrabu v X řešitelná pouze shozením X serveru nebo přepnutím do virtuálního terminálu, a shozením aplikace odtud. (Když jsem to ladil, stalo se mi to mnohokrát.)