Linux na handheldech iPAQ (3)

Software

Na iPAQu lze provozovat tři typy aplikací. Aplikace konzolové, aplikace pro X window system a aplikace pro prostředí Qtopia. Prvně jmenované lze logicky spouštět pod oběma grafickými prostředími.

Jak jsem již zmínil v předchozím dílu, Qtopia prostředí mě funkčně nezaujalo (v konferenci dokonce padl i extrémní názor, že „to rovnou můžu zůstat u Windows CE“) a dávám přednost standardnímu X window systemu. Z toho vyplývá i fakt, že aplikací pro Qtopia prostředí se dotknu jen okrajově. Snad tento nedostatek někdo časem napraví článkem o handheldech Sharp Zaurus, které používají právě jen toto prostředí (protože však byl právě ohlášen port Qtopia prostředí pro X window system, je možné, že se k němu a jeho aplikacím později sám vrátím v zatím neplánovaném pokračování seriálu).

Aplikace obecně

Pokud tento odstavec začnu konstatováním, že se v zásadě jedná o standardní linuxový systém, je tím řečeno mnohé. Chcete editor vi nebo číst poštu muttem? Není problém. Jste vývojář a chcete mít v handheldu Apache, PHP a SQL? I to je možné. Háček je jediný – omezené prostředky systému, především však „diskový“ prostor. Zvláště pokud nemáte nějaké externí médium (např. CF kartu) pro ukládání programů a dat, bude vám interní flashka velmi brzy těsná. Jistě, můžete použít i ramdisk, ale nesmíte zapomenout, že se tím ochuzujete o paměť RAM pro běžící aplikace. A odswapovat není kam. Pokud tedy nejste šťastnými majiteli microdrive či PCMCIA harddisku (ale to už zase nejspíš nebudete potřebovat ten ramdisk). Nepříjemné rozhodování, kterou aplikaci (a knihovny, na nichž závisí) si ještě nainstalujete a kterou už ne, je, na rozdíl od desktopu, běžnou záležitostí.

Právě z důvodů omezeného diskového prostoru vyplynul jistý standard v preferovaných součástech systému. Konkrétně se jedná například o použití knihoven glibc-2.2, glib-1.2, gtk+-1.2, v oblasti interpretovaných jazyků pak o jazyk Python s rozšířením pygtk. Naopak třeba s libstdc++ či jazykem Perl se příliš nepočítá, nic vám však nebrání si obé nainstalovat a používat. Nové aplikace jsou většinou vyvíjeny tak, aby používaly preferované součásti (většina aplikací je díky tomu v C a nebo Pythonu). Osobně si myslím, že výběr preferovaných knihoven je asi nejlepší, jaký mohl být. Python je taktéž skvělý, já si však, bohužel, zatím víc rozumím s Perlem.

Jak je asi naprosté většině z vás jasné, použitý mikroprocesor není kompatibilní s mikroprocesory řady x86. Z toho vyplývá nutnost používání programů přímo zkompilovaných pro ARM platformu (nemluvím teď o programech v interpretovaných jazycích). Kde je vzít? Možnosti jsou tři.

První je instalace balíčku ve formátu .ipk. Spousta oblíbených aplikací dnes již má vlastní balíček a zde je instalace triviální. Pokud se vám příslušný balíček nepodaří najít, nastupuje možnost další. Tou je použití .deb balíčku z distribuce Debian/ARM. Je sice možná i jeho přímá instalace, ta ale není doporučována (.deb balíčky si s sebou nesou na iPAQa příliš mnoho balastu) a dává se přednost manuálnímu rozbalení a použití pouze potřebných souborů, což se může spojit s konverzí na .ipk balíček. Možností poslední je pak kompilace ze zdrojových kódů.

Možnosti portace a vývoje aplikací

Ty, kdož již přišli do styku s portací či vývojem software pro jiné platformy, jistě nepřekvapím konstatovaním, že je toto možné provádět dvěma různými způsoby. Buď v nativním protředí, a nebo pomocí crosscompileru (teď budu mluvit především o jazycích C a C++).

Instalace crosscompileru na váš x86 desktop není složitou záležitostí. Horší však už je to s vlastním překladem. S konzolovými aplikacemi většinou nebývá větší problém, kompilace projektů pro X window prostředí nebo dokonce GTK+ však již není tak přímočará (je problém dát dohromady všechny .h soubory a knihovny a především na ně správně nasměrovat gcc) a je daleko lepší využít výhod nativního překladu.

