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

[Ondra]

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

[Fluttershy, yay!]

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 :)

[Fluttershy, yay!]

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.

[Fluttershy, yay!]

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.

[Fluttershy, yay!]

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

[Fluttershy, yay!]

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.

[Fluttershy, yay!]

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