Kompilaci v nativním prostředí je možné provádět více způsoby. První a nejpoužívanější možností je použití jednoho z tzv. skiffclusterů. Jsou to počítače postavené na obdobném hardware jako iPAQ, které právě pro tento účel provozuje vývojové středisko společnosti Compaq, a které jsou komukoliv na internetu přístupné prostřednictvím služeb telnet a ftp.

Druhou možností je vytvoření vývojářského stroje přímo z vašeho iPAQu. I zde existuje více cest (dvě). Cestou finančně náročnější je pořízení nějakého externího velkokapacitního média a následná instalace distribuce Debian/ARM (resp. Intimate), cestou druhou je nahrazení tohoto média síťovým spojením například s vaším desktopem. Nejjednodušší je v tomto případě použití ethernetu po USB (stačí USB kolébka či kabel a příslušný usbnet.o modul na vašem desktopu). Cenová výhodnost USB řešení je vyvážena nižší rychlostí (USB má teoretickou maximální rychlost 12Mbit a vy přes něj budete tahat téměř všechno, v případě potřeby i swap).

Poslední možností nativní kompilace je pořízení nějakého jiného stroje (desktopu) na platformě ARM. Není to jednoduché ani levné. Celé stroje jménem NetWinder dodávala snad jen dnes již neexistující společnost rebel.com (informace zde), nyní štafetu částečně převzala společnost NetWinder. Dá se ovšem také pořídit ARM motherboard ve formátu micro-ATX a na jeho základě postavit vlastní stroj.

Pro doplnění, kernel se kompiluje výhradně crosscompilerem.

Pokud odběhnu od klasických „binárek“ k interpretovaným jazykům, je zde situace daleko jednodušší. Aplikace logicky běží tak, jak jsou. Interpretery jazyků Python, Perl, Ruby, vše je k dispozici. Do zvláštní kategorie pak patří Java, kde je z dispozici několik možností, nejoblíbenější je však pravděpodobně Blackdown Java-Linux.

Nyní nadešel čas vrátit se částečně k tématu předchozího dílu a povědět si o několika klíčových programech, které úzce souvisejí s operačním systémem.

Window managery

Stejně jako u vašeho linuxového desktopu máte i na iPAQu možnost zvolit si window manager podle vašeho gusta. Ne každý je však vhodný pro handheld zařízení (ať již z hlediska absence myši a klávesnice, nebo omezených prostředků systému, především pak z důvodu velikosti/malosti displeje).

Prvním používaným window managerem byl Blackbox. I přes jeho přednosti však už tehdy někteří uživatelé (včetně mě) dávali přednost IceWM. Jedním z hlavních důvodů definitivního opuštění Blackboxu jako implicitního window manageru byla závislost na objemné knihovně libstdc++. Nahrazen byl pro iPAQa speciálně upravenou verzí window manageru Ion.

Ion je velmi specifický typ window manageru. V originále se ovládá především klávesovými zkratkami, doplnění ovládání myší (resp. stylusem – perem u iPAQu) je hlavní změnou iPAQové verze. Daleko zajímavější vlastností jsou však nepřekrývající se okna. Na začátku máte k dispozici vždy celou plochu obrazovky/displeje, kterou můžete vertikálně či horizontálně rozdělit na dvě menší a každou takto nově vzniklou plochu můžete dále dělit stejným způsobem. Každá z těchto ploch je vlastně okno pro jednu z vašich aplikací. Hranice se dají mezi „okny“ posouvat a každé „okno“ má možnost maximalizace. I já na toto řešení zpočátku hleděl s nedůvěrou (a opět se dočasně vrátil k IceWM), ale musím přiznat, že má, především na displejích s nízkým rozlišením, své kouzlo.

Ačkoli je v tomto okamžiku Ion stále implicitním window managerem, v dalších verzích Familiar Linuxu od něj štafetu pravděpodobně převezme Matchbox, který, přestože se nachází v ranném stádiu vývoje, si oblíbilo značné množství uživatelů (včetně mě). Je totiž vyvíjen přímo jedním z uživatelů iPAQu a díky tomu je mu šit přímo na míru. Jeho nejzajímavější vlastnost má opět co dělat s malým rozlišením displeje a s okny, ta jsou totiž všechna neustále maximalizovaná (výjimku tvoří dialogy a dokované aplikace – např. virtuální klávesnice). Jakkoliv to opět může znít divně, považuji toto řešení v současné době opravdu za nejlepší.

Výčet používaných window managerů bych zakončil zmínkou o flwm, souvisejícím s dostupností kompletního FLTK toolkitu, Ionu podobném ratpoisonu, či japonském sgwm (Sikigami PDA Environment), který řeší problém nízkého rozlišení displeje opět jiným způsobem – přidáním scrollbarů, pokud rozměry okna aplikace přesahují rozlišení displeje.

Musím také zmínit, že výběr window manageru je ovlivněn i jeho schopností vypořádat se korektně se změnou rozlišení (u iPAQu to prakticky znamená rotaci displeje) za jeho běhu i běhu aplikací. Právě existence iPAQu byla totiž jedním z důvodů doplnění rozšíření Xrandr (rotate and resize) do X window systemu.

Vstup dat

(myslím tím především text) je možný dvěma způsoby. Prostřednictvím virtuální on-screen klávesnice a nebo rozeznáváním tahů na displeji.

Jako virtuální klávesnice se donedávna používal program xvkbd, ten však přinášel příliš mnoho závislostí na dalších knihovnách (nezapomínejte, flashka není nafukovací), a proto byl nahrazen programem xkbd, který je psán přímo iPAQovi na míru. Jeho další výhodou je možnost jednoduché změny rozložení kláves prostřednictvím konfiguračního souboru. Součástí balíčku je například alternativní rozložení FITALY (klávesnice optimalizovaná na psaní jedním prstem, existuje i pro PalmOS).

Software pro rozeznávání tahů na displeji také prošel svým vývojem, který dospěl až k programu xstroke. Jeho vývoj byl odstartován také právě na iPAQ platformě. Naprostá většina tahů je totožná s tahy graffiti PalmOS zařízení. Psát je možné na libovolném místě displeje a prostřednictvím knihovny libXrender je efektně přímo zobrazována „stopa“ tahu. Doplnění vlastních tahů prostřednictvím konfiguračního souboru opět není problém. Pro úplnost, prostředí Qtopia používá rozeznávání přímo psaného písma, stejně jako Windows CE (což má sice výhodu, že se uživatel nemusí učit graffity, zato je to však neskutečně pomalé).

Čeština

Zde musím čtenáře zklamat. Čeština zatím není. Nemyslím, že by to měl být až takový problém (je to přeci jen standardní Linux), ale uživatelská základna v České republice je malá a mě samotného tento problém příliš netíží.

Aplikace pro framebuffer

Na závěr se musím přiznat, že jsem vám zatajil ještě jeden specifický typ konzolových aplikací. Jak jsem se již několikrát zmínil, grafický výstup iPAQu je řešen přes framebuffer device, takže je možné provozovat (a programovat) aplikace, používající přímo toto rozhraní. Není jich však mnoho, já sám vím pouze o dvou používaných.

První je fbvnc, speciální VNC viewer, používaný ve spojení s lokálně běžícím Xvnc serverem k virtuálnímu zvětšení rozlišení displeje. Xvnc server například může běžet s virtuální obrazovkou 1024×768 bodů a vy se prostřednictvím fbvnc můžete dívat buď na výřez (to není až tak zajímavé), nebo na zmenšeninu (daleko zajímavější a především opravdu použitelné, při poměru 1:2 s vhodnými fonty i čitelné), případně na kombinaci obého. fbvnc má navíc vlastní screen overlay (vypínatelný jedním z tlačítek) s klávesnicí a několika důležitými ovládacími prvky (scroll výřezu, hlasitost, rotace, poměr zmenšení, třítlačítková myš a podsvětlení).

Druhou takovou aplikací je speciální port emulátoru Atari800, který je mým dílem. Verze pro X window system totiž na iPAQu nesplňovala mé požadavky na výkon a použitelnost, tak jsem si napsal vlastní port.

Touto malou osobní reklamou :-) bych ukončil dnešní povídání, příště se podíváme na webové browsery, PIM aplikace a na další „normální“ software.