Tvorba moderních multiplatformních rozhraní v jazyce Python

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Tvorba moderních multiplatformních rozhraní v jazyce Python Diplomová práce Vedoucí práce: Ing. David Procházka, Ph.D. Bc. Pavel Kostelník Brno 2013

2 Děkuji panu Davidu Procházkovi za jeho cenné rady z oblasti praktické implementace i za zkušenosti poskytnuté při vytváření závěrečné práce.

3 Prohlašuji, že jsem celou diplomovou práci vytvořil samostatně dle pokynů vedoucího práce za použití zdrojů, které jsou uvedeny v souhrnu literatury. V Brně dne 1. května

4 4 Abstract Kostelnik, P. Designing modern multiplatform user interfaces in Python programming language. Master thesis. Brno, This thesis presents a complex palette of frameworks that are available for development of user-friendy interface in Python programming language. Thesis provides detailed description of libraries that are written in Python and their comparison with other frameworks based on different programming languages. Kivy framework is described in detail, since it is used for experimental application development. This application demonstrates the possibilities of multiplatform development tools that can be used for processing 3D graphics. Key words User interface, multiplatform development, Python, Kivy, 3D Model, REST protocol Abstrakt Kostelník, P. Tvorba moderních multiplatformních rozhraní v jazyce Python. Diplomová práce. Brno Záměrem této práce je zpracovat komplexní přehled možností implementace přívětivého uživatelského rozhraní v jazyce Python. Obsahuje obecnou rešerši a popis jednotlivých knihoven, které jsou pro daný jazyk dostupné, včetně porovnání těchto prostředků s možnostmi dostupnými v jiných programovacích jazycích. Práce se detailněji zabývá knihovnou Kivy, ve které je také implementována experimentální aplikace. Ta demonstruje možnosti multiplatformního vývoje při tvorbě aplikace pro práci s 3D modely. Kĺıčová slova Uživatelské rozhraní, multiplatformní vývoj, Python, Kivy, 3D model, REST protokol

5 OBSAH 5 Obsah 1 Úvod 7 2 Cíl práce 8 3 Analýza knihoven pro tvorbu uživatelského rozhraní Qt framework Wxwidgets GTK Cocoa Java Swing Android SDK Kivy Zhodnocení knihoven Metodika Požadavky na experimentální aplikaci Volba GUI knihovny Volba architektury Vývoj UI Praktický postup práce Implementace aplikace Implementační specifika Kivy Propojení PJJ Python s C/C Vlastní práce klient Design UI Implementace Vlastní práce Server Použité knihovny a technologie Implementace Hodnocení Omezení současného řešení Možnosti využití aplikace Ekonomické hodnocení Závěr Literatura 60 Přílohy 62

6 OBSAH 6 A Obsah CD 63 B Screenshoty aplikace 66

7 1 ÚVOD 7 1 Úvod Tvorba přívětivých uživatelských rozhraní je alfou i omegou vývoje moderních aplikací. Velmi často je úspěch aplikace závislý na prezentační vrstvě aplikační architektury. Zcela klíčová je schopnost odpovídajícím způsobem uživateli zpřístupnit jednotlivé funkce. V dnešní době přechodu na ovládání dotykem je na kvalitní uživatelské rozhraní kladen zvláštní důraz. Obecným trendem aplikací, knihoven a operačních systémů je snaha o sjednocení uživatelského rozhraní napříč platformami tak, aby byl přechod pro uživatele mezi jednotlivými zařízeními naprosto plynulý a neznatelný. Mezi aplikace se složitějším návrhem rozhraní patří také ty, které pracují s 3D modely. Většinou se jedná o takové programy, které by měly uživateli umožňovat více funkcí při zachování snadné orientace. Tyto aplikace jsou sice většinou využívány profesionály, ale i ti (jako všichni uživatelé) preferují jednoduchý, přehledný a správně fungující program. Programátorská praxe často naráží na omezenost jednotlivých knihoven pro tvorbu uživatelského rozhraní. Ve větší skupině jsou tyto frameworky vázány striktně na konkrétní platformu. Python jako platformně nezávislý jazyk je typickým průkopníkem znovupoužitelnosti kódu a umožňuje ve většině případů spuštění nezměněného kódu na všech operačních systémech (Kuchling, A. M., 2012). Tato práce je zaměřena právě na praktické zhodnocení jednotlivých knihoven, které jsou pro tvorbu uživatelských rozhraní v jazyce Python dostupné. Pro lepší návaznost je provedeno také srovnání s moderními prostředky tvorby grafického uživatelského rozhraní v jiných programovacích jazycích.

8 2 CíL PRÁCE 8 2 Cíl práce Cílem práce je zhodnotit jednotlivé knihovny pro tvorbu multiplatformních uživatelských rozhraní a ověřit získané poznatky implementací experimentální aplikace ve vhodném frameworku. Východiskem pro řešení je zhodnocení jednotlivých knihoven a možnosti jejich použití vzhledem k požadované funkčnosti experimentální aplikace. Hlavní kritéria hodnocení jsou použitelnost při multiplatformním vývoji a tvorba odpovídajícího moderního uživatelského rozhraní. Prakticky budou možnosti zvolené knihovny ověřeny prostřednictvím implementace konkrétního frameworku pro aplikaci pracující s rozšířenou realitou. V rámci tvorby této aplikace je snahou uplatnit moderní přístupy pro návrh uživatelsky přívětivého rozhraní. Omezujícími faktory pro dosažení cílů práce jsou zejména softwarová omezení daná použitím konkrétních knihoven.

9 3 ANALÝZA KNIHOVEN PRO TVORBU UŽIVATELSKÉHO ROZHRANí 9 3 Analýza knihoven pro tvorbu uživatelského rozhraní Knihoven pro tvorbu grafického uživatelského rozhraní existuje nepřeberné množství. Některé frameworky jsou striktně zaměřeny pouze na GUI, jiné se orientují na podporu širší funkcionality a umožňují např. práci s XML, správu sít ových spojení, atd. Součástí následující rešerše jsou pouze knihovny pro tvorbu grafického uživatelského rozhraní, které jsou v praxi obecněji rozšířené. 3.1 Qt framework Knihovna Qt představuje mamutí framework, který je vyvinut v jazyce C ++. Za vývoj Qt dlouhá léta zodpovídala firma Nokia, což frameworku umožnilo velký rozkvět. Tato knihovna patří ve své aktuální verzi 4.8 ke špičce ve vývoji grafických rozhraní, zejména pro desktopové aplikace. Funkcionalita Knihovna Qt je ve své verzi 4.8 rozdělena do několika základních modulů podle funkcí, které jednotlivé součásti poskytují. Následuje stručný přehled důležitých částí tohoto frameworku (Blanchette, Summerfield, 2008): QtCore, QtGui modul pro základní práci s uživatelským rozhraním. Umožňuje vytvářet aplikace a GUI. QtNetwork modul pro práci se sítí v Qt, obsahuje mimo jiné vlastní Webkit prohlížeč pro práci s HTML. QtOpenGL modul, který umožňuje vykreslování pomocí OpenGL. QtSql modul pro práci s relačními databázemi a tvorbu SQL dotazů v Qt. Celkově lze říci, že se dá vytvořit funkční aplikace téměř jakéhokoliv druhu pouze za použití funkcí dostupných díky Qt bez nutnosti připojovat k projektu jakýkoliv jiný framework. Qt je all-in-one balíček, díky němuž lze kromě tvorby GUI pracovat např. s XML stromem nebo manipulovat s obrázky. To umožňuje nejen zrychlení vývoje aplikací, ale také jednodušší správu závislostí. Qt z hlediska moderních způsobů ovládání podporuje gesta prostřednictvím třídy QGesture a jejích potomků. Správa gest je plně v roli programátora, který může např. nadefinovat svá, zcela nová gesta nebo velmi jednoduše využít standardních gest, která odpovídají notoricky známým gestům z jiných knihoven a zařízení. Výchozí gesta rozpoznávaná v Qt jsou na obrázku níže.

10 3.1 Qt framework 10 Obrázek 1: Qt výchozí gesta Pan, Pinch, Swipe (Digia, Plc) Qt je v současné době schopné tvořit platformě nezávislý C ++ kód pro všechny tři hlavní operační systémy (Windows, OS X, Linux). Důležitým milníkem ve vývoji tohoto frameworku by mělo být oficiální vydání Qt 5.0. Qt se chce do budoucna zaměřit především na stále rostoucí mobilní segment a podporovat ios a Android. V nadcházejícím SDK pro tvorbu aplikací pro Blackberry OS je Qt obsažen jako plnohodnotná alternativa k nativnímu frameworku (Struhár, 2012). Programátorská přívětivost Knihovna obsahuje rozsáhlé SDK, jehož součástí jsou programy, které vývoj v tomto frameworku značně zjednodušují. Nejdůležitější součástí je IDE QtCreator, které představuje vývojové prostředí s podporou doplňování kódu, designování UI a velkou měrou tak ulehčuje vytváření Qt aplikací v C ++. Součástí SDK je také QtDesigner, který je rovněž velice vděčnou pomůckou při vytváření aplikací v tomto frameworku. Je o něco univerzálnější než výše zmíněný creator. S jeho pomocí je možno na jednoduchém drag n drop principu navrhnout GUI za použití dostupných QtWidgetů. Výsledný návrh je uložen do XML souboru, který je naprosto univerzální. Dokumentace frameworku Qt je dostupná na domovských stránkách ( Je velice vyčerpávající a názorná. Součástí jsou i krátké ukázky použití jednotlivých tříd a funkcí v kódu. Nejedná se pouze o jednoduchou API, ale obsahuje také tématicky zaměřené články a nahrazuje tak jakousi Qt učebnici. Výhodou je také business logika aplikací v Qt. Framework má filozofii volání složitější funkcionality jako samostatných programových vláken (instance QThread); tím zpřehledňuje kód a zrychluje jeho vykonávání. Qt je již několik let vydáváno pod GPL licencí. Ta umožňuje každému daný framework používat (i pro komerční účely) zcela zdarma. PyQt Firma Riverbank Computing, Ltd. vytvořila Python binding 1 na knihovnu Qt za pomocí vlastního nástroje SIP. K dispozici je napojení jak na Qt v.4, tak i Qt v.3. 1 Binding je napojení kódu jednoho programovacího jazyka na jazyk jiný. Typicky se používá binding kompilovaných jazyků na skriptovací.

11 3.2 Wxwidgets 11 Třídy a jejich funkce jsou analogické (existují pouze drobné rozdíly), proto je možné při psaní využít nejen prostou API dokumentaci PyQt, ale i podrobnější popis funkcí v manuálu Qt. PyQt v sobě kombinuje výpočetní sílu C ++, která umožňuje efektivní vykreslování UI a jednoduchost Python syntaxe. Díky nasazení tohoto moderního skriptovacího jazyka se také značně rozšiřuje množství knihoven, které je v aplikaci možno použít. Při používání PyQt je výhodné využít pro design GUI QtDesigner. Součástí PyQt je skript pyuic4.py, který umožňuje konverzi XML generovaného designerem. XML je parsováno na klasickou Python třídu (typicky QMainWindow) a design je převeden na instance jednotlivých Python tříd, které napojují widgety z Qt. 3.2 Wxwidgets Knihovna WxWidgets je stejně jako předchozí projekt napsána v jazyce C ++. Jedná se o rozsáhlý projekt, který podobně jako Qt zprostředkovává rozsáhlou funkcionalitu v rámci jedné knihovny. Součástí tohoto frameworku jsou třídy pro práci se sít ovým spojením, správa databází, tvorba SQL atd. WxWidgets vznikla o něco později než Qt (r. 1992) a snaží se být lepším a efektivnějším GUI frameworkem než Qt. Jejím hlavním cílem je kompatibilita a přizpůsobení vzhledu aplikace nativnímu rozhraní operačního systému. Podobně jako Qt podporuje v současné době všechny tři hlavní operační systémy. Na rozdíl od Qt se ve své implementaci i vnitřně snaží inklinovat k danému operačnímu systému a používat jeho vnitřní volání namísto užití vlastní univerzální implementace (Petty, 2009). Funkcionalita WxWidgets je velice rozsáhlý a komplexní framework. Jeho základní snahou je, aby vytvářené GUI co nejvěrněji reprezentovalo systémové aplikace a bylo danému systému plně přizpůsobené. Důležitou výhodou tohoto frameworku je jeho kontinuální podpora tvůrci garantují lifetime support pro všechny platformy (tj. včetně starších verzí Windows). V tomto frameworku je dokonce možné kompilovat aplikace pro jiný operační systém než je systém, na kterém kompilace probíhá (např. kompilace aplikací pro MS Windows na Linuxu). Jednou ze základních tezí knihovny je její multiplatformnost. WxWidgets framework kód by měl být komponovatelný na všech třech velkých platformách a není závislý na žádné ze systémových knihoven (Petty, 2009). WxWidgets také nabízí kromě běžných widgetů pro tvorbu GUI nadstandardní paletu, kde se nacházejí méně používané grafické prvky. Patří mezi ně např.: wxtreectrl widget, který umožňuje vytvářet stromovou strukturu labelů. wxnotebook umožňuje vytvářet systém záložek v aplikaci (tabbed view).

12 3.3 GTK 12 wxtoolbar vytváří toolbar, který usnadňuje ovládání aplikace a zapadá do grafického stylu systému. wxglcanvas widget, na nějž je možno jednoduše kreslit prostřednictvím OpenGL příkazů. Tato knihovna zahrnuje také možnosti přímého tisku pro všechny platformy. Na rozdíl od knihovny Qt také umožňuje deployment vícejazyčných aplikací. Tedy zahrnuje v sobě podporu pro snadný překlad uživatelského rozhraní aplikace do jiného jazyka (Smart, Hock a Csmor, 2005). Programátorská přívětivost WxWidgets obsahují online rozsáhlou dokumentaci, která podobně jako u předchozí knihovny neobsahuje jen API, ale i konkrétní příklady a další instruktáž, která má programátorům usnadnit práci. Framework je zaměřen především na desktop aplikace a nemá žádné ambice proniknout na mobilní OS. Proto je jeho podpora týkající se ovládání GUI moderními metodami poměrně omezená. WxWidgets nabízí v tomto směru pouze drag n drop. Např. úplně chybí jakákoliv podpora gest, která je v Qt obsažena. WxWidgets jako takové nemají své vlastní IDE, ale je možné je vyvíjet v libovolném prostředí. Existuje také designer GUI wxglade (dostupný na Ten generuje přímo kód daného požadovaného jazyka (podporovány jsou Python a C ++ ). Výhodou tohoto frameworku jsou také jeho licenční podmínky. WxWidgets jsou k dispozici pod LGPL licencí, a to i pro komerční použití. WxPython Podobně jako Qt i WxWidgets má svůj Python port. Dostupný je na Lze jej jednoduše použít ve spolupráci s wxglade, a rychle tak vyvíjet GUI v Pythonu. Zřejmou výhodou tohoto spojení je jednoduchost vývoje a možnost použití jakéhokoliv modulu z velmi rozsáhlé knihovny Pythonu. 3.3 GTK Na rozdíl od obou předchozích knihoven je GTK knihovna vytvořená v jazyce C 2. Jedná se o projekt ze všech hodnocených knihoven nejstarší, který byl původně vyvinut pro potřeby Unixových systémů a dal vzniknout uživatelskému rozhraní gnome, které na tomto toolkitu dodnes stojí. 2 Existuje také C ++ port gtkmm

13 3.3 GTK 13 Funkcionalita GTK obsahuje všechny základní widgety pro stavbu plnohodnotného GUI. Hlavní výhodou GTK je fakt, že stojí na knihovně glib. Jedná se o nízkoúrovňovou knihovnu, která je součástí GTK a měla by při použití tohoto GUI pro aplikace v jazyce C zpřístupnit celou řadu funkcí, které jsou často v kódu zbytečně zdvojovány. Jedná se např. o následující funkcionalitu (GTK+ Team, 2012): Přirozený vzhled aplikací aplikace v GTK by měly vypadat jako nativní aplikace daného systému. Toho není dosaženo použitím nativních widgetů (jako např. wxwidgets), ale obdobně jako u Qt použitím motivů (themes). V praxi ovšem často tato funkce nefunguje úplně dokonale (např. aplikace na OS X mají tendence vypadat stejně jako na Linuxu a do nativní podoby mají daleko). Podpora jednoduché synchronizace vláken GTK podporuje prostřednictvím svých volání synchronizaci vláken, která je velmi často kamenem úrazu při psaní aplikací. Neumožňuje však složité synchronizační vzory, spíše jednoduchou správu vláken. Lokalizace V této oblasti GTK vyniká nad ostatní frameworky. Nejen, že umožňuje jednoduchou lokalizaci aplikace do libovolného jazyka a podporuje ve výchozím stavu UTF8, ale umožňuje také např. zobrazovat text v jiných směrech (např. zprava doleva nebo zdola nahoru). GLib také zahrnuje podporu pro zrakově postižené, kterou je možno v aplikaci použít. Framework podporuje kromě Unixových systémů, pro které byl původně určen, také MS Windows. Nutno však říci, že podpora dalších operačních systémů je spíše dodatečná a není na ni kladen takový důraz. Kompilace GTK na jiných systémech je často problémová, stejně jako deployment (např. na OS X není možné GTK aplikace spustit jinak než přes X11.app, protože neexistuje nativní port tohoto frameworku na Mac). Okrajově lze také použít tuto knihovnu na některých mobilních zařízeních (některá zařízení Nokia, OpenMoko). Spolu s GTK v.3 přibyly do frameworku některé nové grafické prvky (např. switch widget), které bylo nutno dodat spolu s postupujícím vývojem gnome. Moderní prvky ovládání se do toolkitu dostávájí zejména díky práci třetích stran (firma Canonical prostřednictvím projektu Canonical multitouch Programátorská přívětivost GTK obsahuje relativně stručnou API dokumentaci, která obsahuje pouze popis celé knihovny a všech funkcí, které GTK zpřístupňuje. Jakékoliv další zdroje či návody nejsou součástí dokumentace na GTK zůstává nejvíce tam, odkud přišlo (na Linuxu, v zobrazovacím prostředí gnome). Nemá ambice příliš pronikat na další platformy, ačkoliv je podporuje.

14 3.4 Cocoa 14 Tato knihovna byla jednou z prvních, která podporovala design GUI v XML. Z GTK toolkitu vzešel designer Glade, jehož obdoby jsou používány v dalších grafických knihovnách. Glade XML soubory jsou parsovány na kód příslušného jazyka za chodu. PyGTK GTK je v programovacím jazyce Python dostupné díky bindingu PyGTK ( Pro PyGTK platí obdobná fakta jako pro celý GTK framework. Je multiplatformní, ale jeho hlavním cílem je uspět na Linuxu a v gnome. PyGTK existuje v současnosti ve své finální verzi 2.24 a vývojáři projektu přešli k nové knihovně PyGObject ( která zprostředkovává Python binding na GTK v.3 a gnome platform. Dokumentace tohoto projektu i jeho stav je však stále v rané fázi. Tento projekt rovněž blíže tíhne přímo ke gnome (pro které je primárně určen), proto má na něj také závislosti. 3.4 Cocoa Cocoa je API firmy Apple pro vytváření aplikací na operační systém OS X. Velice úzce souvisí s knihovnou Cocoa Touch, která přináší podporu gest a je součástí SDK pro ios. Apple tradičně používá z historických důvodů programovací jazyk Objective C, ve kterém je i Cocoa napsáno. V současné době zažívá tato knihovna růst zejména díky zájmu o zařízení s ios. Funkcionalita Cocoa je složeno z několika základních částí, které sdružují funkcionalitu a poskytují dobrý základ pro tvorbu aplikací bez nutnosti připojovat cizí knihovny. Součásti knihovny (tzv. Core framework) tvoří: Foundation framework tento framework je historickým dědictvím z doby, kdy Apple používal OS NextStep. Jedná se o knihovnu sdružující základní funkce, které ani nespadají konkrétně do tvorby UI. Obsahuje např. třídy pro manipulaci s řetězci, podporu vláken nebo kolekce. Application framework součást knihovny Cocoa, která slouží k vytváření uživatelských rozhraní a k interakci s nimi. Pro lepší pochopení architektury Cocoa a jejího rámce v OS X slouží obrázek níže. Důležitou myšlenkou Cocoa je také model-view-controller přístup, který Apple ve svém frameworku dodržuje. Tento moderní přístup zpřehledňuje kód a umožňuje jeho rychlý vývoj a modularitu.

15 3.4 Cocoa 15 Obrázek 2: Architektura OS X (Apple, Inc) Programátorská přívětivost Apple poskytuje svým vývojářům nadprůměrný servis. Pravidelně vydává nové verze vývojového prostředí XCode, které je primárním vývojovým prostředím pro OS X a ios. XCode obsahuje také interface builder, který umožňuje jednoduchou a intuitivní tvorbu GUI. XCode po instalaci dodatečného ios SDK obsahuje také iphone simulátor a umožňuje pohodlnou tvorbu a testování aplikací pro zařízení s tímto mobilním operačním systémem. Na stránkách jsou programátorům k dispozici veškeré podklady, včetně API dokumentace všech systémových knihoven, které Apple používá. Tato firma vždy byla známá svým inovativním přístupem, a proto je také logické, že její grafický framework obsahuje rozsáhlou podporu gest a alternativních způsobů ovládání. Cocoa Touch nabízí kvalitně zpracovanou knihovnu pro rozpoznávání různých gest a definování gest vlastních. Stejně tak je možné do budoucna počítat s možností hlasového ovládání (první velice omezené API se objevilo v ios 5.1 SDK). Cocoa framework není striktně určen pouze pro vývoj v Objective C. Prostřednictvím bindingů Applu i třetích stran lze používat Cocoa v programovacích jazycích Python, Ruby a AppleScript (Apple, 2012). PyObjC PyObjC představuje most mezi jazyky Python a Objective C. Jedná se o možnost využívat Cocoa toolkit a jeho funkce pro vývoj vlastních aplikací v Pythonu. Tento

16 3.5 Java Swing 16 Python modul umožňuje spustit libovolný Objective C kód jako čistý Python. Výhodou tohoto propojení je jeho dvoucestnost: Cocoa je plně dostupné z Pythonu, stejně jako Python z Objective C. Pro vývoj Cocoa aplikací v Pythonu ale není příliš mnoho důvodů. Takové aplikace totiž poběží jen na OS X, kde je již nainstalovaný framework Cocoa. Vlastně se jedná jenom o možnost pracovat v jiném jazyce, než Objective C. Kód není možno použít multiplatformně, proto není tento binding příliš používaný, ani aktualizovaný (poslední verze z roku 2009). 3.5 Java Swing Java Swing je jedním z dvojice standardních knihoven grafického uživatelského rozhraní, které jsou součástí Javy. Základní vlastností swingu je možnost konfigurovat vzhled widgetu podle požadavků programátora (mohou se snažit emulovat chování systémových GUI widgetů nebo ve výchozím stavu se snaží vypadat na všech platformách naprosto totožně). Velkou výhodou tohoto frameworku je jako u každého programu v Javě jeho portabilita. Takový program poběží naprosto korektně všude, kde běží Java (Swing je součástí Javy SE od v.1.2). Funkcionalita Swing v sobě obsahuje veškeré základní widgety. Ty obsluhuje velice široká paleta událostí, které jsou v této knihovně velice dobře typizovány. Na rozdíl od frameworků, které jsou napsány v C/C ++ má swing poněkud jiný mechanizmus připojování signálů na jednotlivé události rozhraní. Jedná se o princip implementace tzv. listenerů, což jsou objekty, které poslouchají v GUI danou událost. Tento přístup je pro GUI toolkity napsané v Javě charakteristický. Podpora pro vývoj swing UI je poměrně široká. Je možno jej programovat v libovolném IDE. Netbeans a Eclipse umožňují tvorbu swing UI prostřednictvím designeru. Z návrhu je následně vygenerován konkrétní Java kód (ten má často bohužel do přehlednosti daleko). Java swing je poměrně starý nástroj pro tvorbu grafických uživatelských rozhraní. Jako takový nepodporuje příliš mnoho moderních prvků ovládání, protože ty nebyly v době jeho tvorby ani navrženy, ani nebyly hardwarově proveditelné. Oracle ale dále provádí rozšíření a některá z nich umožňují, aby swing podporoval dotykové aplikace a počítají dokonce s podporou multitouch (Riecken, 2008). Problémem takových řešení ale zůstává nutnost zpětné kompatibility swingu a rigidní design widgetů, které nejsou na ovládání dotykem přizpůsobené. Programátorská přívětivost Swing API je součástí JavaDoc příslušné verze Javy. Swing je nejběžnějším nástrojem používaným pro tvorbu GUI v Javě. Proto je k dispozici velké množství online

17 3.6 Android SDK 17 návodů a tutoriálů. Základní tutoriál, převzatý od Sunu, je k dispozici na stránkách Oracle na Swing jako takový je poměrně starý framework a nepodporuje extrahovaní tvorby GUI mimo programový kód. Neexistuje možnost vytvářet layout např. v XML (bez použití nástavbových knihoven). To má za následek často poměrně špatnou přehlednost v třídách GUI, kde se mísí funkce controlleru a pohledu (view) aplikace. Jython Jython je implementace Python interpretu pod Java virtual machine. Výhodou Jythonu je nejen zrychlení výkonu oproti klasickému Pythonu, ale hlavně možnost využít libovolnou třídu z Javy ve svém Python programu. Právě prostředí swing je možné jednoduchým způsobem použít jako GUI pro vývoj svých Python aplikací, které následně můžeme spouštět na Jythonu. Jython poskytuje téměř všechny standardní knihovny programovacího jazyka Python (v jeho implementaci se ale jedná o klasické třídy Javy). Jython samozřejmě neumí využít ty moduly Pythonu, které jsou napsány v C. Klasické pure-python moduly je možné použít i v tomto interpretu (Juneau, Baker, Ng, Soto a Wierzbicki, 2010). Jednoduchou ukázku výstavby swing UI v Pythonu díky Jython interpretu poskytuje Jython swing tutorial zde: Android SDK OS Android zahrnuje vlastní unikátní GUI, které bylo od počátku vyvíjeno jako toolkit pro tvorbu uživatelského rozhraní ovládaného dotykem. Google se snažil držet všech moderních trendů a návrhových vzorů při tvorbě widgetů a celkové user-experience svého grafického rozhraní. Dnes je Android nejrozšířenějším mobilním operačním systémem s více než 1.3 milióny nově aktivovaných zařízení denně. Funkcionalita Android zahrnuje širokou paletu widgetů grafického uživatelského rozhraní, které jsou navrženy moderně s cílem jednoduchého ovládání prstem. Android se snaží umožnit uživatelům ovládat GUI takovým způsobem, který simuluje interakci s předměty reálného světa (posunování papíru při čtení, odemykání přístroje). GUI v Androidu také podporuje celou řadu efektů uživatelského rozhraní, které práci na zařízení nejen zjednodušují a zpřehledňují, ale také zpříjemňují. Jsou založeny na OpenGL ES specifikaci. Relativně nedávnou novinkou je velká změna tvorby GUI prostřednictvím tzv. fragmentů. Fragmenty byly do Androidu přineseny s podporou větších displejů a snahou o kvalitnější aplikace pro tablety. Tento princip umožňuje aplikaci, aby měnila rozložení grafických prvků na základě velikosti obrazovky, kterou má k dispozici. Tento přístup je velice efektivní, protože umožňuje psát aplikace pro Android bez nutnosti rozlišovat tablet nebo mobilní telefon (Google, Inc., 2013).

18 3.6 Android SDK 18 Výhodou Androidu je jeho úzká provázanost s online službami Googlu, který také zajišt uje rychlý a kvalitní vývoj tohoto systému. Z hlediska tvorby moderních UI je Android na špičce vývoje. Podporuje systemwide gesta, v nejnovější verzi (4.2) ovládání hlasem offline, správu notifikací, kterou postupně přebírají všechny ostatní platformy, atd. Tento systém byl také prvním, který doopravdy zvládl zavést kvalitní a použitelné UI pro správu multitaskingu na mobilních zařízeních (Hackborn, 2010). Programátorská přívětivost Google poskytuje Android SDK spolu s Eclipse pluginem a tudíž je primárním vývojovým IDE pro Android Eclipse IDE. Součástí SDK jsou také simulátory Androidu a všechny vyvíjené aplikace je velice jednoduché takto vyzkoušet. SDK má také rozsáhlou dokumentaci, která je k dispozici na android.com. Obsahuje API reference, design patterns a hlavně podrobné tutoriály k jednotlivým tématům Androidu. Příslušný JavaDoc je samozřejmě také součástí Eclipse pluginu a popis jednotlivých funkcí se objevuje při doplňování kódu v Eclipse. První verze Androidu se objevila 2007 a obecně se jedná o projekt, který je díky svému open-source charakteru velice aktivně rozvíjen. Právě proto je Android typickým příkladem správně navrženého komplexního systému. Jeho SDK respektuje a používá návrhové vzory a snaží se o čistý a přehledný kód. Je velice těžké napsat aplikaci, která by byla špatně navržená, protože samo SDK vede k logickému a správnému členění kódu. Debugging projektů pro tuto platformu je naprosto přímočarý. Simulátor naprosto věrně kopíruje chování skutečného zařízení a Google vytvořil pro debugování aplikací speciální debug konzoli, která je součástí zmiňovaného Eclipse pluginu. Design UI aplikací pro Android je uložen v XML souborech, které systém sám parsuje na příslušný Java kód. Ten je vytvářen v designeru, ale je možné jej editovat i ručně. Android obsahuje komplexní systém generovaných ID, které jsou přiřazeny každému objektu a tímto způsobem je velice jednoduché přistoupit k jednotlivým objektům z GUI designu. SL4A Scripting Layer for Android je projekt, jehož cílem je portovat běžné skriptovací jazyky na OS Android a umožnit vývoj aplikací v těchto jazycích. V současné době je tento projekt v alfa verzi a poskytuje pouze naprosto nejzákladnější přístup k některým funkcím systému. Už vůbec se nedá mluvit o možnosti reálného tvoření aplikací pro Android ve skriptovacích jazycích za použití tohoto projektu. V současné době jsou portovány interprety jazyků Python, Perl, JRuby, Lua, BeanShell, JavaScript a Tcl. SL4A má v současné době spíše využití pro práci se systémem na pozadí (Ferrill, 2011). Vzhledem k velice rychlému vývoji systému je také velice nepravděpodobné, že budou v SL4A dostupné všechny funkce nativního Android SDK v Javě, a proto je smysl tohoto projektu poněkud diskutabilní.

19 3.7 Kivy Kivy Kivy je Python framework, jehož primárním cílem je absolutní multiplatformnost. První oficiální verze Kivy byla publikována v lednu roku Pro vykreslování GUI používá Open GL (popř. OpenGL ES). Aby byla eliminována pomalost Pythonu, je většina GUI napsána v Cythonu 3 a vykonává se na úrovni rychlosti strojového kódu v jazyce C. Funkcionalita Základní myšlenkou Kivy je možnost spustit aplikaci pod jakýmkoliv rozšířeným mobilním i desktopovým operačním systémem. Kivy aplikace jsou v současné době spustitelné na Windows, OS X, Linuxu, ios a Androidu. To z něj činí nesmírně mocný nástroj pro vývoj aplikací a jejich následný deployment. Kivy obsahuje velice široký výběr widgetů, které je možné v uživatelském rozhraní použít. Jedná se o dobře designované a přizpůsobitelné grafické prvky, které odpovídají návrhovým vzorům grafického rozhraní a snaží se o podobnost s widgety známých platforem (podoba s Androidem je více než zřejmá). Kivy mimo klasických GUI widgetů obsahuje méně tradiční prvky jako např.: restructuredtext renderer widget, který umožňuje renderovat text zapsaný v restructured formě vlastní Python dokumentaci Sphinx ( TabbedPanel tabbed view v Kivy frameworku. Umožňuje efektivně jednotlivé záložky definovat např. formou json notace. Accordion speciální grafický prvek, který představuje animovaný otevíratelný seznam. Svým vzhledem připomíná akordeon. Carousel widget vhodný zejména pro mobilní aplikace. Zjednodušuje navigaci přes skupinu jiných grafických prvků a představuje jejich sekvenční prezentaci. Kivy podporuje také deployment svých aplikací na jednotlivé platformy. Pro desktopové operační systémy je použit PyInstaller ( pro Android a ios vlastní deployment systém Kivy, který je popsán na domovských strankách projektu ( Principem tvorby takových aplikací je zabalení vlastní distribuce Pythonu, která obsahuje Kivy i další závislosti, přímo do balíčku s aplikací. 3 Cython je Python interpret, který umožňuje vytvářet moduly pro Python v jazyce C. Obsahuje rozšířenou syntaxi, která zahrnuje C-like výrazy, jejichž pomocí jsou volány funkce a datové typy jazyka C. Výsledkem je platformně závislý modul ve formě shared object nebo dll knihovny, který je možné v Pythonu používat stejně jako jakýkoliv jiný pure-python modul. Cython byl součástí návrhu jazyka Python. Právě možnost jednoduchého psaní modulů v C, které zrychlí kód Pythonu v jeho úzkých místech, dělá z tohoto jazyka tak oblíbený nástroj.

20 3.8 Zhodnocení knihoven 20 Kivy je zejména GUI framework a příliš se nesnaží přidávat další funkcionalitu, která je už dostupná v rámci jiných Python modulů. Umožňuje pouze vytvořit pouze základní server-klient architekturu díky frameworku twisted, který obsahuje. Mezi další rozšířenou funkcionalitu patří základy práce se sít ovými spojeními a modul pro přehrávání videa (ze souboru, popř. z webkamery). Programátorská přívětivost Nejlepším zdrojem materiálů je domovská stránka Kivy. Ta obsahuje, jak API dokumentaci ( tak i komplexní tutoriál ( Na stránkách se také nacházejí ukázkové profesionální aplikace, při jejichž tvorbě bylo Kivy využito. Protože je Kivy open-source projekt, je možné vždy nahlédnout do zdrojového kódu na Design uživatelského rozhraní je možný přímo v Python kódu nebo za použití Kivy language. Tento speciální textový designovací jazyk vznikl jakýmsi jednoduchým zkřížením Pythonu a XML. Nepříjemným faktem je absence jakéhokoliv GUI designeru i po dvou letech od prvního vydání stabilní verze. Kivy je snadné rozšířit (není problém derivovat svůj vlastní widget). Díky Kivy language se zjednodušuje oddělení prezentační vrstvy aplikace od její funkcionality. Framework je založen na ovládání dotykem, mimo jiné nativně podporuje multitouch. Kivy obsahuje širokou škálu událostí, která obsluhuje GUI a umožňuje tvorbu událostí vlastních. Princip připojování událostí k widgetům je poměrně atypický a vzdáleně připomíná javascript. Kivy pro přímočarý vývoj umožňuje nastavení základních proměnných (např. velikosti okna) celého frameworku v konfiguračním souboru. Knihovna také obsahuje kvalitní debugovací systém založený na různých úrovních důležitosti zpráv podle vzoru v Unixových systémech. 3.8 Zhodnocení knihoven Následuje slovní shrnutí hlavních kladů a záporů jednotlivých zkoumaných knihoven. Qt největší síla tohoto frameworku leží v jeho dlouhodobém používání a kvalitní podpoře ze strany firmy Nokia, která jej léta vyvíjela. Nástroje jako QtDesigner nebo QtCreator představují při vývoji neocenitelnou pomůcku. Drobnou nevýhodou, kterou by ale mohlo odstranit Qt 5, je absence širší podpory mobilních platforem. WxWidgets hlavním kladem WxWidgets je fakt, že jednotlivé prvky GUI neemulují jako mnohé jiné multiplatformní knihovny, ale používají nativní grafické prvky systému. Nevýhodou WxWidgets je především absence modernějších GUI prvků.

21 3.8 Zhodnocení knihoven 21 GTK GTK funguje správně a nejlépe na Linuxu. Na ostatních platformách není jeho použití zrovna přímočaré a je vidět, že multiplatformita není myšlenka, se kterou by byl toolkit tvořen. Dalším problémem může být možná až příliš strohá dokumentace. Cocoa tento framework představuje vrchol vývoje moderního UI. Podporuje gesta, ovládání hlasem, atd. Jednotlivé widgety jsou dobře designovány a knihovna Cocoa touch přinesla mnohé principy, které byly následně přijaty jako obecný standard návrhu GUI. Značnou nevýhodou je ale platformní závislost. Cocoa, respektive Cocoa touch jsou striktně vázány pro použití na zařízeních od firmy Apple. Java Swing Swing může na rozdíl od všech ostatních frameworků zaručit bezproblémový deployment a zcela identický vzhled na všech použitých platformách. Výhody využití Swingu plynou z podstaty Javy. Hlavním nedostatkem knihovny je potom její zastaralost (jednotlivé widgety jsou poněkud těžkopádné, zejména pro ovládání dotykem). Android SDK Android má moderně navržený UI, který v mnoha směrech přejímá principy z Cocoa touch. SDK zahrnuje kompletní sadu nástrojů, která obsahuje úplně vše, co vývojář potřebuje, včetně rozsáhlé dokumentace. Při vývoji aplikací je vývojář veden k přehlednému kódu a vytváření třívrstvé architektury. GUI Toolkit je ale striktně (z pochopitelných důvodů) svázán s operačním systémem, a proto není možné o žádné multiplatformitě hovořit. Kivy Kivy představuje velice zajímavou alternativu, která díky naprosté multiplatformnosti Pythonu a Open GL může slavit úspěchy na libovolné platformně. Obsahuje velkou množinu moderních widgetů a nástroje pro praktický deployment na libovolný operační systém. Hlavním nedostatkem Kivy je jeho omezenost pouze na GUI framework - stává se tak omezeným zejména na mobilních platformách. Druhým problémem může být složitá filozofie samotného designu UI, který by měl být zcela shodný napříč všemi platformami (neexistuje princip podobný fragmentům z Androidu). Pro závěrečné objektivní zhodnocení knihoven je potřeba stanovit hodnotící kritéria. S přihlédnutím k cíli práce byla zvolena následující kritéria: Multiplatformnost schopnost knihovny vytvářet funkční aplikace pro různé operační systémy bez nutnosti změn v kódu. Podpora Pythonu možnost použít daný framework v programovacím jayzku Python (at už nativně nebo jako binding). Moderní UI kvalita toolkitu pro tvorbu moderních uživatelských rozhraní (moderní widgety, podpora dotykového ovládání,... ). Dokumentace kritérium hodnotící dokumentaci projektu a dalšími

22 3.8 Zhodnocení knihoven 22 materiály, které jsou pro nové uživatele knihovny pomocí při studiu a pochopení jejího fungování. Nástroje a IDE tento ukazatel vyjadřuje, jakým způsobem je knihovna softwarově zajištěna. Tj. zda toolkit obsahuje designer, jaká je podpora frameworku v různých IDE, atd. Pro hodnocení byla použita stupnice 0 až 5. Protože výše zmíněná kritéria nemají vzhledem k cíli práce stejnou důležitost, byly pro ně stanoveny následující váhy: multiplatformnost 0,3 podpora Pythonu 0,25 moderní UI 0,2 dokumentace 0,1 nástroje a IDE 0,15 Následuje tabulka, která hodnotí jednotlivé GUI frameworky vzhledem k zmíněným kritériím. Qt WxWidgets Multiplatformnost Podpora Pythonu Moderní UI Dokumentace Nástroje a IDE Celkem (váženě) 4,30 3,70 3,15 3,00 3,80 2,50 4,45 GTK Cocoa Java Swing Android SDK Kivy Tabulka 1: Hodnocení knihoven

23 4 METODIKA 23 4 Metodika 4.1 Požadavky na experimentální aplikaci Jedním z cílů této práce je vytvořit aplikaci pro práci s 3D objekty. Ta by podle zadání práce měla splňovat následující požadavky. 1. Bude vytvořena v programovacím jazyce Python. 2. Bude splňovat požadavky na kvalitní moderní uživatelské rozhraní (podpora gest, drag and drop). 3. Aplikace bude uživatelsky příjemným způsobem umožňovat práci s 3D objekty ve formátu 3ds Aplikace bude multiplatformní. 5. Aplikace bude sloužit k jednoduché manipulaci s 3D objekty. Ty bude možno následně použít v software Aurel vyvinutém Mendlovou univerzitou v Brně. Aplikace bude umožňovat tvorbu množin modelů, jejich sdružování do projektů atd. Výstupem aplikace by měl být konfigurační soubor, který bude možno použít v software Aurel. 4.2 Volba GUI knihovny Ná základě všech požadavků a komplexního hodnocení knihoven v předchozí kapitole byl jako ideální framework pro experimentální aplikaci vybrán Kivy framework. Splňuje všechny požadavky na aplikaci a navíc se jedná o řešení, které není v žádném oficiálním českém zdroji popsáno. Tímto způsobem může tato práce sloužit také jako referenční zdroj pro programátory, kteří se budou v budoucnu tímto frameworkem zabývat. Kivy umožní tvorbu aplikace, která by bez jakékoliv změny v kódu měla být spustitelná na libovolném desktopovém či mobilním OS. Mezi další přednosti této knihovny patří přehledný objektový návrh nebo designovací Kivy language. Vykonávání kódu je také optimalizováno na úroveň strojového kódu generovaného překladačem jazyka C. Kivy je tedy správnou volbou i z hlediska požadavků na systémové prostředky. 4.3 Volba architektury Experimentální aplikace by měla dle požadavků uživatelsky přívětivým způsobem zpřístupňovat práci s 3D objekty. V principu se tedy vlastně jedná o dvě hlavní množiny funkcionality aplikace. Jednak je to samotné vykreslování 3D objektů, dále potom uživatelské rozhraní a funkce s ním spojené, které renderování využívají 4 3ds je formát objektů modelovaných v software 3D Studio Max

24 4.4 Vývoj UI 24 a poskytují uživateli tuto funkčnost srozumitelným způsobem. Z tohoto důvodu bylo v rámci návrhu rozhodnuto pro architekturu klient/server. Aplikace tedy bude založena na principu rozdělení na grafického klienta, který umožní jednoduchou uživatelskou interakci a render server, který bude zastávat funkci překreslování objektů. Výhodou této architektury je i možnost využít server univerzálněji. Vytvářený klient nemusí být jediným druhem klienta, který je schopen se k serveru připojit. Pokud bude komunikace navržena dostatečně průhledným způsobem, je velmi jednoduché vytvořit vlastní klienty, kteří mohou funkčnosti serveru využít v dalších aplikacích. 4.4 Vývoj UI Jedním z cílů práce je zaměření na moderní a přívětivé uživatelské rozhraní a proto je velice důležité se touto problematikou detailně zabývat. Při vývoji grafického rozhraní je vhodné přihlédnout k určitým návrhovým vzorům, které jsou v této oblasti respektované a používané. Patří mezi ně: princip safe exploration (možnost si na cokoliv svobodně kliknout, aniž by to vyvolalo pád aplikace), incremental construction (možnost vytvářet výsledek postupně, po částech, v jednotlivých krocích), habituation (aplikace funguje na obdobných principech, na které už jsou uživatelé zvyklí z jiných programů) (Tidwell, 2006). Aby mohly být naplněny všechny požadavky, byl pro vývoj UI zvolen iterativní přístup. Postupem času by tedy GUI mělo dosáhnout své finální vhodné podoby. Ta se bude odvíjet od jednotlivých kroků, které budou provedeny. Iterativní přístup má hned několik výhod, které představují důvody k jeho využití pro tvorbu GUI. 1. Okamžité projevení změn jakékoliv změny, které budou do modelu systému vytvářeného iterativně zaneseny, se promítnou hned po jejich provedení. 2. Evoluce model UI je vytvářen postupně. Dochází k vývoji tak, že každá novější verze by měla být přesnější a lepší než ta předchozí. 3. Zachování podstatných principů díky iterativnímu přístupu je nemožné, aby se z UI vytratily základní důležité prvky, které jsou elementárními stavebními kameny již na začátku vývoje. 4. Zjednodušování postupnou iterací dochází k odstraňování nepodstatných částí rozhraní, což vede k uživatelské přívětivosti a jednoduchosti.

25 4.5 Praktický postup práce Praktický postup práce Pro naplnění cílů práce je potřeba provést konkrétní kroky, které k nim povedou. Následuje jednoduchý výčet a popis těchto kroků: 1. podrobné seznámení s jazykem Python, 2. tvorba serverové části aplikace, 2.1. výběr správného komunikačního protokolu (popř. jeho návrh), 2.2. volba frameworku pro renderování 3D objektů formátu 3ds, 3. tvorba klientské části aplikace, 3.1. návrh GUI, 3.2. seznámení s knihovnou Kivy, 3.3. implementace komunikace se serverem.

26 5 IMPLEMENTACE APLIKACE 26 5 Implementace aplikace 5.1 Implementační specifika Kivy Architektura Kivy knihovny je na obrázku níže. Obrázek 3: Architektura Kivy, (Kivy.org) Pro lepší porozumění struktuře architektury frameworku jsou níže popsány jeho klíčové části (Kivy community, 2012). Core providers Kivy podobně jako většina grafických frameworků provádí abstrakci základních operací jako je otevření okna, zobrazení textu atd. Základem takového API pro volání typických funkcí je vnitřní výstavba Kivy tak, aby jednotlivé části byly platformně závislé. To znamená, že Core provider je komunikační most mezi nativním API příslušného operačního systému a API ve frameworku Kivy, které slouží k volání dané funkce (Kivy Community, 2012). Tím je dosaženo nejen rychlosti (používají se nativní funkce), ale zjednodušuje se i deployment. Podobný systém je zaveden i pro tzv. Input providers různá zařízení (klasická myš, Apple magic trackpad) mají stejné Kivy API pro práci s vstupními událostmi.

27 5.1 Implementační specifika Kivy 27 Graphics Kivy představuje také jednoduché API do OpenGL. OpenGL kód je poněkud složitý ke čtení, a proto Kivy vytvořil vlastní podmnožinu podporovaných příkazů a systém vlastních zkratek. Např. třídy kivy.graphics.rectangle nebo kivy.graphics.canvas. Pro vykreslování GUI Kivy používá OpenGL 2.0 ES specifikaci. Inputs díky Input providerům Kivy provádí abstrakci pro všechna vstupní zařízení. Všechny vstupy reprezentuje jedna třída Touch. Každá instance této třídy může vstoupit do jednoho ze tří klíčových stavů, o kterých jsou widgety v GUI informovány. Tyto stavy jsou: 1. Down dotek je stlačen dolů, pouze jednou, právě tehdy, kdy se poprvé objeví. 2. Move dotek může tento stav nabývat opakovaně po neomezeně dlouhou dobu. Tento stav nastane při změně 2D souřadnic doteku. 3. Up tento stav nastává pouze jednou u každého doteku. Nastává právě v momentu, kdy uživatel zvedne prst od widgetu, popř. pustí tlačítko myši atp. Kivy Core vrstva modulů nad výše zmíněnou základní trojicí se nazývá Core. Součástí jádra frameworku jsou následujcí moduly (Kivy Community, 2012): Práce s widgety Clock objekt může být použit k automatickému volání funkcí (pouze jednou nebo periodicky). Cache představuje cache frameworku Kivy. Gestures je dobrá podpora gest, která umožňuje pokročilou detekci tahů, např. kruhy. Je možné vytvářet jednoduše vlastní gesta. Kivy Laguage modul obsahuje jazyk Kivy. Zjednodušuje psaní grafického rozhraní a zpřehledňuje kód. Kivy Properties představuje jednu ze specialit Kivy. Tyto speciální atributy umožňují komunikaci mezi Kivy design language a klasickým Pythonem a mají v rámci frameworku další funkcionalitu (viz níže). Event loop modul se stará o vysílání událostí v celém frameworku, informuje o událostech příslušné objekty. Widgetů je v Kivy velké množství. Všechny tyto prvky jsou potomky třídy kivy.uix.widget. Základní metody a atributy, které widgety dědí z této třídy, jsou např.

28 5.1 Implementační specifika Kivy 28 add widget celé GUI aplikace v Kivy má stromovou strukturu, kdy jeden widget je kontejnerem jiných a kontejnerem všech je okno aplikace. Pomocí této funkce přidáme widget do jiného. Pomocí funkcí clear widgets a remove widget je možné všechny nebo konkrétní widget z jeho rodiče odstranit. collide point tato velice důležitá funkce je schopná detekovat, jestli daný Python list/tuple koliduje s widgetem. Tj. zda daná dvojice souřadnic zasahuje do widgetu. size hint layout v Kivy umožňuje změnu velikosti okna. Aktuální velikost widgetů se přepočítává dynamicky. Dynamicky se přepočítává právě podle tohoto atributu. Ten vyjadřuje, jakou velikost (v desetinném čísle) má widget zabrat v rodičovském widgetu. Tj. např. hodnota 0,3 znamená, že widget svou velikostí zabere maximálně 0,3 velikosti svého rodiče. Události a reakce na ně Jednotlivé widgety (protože jsou všechny potomky třídy Widget) přijímají informace o všech událostech, byt nejsou provedeny na nich. Tj. tlačítko může například reagovat na dotyk, který vznikl zcela mimo jeho pozici. Tento princip není v grafických knihovnách běžný, ale z praktického hlediska zapadá do principu moderního ovládání. Jednoduchým příkladem může být objekt, který je ovladatelný klasicky přes myš a tlačítko nebo alternativně dotekem. Při ovládání dotekem se volá akce připojená k tlačítku (které díky chytrému systému události v Kivy je o interakci informováno). Pokud by tomu tak nebylo, bylo by třeba psát duplicitní kód pro reakci na dotek a klik na tlačítko. Protože většinou chceme, aby se událost po prvním zpracování již dále nešířila, zpracováváme události následujícím kódem: if not self.collide_point(touch.x, touch.y): return False if self in touch.ud: return False #Za timto kodem bude nasledovat sekvence prikazu, ktera se skutecne #provede, pokud bude dana udalost vytvorena na widgetu, #ktery ji zpracovava. -- za nim na konci return True #zajisti, ze se udalost nebude dale sirit Připojování událostí je v Kivy umožněno trojím způsobem: 1. Kivy language připojení reakce na danou událost je otázkou nastavení dané property na odpovídající funkci. Tento způsob nejvíce odpovídá systému signál-slot známého např. z Qt.

29 5.1 Implementační specifika Kivy Metoda bind() klasické připojení odpovídající nejčastějšímu připojování reakce na události ve většině frameworků pro tvorbu grafického uživatelského rozhraní. Princip je obdobný jako v jazyce javascript. 3. Dědění widget třídy tento přístup je podobný Javě, která pro připojování většinou používá implementaci interfaců atp. Námi použitý widget bude dědit z již specializované widget třídy. Jedinou změnou oproti ní bude přepsání některé z metod on touch down, on touch move, případně on touch up. Kivy language Kivy obsahuje od počátku Kivy design language. Ten je jedním ze základních stavebních kamenů celého frameworku. Smyslem tohoto jazyka je separovat design UI od jeho funkcionality a přesně tak dodržet princip MVC. Kivy language je směsicí Python syntaxe s XML. Smysl nabývá zejména u složitějších aplikací, kde vede k přehlednějšímu kódu a umožňuje adaptabilnější vývoj UI. Následuje jednoduchá ukázka Kivy language: <RunSettingsWindow>: _save_settings: save_settings _arhell_settings_path: arhell_settings_path _arhell_exec_path: arhell_exec_path orientation: vertical BoxLayout: id: window_content orientation: vertical size_hint_y: 0.5 Label: size_hint_y: 0.1 text: Arhell config font_size: 14 id: arhell_config BoxLayout: size_hint_y: 0.2 BoxLayout: Label: text: "Arhell executable path" valign: middle halign: left text_size: self.width, self.width size_hint_x: 0.3 TextInput:

30 5.1 Implementační specifika Kivy id: arhell_exec_path size_hint_x: 0.7 multiline: False Tento kód představuje design UI pro třídu RunSettingsWindow. První řádky představují nastavení properties (viz níže). Dále se objevují grafické widgety balíčku kivy.uix, které jsou součástí kontejneru RunSettingsWindow. U těchto jednotlivých položek je dobré si všimnout atributů size hint u jednotlivých objektů. Jejich význam je vysvětlen výše. U každého z objektů GUI je možné nastavovat všechny jeho vlastnosti. Proto není nutné ve vlastním kódu Pythonu dané třídy zmiňovat objekty, které nemají žádnou konkrétní funkcionalitu (např. statické nápisy). Ty jsou vytvářeny jako anonymní objekty a o jejich tvorbu a začlenění do GUI se postará právě Kivy language. Velmi důležitou vlastností je id. Tento atribut, který se používá pouze v Kivy language (nikoliv v kódu) propojuje design GUI a ObjectProperty dané třídy. Takto můžeme svázat konkrétní objekty Kivy language s objekty v kódu a máme jistotu, že Kivy se postará o korektní propojení. Tento princip znázorňuje následující obrázek. Obrázek 4: Propojení Kivy language a Pythonu (Erens, 2012) Soubory Kivy language se ukládají do textových souborů s příponou.kv. Při startu aplikace Kivy automaticky hledá soubor se jménem aplikace a příponou.kv v aktuálním adresáři, ale je možné soubor s designem načíst také explicitně (Kivy community, 2012).

31 5.1 Implementační specifika Kivy 31 Je možné také používat šablony objektů, tedy tvořit kód Kivy language, který bude generován dynamicky za chodu. Stejně je možné využívat v Kivy language i s jinými widgety, než z balíku kivy.uix. Kivy properties Kivy properties představují jednu z typických a nejsilnějších stránek celého frameworku. Tyto vlastnosti se poněkud liší od klasických vlastností objektů v PJJ Python. Jsou mimo jiné specifické ve svém datovém typu. Kivy má pro jednotlivé properties vyčleněné následující třídy (Kivy community, 2012): 1. kivy.uix.properties.stringproperty vlastnost, jejíž hodnota je řetězcem. 2. kivy.uix.properties.numericproperty číselná vlastnost objektu (i desetinná čísla). 3. kivy.uix.properties.listproperty vlastnost, která je reprezentována instancí Python list objektu. Např. množina všech widgetů, které jsou v daném kontejneru obsaženy. 4. kivy.uix.properties.objectproperty ObjectProperty představuje odkaz na jednu konkrétní instanci objektu, která je libolným Python objektem. 5. kivy.uix.properties.booleanproperty vlastnost daného Kivy objektu, která je charakterizovatelná hodnotami True nebo False. 6. kivy.uix.properties.boundednumericproperty obdoba třídy NumericProperty. Na rozdíl od ní má však nastavitelné minimum a maximum. 7. kivy.uix.properties.optionproperty obdoba StringProperty. Kivy hlídá, že daný řetězec je z nějaké povolené množiny. Pokud tomu tak není, vyvolá se chyba. 8. kivy.uix.properties.aliasproperty o gettery a settery vlastností se stará samo Kivy. Pokud chceme toto výchozí chování přepsat, použijeme pro danou proměnnou tento druh property, které dodáme také vlastní getter a setter jako arugment. 9. kivy.uix.properties.dictproperty vlastnost reprezentující Python dictionary. Properties a jejich hodnoty jsou obsluhovány vnitřními mechanizmy v Kivy (např. dynamické změny property size při změně velikosti okna). Tyto vlastnosti také definují pojivo mezi Python kódem a Kivy language. Všechny vlastnosti definované

32 5.2 Propojení PJJ Python s C/C++ 32 v Pythonu pomocí instancí výše zmíněných tříd, jsou následně dostupné v Kivy language. Kivy properties jsou tak mocným nástrojem zejména proto, že umožňují reakci na jejich změnu dynamicky za chodu programu. Následující ukázkový kód dynamicky zavolá funkci text eval při každé změně textu v textovém poli tfield. self.bind(tfield.text, self.text_eval) Funkci text eval jsou automaticky předávány tyto parametry: objekt self (binding object), hodnota dané property. Právě možnost dynamické reakce na hodnoty vlastností činí z Kivy velice mocný grafický framework. Podobnou funkcionalitu zpřístupňují i jiné knihovny, ale není možné vytvářet si vlastní property nebo snad dokonce vlastní objekty se svými property. Tato myšlenka velice úzce souvisí právě s propojením na Kivy language a jednoduchou a přehlednou tvorbou GUI aplikace. 5.2 Propojení PJJ Python s C/C++ Protože v implementaci bude nutné vykreslovat 3D objekty, je zapotřebí využít prostředků, které tuto funkcionalitu umožní. Standardním frameworkem pro vykreslování 3D objektů je OpenGL. Pro jeho použití v Pythonu je vytvořena knihovna PyOpenGL ( Protože PyOpenGL, Kivy a další v implementaci využité frameworky vyžívají napojení na C/C ++, je vhodné tento mechanizmus propojení obou jazyků podrobněji popsat. Samotný jazyk Python byl vytvářen se snahou jednoduše umožnit jeho zrychlení prostřednictvím využití zkompilovaných strojových kódů jazyka C/C ++. Existuje hned několik řešení, jak jej s těmito jazyky jednoduše propojit (Martelli, Martelli Ravenscroft, Ascher, 2005). Boost::Python Knihovna Boost je známou knihovnou jazyka C ++ s velice komplexním využitím (multithreading, unit testy, regulární výrazy,... ). Boost::Python představuje knihovnu, která je schopna kompilovat C ++ kód do podoby souborů, které jsou potom z Pythonu dostupné, jako pure-python moduly. Kompletní dokumentace je k dispozici na domovských stránkách projektu ( python/doc/). V principech napojování kódu se přístup této knihovny podobá principu knihovny SWIG. Spolu s C ++ kódem je totiž nutné napsat také wrapper, který s tímto kódem koresponduje. Ten řekne knihovně, které funkce exportovat do Pythonu, a ta se postará o konstrukci modulu využívající příslušný kód v C ++. Drobnou nevýhodou je prakticky závislost vývoje wrapperů na vývojovém nástroji bjam. Jeho používání rozhodně nemůže být označeno za intuitivní. Podle dokumentace jsou i jiné nástroje, jak sestavit moduly. Existuje ale obrovské množství věcí, které se při sestavování mohou nastavit špatně. (Guzman, J., Abrahams, D.,

33 5.2 Propojení PJJ Python s C/C ). Problémem je jednak neintuitivní používání programu bjam, ale také absence chybových výpisů a debuggingu obecně při použití tohoto nástroje. Do implementace bjam je obtížné proniknout, a tím je převod z C ++ do Pythonu mimo kontrolu programátora. Ctypes Ctypes je standardní knihovna jazyka Python. Pracuje jako interface Pythonu do jazyka C. Její výhodou je možnost jednoduchého použití na každém zařízení bez nutnosti instalovat další knihovny. Pracuje na principu využívání funkcí z knihoven jazyka C kompilovaných do shared-objects (soubory s příponou.so, popř..dll na Windows). Další výhodou jejího využití je, že není potřeba vytvářet žádný wrapper. Python je automaticky schopen linkovat funkce jazyka C obsažené v zkompilovaném objektu (Beazley, 2009). Nevýhodou tohoto modulu je fakt, že nespolupracuje s jazykem C ++. Tento modul je vhodné použít zejména pro binding menších částí kódu, kterými chceme zrychlit kritické části software napsaného v Pythonu. Cython Cython ( je nadmnožinou Pythonu. Představuje Python interpreta s rozšířenou syntaxí, který kód neinterpretuje, ale kompiluje do strojového kódu. Výsledkem jsou moduly s příponou.so a.dll. Syntax Cythonu je směsicí konstruktů Pythonu a C. Cython umožňuje používání datových typů jazyka C, ale je plně kompatibilní s Pythonem. Snaží se umožnit vytváření jednoduchého a přehledného kódu (po vzoru Pythonu), který značnou měrou urychlí vykonávání programu (po vzoru C). Tvorba modulů je velice jednoduchá a syntaxe Cythonu je designovaná tak, aby byla srozumitelná pro Python programátory. Prakticky není ani nutná tvorba wrapperů, pouze setup modulu, který řekne Cythonu, jakým způsobem modul zkompilovat. Všechny grafické instrukce a výpočetně náročné úlohy frameworku Kivy byly zrychleny právě tímto nástrojem. SIP SIP byl vyvinut firmou River Bank Computing pro využití frameworku Qt v Pythonu. Dá se ale použít pro tvorbu bindingu libovolného kódu v C ++ pro Python. Při kompilaci C ++ se používá tzv. sip soubor, který obsahuje API definici třídy. Jedná se tedy o klasický wrapper. K němu následně vytvoříme konfigurační soubor, který poskytuje informace ke kompilaci. Po spuštění tohoto skriptu se vytvoří klasický makefile, který zkompilujeme a výsledkem je požadovaný Python modul (Riverbank computing ltd., 2012).

34 5.2 Propojení PJJ Python s C/C++ 34 SIP je dobře a detailně dokumentován (dokumentace na: riverbankcomputing.co.uk/static/docs/sip4/) a praktickou ukázkou jeho pokročilých schopností je právě binding frameworku Qt. Další výhodou je fakt, že SIP využívá standardních nástrojů (např. vytváří klasické makefiles). Nevýhodou SIPu je poměrně podrobný zápis, který je nutný ke kompilaci jednotlivých modulů. Ten může být v případě složitějšího C ++ kódu poměrně náročný na vytvoření. SWIG SWIG umožňuje psaní bindingů pro velké množství jazyků (výše uvedené nástroje jsou cíleny pouze na Python). Díky SWIGu je možné tvořit binding C/C ++ pro Perl, Python, PHP, Ruby, Lua, Tcl, C#, Java. Pro vytváření modulů je potřeba tzv. interface file s příponou.swig. Ta představuje wrapper, který se potom dále používá pro kompilaci do modulu příslušného jazyka. Nevýhodou SWIGu je podobně jako u SIPu nebo Boost::Python nutné opisování poměrně velké části kódu, který se snažíme nabindovat. Interface soubory mohou nabývat na velikosti a jejich syntaxe, která je velice podobná C ++, není příliš přehledná. SWIG byl prvním nástrojem, který binding C ++ kódu pro Python umožňoval, první verze vyšla již v roce 1995 (Swig community, 2012). Z tohoto důvodu je SWIG nejrozšířenějším prostředkem při tvorbě bindingů pro PJJ Python. Tento nástroj byl využit i pro tvorbu PyOpenGL. Původní kód v C byl převeden do Python modulů.

35 6 VLASTNí PRÁCE KLIENT 35 6 Vlastní práce klient 6.1 Design UI Tvorba UI probíhala iterativním vylepšováním z originálního návrhu. Základem je myšlenka jedno-okenní aplikace, která bude dynamicky měnit obsah okna. Základní prvky okna jsou na obrázku níže. Aplikace byla navrhnuta s přihlédnutím k možnostem jejího používání jak na stolním počítači, tak na ovládání dotykem. Obrázek 5: Základní rozvržení okna aplikace Okno aplikace je tedy rozděleno na tyto základní oblasti: 1. Hlavní menu poskytuje možnosti globální navigace v aplikaci. Aplikace je logicky členěna na tři základní celky: projekty, modely a nastavení. Přechody mezi těmito hlavními částmi jsou realizovány právě pomocí tohoto menu. 2. Titulek slouží pro snadnou orientaci v aktuálním obsahu okna. Měl by smysluplně vysvětlovat hlavní obsah okna a určovat, kde jsme zanořeni. Jedná se o jakýsi zjednodušený návrhový vzor breadcrums.

36 6.1 Design UI Kontextové menu toto menu je svázáno s hlavním menu a jeho obsah se proto dynamicky mění. Položky menu představují již konkrétní akce, které je možné v aplikaci provádět (jednotlivé use-case). Pro zobrazení byl vybrán vzhled dlaždic, který uživatelé znají např. z Windows Phone nebo Windows Detail box tato část okna slouží jako oznamovací oblast. V tomto boxu se také zobrazují detailnější informace o objektech, se kterými uživatel pracuje. 5. Hlavní obsah okna zde se zobrazuje hlavní obsah, se kterým aktuálně uživatel pracuje. Dobrých důvodů pro využití jednoho okna a realizace vzoru one-window drilldown je hned několik (Tidwell, 2006): Je to vhodné zejména při menším displayi, obsah okna je zaplněn tím, co chce uživatel vidět. Není zde zbytečně mnoho ovládacích prvků. Uživatelé nejsou příliš zkušení (důraz na jednoduchost). Uživatel není schopen ovládát UI s velkou jemností a přesností (typicky ovládáno dotekem). Prvky UI jsou v designu rozmístěny logicky. Bylo experimentálně zjištěno, že člověk z hlediska vnímání má tendenci číst zleva doprava a shora dolů. Proto i poloha ovládacích prvků byla tomuto principu přizpůsobena. Hlavní menu se nachází v horní části, kontextové menu vpravo od hlavního obsahu. Důraz je právě na maximální zvýraznění hlavního obsahu okna, kterému také uživatel věnuje nejvíce pozornosti a nejvíc jej zajímá. Členění menu v aplikaci odpovídá návrhovému vzoru Button groups. Jednotlivá tlačítka, která spolu souvisí, jsou sdružena v příslušných menu. Tuto zásadu respektují i tlačítka, která se vyskytují v hlavním obsahu okna. V aplikaci je viditelná snaha o jednotný vizuální styl UI, který by měl být vždy sjednocovacím prvkem (Darcey, Conder, 2010). Důležitou součástí GUI bylo také použití principu drag n drop. Tento moderní způsob ovládání umožňuje lepší, přirozenější a s využitím dotykových zařízení také efektivnější způsob ovládání (konkrétně pro přesun objektů z jedné skupiny do druhé). Níže zobrazené okno ukazuje typický příklad nasazení tohoto druhu interakce s uživatelem (párování markerů a objektů).

37 6.2 Implementace 37 Obrázek 6: Příklad využití drag n drop 6.2 Implementace Klient se skládá z několika silně provázaných objektů, které se starají o jeho chod. Jedná se bud o samostatné třídy, které jsou součástí hlavního balíčku aplikace, nebo o celé balíčky tříd zodpovědné za určitou funkcionalitu. Objekt Settings konfigurační objekt celého klienta. Zajišt uje zavedení Kivy frameworku, načtení nastavení atd. Není pouze pasivním objektem, ale přímo provádí některé akce na základě interakce GUI s uživatelem. Objekt Main hlavní třída s hlavní funkcí celé aplikace. Nese reference na všechny objekty, jejichž činnost je pro aplikaci nezbytná. Balíček Models obsahuje všechny třídy objektového modelu, které zastupují objekty reálného světa (modely, markery, projekty,... ). Balíček UI nejdůležitější balíček celé práce. Obsahuje celkem 49 tříd, které se starají o chod uživatelského rozhraní. Balíček errors obsahuje vlastní definované chyby, které se mohou v aplikaci vyskytnout.

38 6.2 Implementace 38 Balíček network velice důležitá součást systému, které obsahuje objekt ThreeDClient, zajišt ující komunikaci klientské části aplikace se serverem. Objekt Museum objekt vytvořený pro průběžné ukládání, které má zrychlit chod aplikace zejména na pomalejších zařízeních. Následuje podrobný rozbor jednotlivých výše zmíněných součástí. Objekt Settings V souboru Settings.py se nachází jediná třída Settings. Součástí této třídy je tato funkcionalita: Načtení nastavení základní nastavení celé aplikace se vždy nachází v domovském adresáři uživatele ve složce.arhell. Pokud tato složka neexistuje, postará se třída o její vytvoření a naplnění. Veškerá konfigurace je představována formou.xml souborů. Jedná se o projekty a kolekce, soubor s modely (models.xml) a konfiguraci aplikace samotné (settings.xml). Všechny tyto soubory jsou parsovány a převedeny do nastavení aplikace při jejím startu. Konfigurace Kivy prostředí tato třída se také stará o to, aby se korektně načetl balíček Kivy. Ten je třeba konfigurovat. Jedná se zejména o načtení vlastních widgetů do továrny Kivy ( api-kivy.factory.html) a parsování všech souborů v Kivy language, aby mohly být použity při běhu GUI. Exporty a importy nastavení nastavení celé aplikace je přenositelné. Hlavní výhodou je zejména možnost přenesení celého projektu a jeho následný import na jiném počítači. Projekt je zabalen do.zip souboru, který obsahuje rovněž všechny použité modely. Na druhém počítači stačí pouze projekt jednoduše importovat. V rámci aplikace existuje několik globálních konfiguračních souborů. Hlavním je soubor settings.xml, který uchovává nastavení aplikace. Níže je uvedena ukázka tohoto konfiguračního souboru. <?xml version= 1.0 encoding= UTF-8?> <settings> <render_server_ip>localhost</render_server_ip> <render_server_port>8259</render_server_port> <independent_server>true</independent_server> <server_startup_command>python ~/ThreeDRenderServer.py </server_startup_command> <remove_with_warning>true</remove_with_warning> <arhell_exec_location>~/arhell</arhell_exec_location>

39 6.2 Implementace Implementace 39 <arhell_settings_location>~</arhell_settings_location> </settings> <arhell_settings_location>~</arhell_settings_location> </settings> Uvedená konfigurace má tyto položky: Uvedená konfigurace má tyto položky: render server ip ip adresa (nebo dns jméno), na které běží render render server. server ip ipadresa(nebodnsjméno),nakteréběžírender server. render server port port, na kterém render server poslouchá. render server port port,nakterémrenderserverposlouchá. independent server závislost, popř. nezávislost serveru na běhu klientské aplikace. server Tedy závislost,popř.nezávislostserverunaběhukli- označuje, je-li serverová část aplikace spouštěna (a independent entské také ukončována) aplikace. Tedy spolu označuje, s klientem, je-li serverová nebo je její část běhaplikace na klientovi spouštěna nezávislý. (a také Ve výchozím ukončována) stavu spolu je server s klientem, built-inebo a tato je její hodnota běh najeklientovi tedy False. nezávislý. Ve výchozím stavu je server built-in a tato hodnota je tedy False. server startup command příkaz, kterým restartujeme server. Může se server jednat startup o lokálnícommand příkaz, ale příkaz,kterýmrestartujemeserver.můžese možno vykonat jej i po síti prostřednictvím jednat ssh (vyžaduje o lokálnívlastní příkaz, nastavení ale je možno klíčů). vykonat jej i po síti prostřednictvím ssh (vyžaduje vlastní nastavení klíčů). remove with warning pokud je tato hodnota natavena na True, aplikace se při with každém warning odstranění pokudjetatohodnotanatavenana True,apli- modelu (3D modelu, projektu,... ) zeptá, remove kace jestli sechceme při každém danýodstranění objekt skutečně modelu smazat. (3D modelu, projektu,... ) zeptá, jestli chceme daný objekt skutečně smazat. arhell exec location cesta k binárnímu souboru s Aurel, který použije arhell při načtení exec vytvořené location textové cesta knastavení binárnímu vlastní souboru aplikace. s Aurel, který použije při načtení vytvořené textové nastavení vlastní aplikace. arhell settings location cesta k adresáři, do kterého je ukládáno textové arhell nastavení settings pro Aurel. location cestakadresáři,dokteréhojeukládánotextové nastavení pro Aurel. Všechny konfigurační soubory aplikace vycházejí ze základních principů xml - jednoduché Všechnysrozumitelnosti. konfigurační soubory Není tedy aplikace nutné vycházejí je podrobněji ze základních popisovat. principů xml - jednoduché Struktura srozumitelnosti. adresáře.arhell Neníjetedy následující: nutné je podrobněji popisovat. Struktura adresáře.arhell je následující: ~/.arhell collections složkasevšemikolekcemivxml models složkasmodely(výchozínastavení) markers složkasmarkery(výchozínastavení) markers.xml konfiguračnísouborpromarkery models.xml konfiguračnísouborpromodely projects složkasprojektyvxml server složka pro činnost serveru (pouze pokud běží na klientovi i server) settings.xml nastaveníaplikace(vizvýše) Objekt Main Objekt Main V souboru Main.py je jediná třída Main reprezentující hlavní třídu aplikace. Jako taková V souboru obsahuje Main.py odkazyjena jediná všechny třída další Main důležité reprezentující třídy aplikace hlavní - in-memory třídu aplikace. databázi Jako s modely takováaplikace, obsahujesettings odkazy na objekt, všechny objekt další třídy důležité Museum, třídyhlavní aplikace okno - in-memory aplikace (instance databázi MainWindow) aklientaprosít ovou komunikaci se serverem.

40 6.2 Implementace 40 s modely aplikace, Settings objekt, objekt třídy Museum, hlavní okno aplikace (instance MainWindow) a klienta pro sít ovou komunikaci se serverem. Tento objekt dědí ze třídy App frameworku Kivy a přepisuje některé její metody (např. v metodě on stop zajistí případné vypnutí závislého serveru). Baĺıček Models Tento balíček reprezentuje všechny modelové třídy. Celá aplikace odpovídá přístupu MVC. Za modelem stojí právě instance tříd obsažených v tomto balíčku. Balíček obsahuje modelové třídy pro kolekce, projekty, modely atp. Všechny tyto třídy obsahují některé standardní funkce, např. možnost konstrukce objektů z xml (metoda from_xml()). Implementují také metodu get_info(). Ta představuje informaci, která je následně o objektu zobrazována v části GUI Detail box. Jedná se vlastně o jednoduchý řetězec charakterizující blíže daný objekt. V tomto balíčku je také třída ModelDB. Ta představuje in-memory databázi všech modelů aplikace, která je vždy vybudována dynamicky při jejím startu. Pro import projektů je součástí aplikace také třída ImportPlayground. Ta umožňuje inteligentní práci s databází modelů při importu projektu, aniž by ohrozila konzistenci dat, které se aktuálně v databázi nacházejí. Baĺıček UI Tento balíček sdružuje klíčové třídy aplikace a stará se logiku chodu klienta. Obsahem jsou.kv soubory, které v Kivy language definují každé jednotlivé okno aplikace, jednotlivé třídy oken aplikace (aplikační logika) a také abstraktní widgety, které použitý grafický framework rozšiřují. Aplikace je inspirována systémem Android a snaží se o co nejmenší zátěž výpočetního výkonu zařízení, na kterém je provozována. Z tohoto důvodu se při změně obsahu okna nepřekresluje celá plocha, ale typicky pouze hlavní obsah okna (viz tvorba UI). Baĺıček UI vlastní widgety Pro účely vytvářené aplikace bylo nutné využít tvorbu některých nových standardizovaných widgetů. Konkrétně se jedná o následující třídy: 1. KivyArhellWidget obecný GUI widget aplikace. Rozšiřuje abstraktní třídu Widget frameworku Kivy. Všechny vlastní jednoduché grafické prvky dědí z této třídy, popř. se jedná o nativní widgety Kivy. Důležitými atributy jsou detail_text, který se zobrazuje v informačním boxu okna a backed_ object. Backed_object je instancí třídy z balíčku models a představuje konkrétní instanci modelu, kterou widget v GUI představuje. Takový přístup umožňuje přímý přístup na model aplikace prostřednictvím GUI.

41 6.2 Implementace ArhellButtonBase abstraktní třída představující podklad pro třídu tlačítka aplikace (ArhellButton). Protože třída není deklarována programově, ale definována pomocí jazyka Kivy, je v této třídě umístěna veškerá funkcionalita tlačítek aplikace (registrace signálů, možnost změny obrázku nebo textu pomocí Kivy object properties). 3. ArhellButton tlačítko aplikace. Je definováno jako každý jiný grafický widget pomocí Kivy language. Tato třída představuje Kivy template ( která dědí z abstraktní třídy svého předka. V.kv souboru je potom definován obecný layout tlačítka, který vychází z grafického návrhu aplikace. 4. InformableWindow obecný předek části okna aplikace. Jeho hlavní funkcionalita spočívá v možnosti získat detail box (funkce get_detail_content()) a informování o provedené události (funkce inform()). Z tohoto widgetu dědí veškeré třídy, které se objevují v hlavním obsahu okna. 5. AvailableModelsBox widget představující grid (tabulku) grafických prvků. Tento obecný přístup zobrazení (pole prvků) je v aplikaci používán poměrně hojně, proto byl abstrahován do této třídy. Obsahem pole mohou být libovolné grafické prvky (potomci třídy kivy.uix.widget). Prvky přidáváme do seznamu object property model_list. 6. ArhellModelImage widget rozšiřující BoxLayout Kivy, ve kterém se nachází obrázek 3D modelu a jeho popisek. Jednoduchý statický widget, který se ale v GUI vyskytuje velice často a jeho opakovaná konstrukce by tedy byla neefektivní. 7. ArhellProjectTreeViewLabel jednoduchá třída, které je potomkem KivyArhellWidget a Kivy.uix.treeview.TreeViewLabel a sdružuje jejich funkcionalitu. 8. DeleteWarning pokud je v konfiguračním XML souboru zapnutá volba remove_with_warning, pak se vždy při mazání objektu zobrazí výstražné okno s potvrzením smazání. Varovné okno je definováno napříč celou aplikací touto třídou. Automaticky se po potvrzení vyvolá signál on_delete. Argumenty jsou tomuto signálu posílány pomocí Python pole kwargs. 9. FileChooserWindow objekt sloužící pro vybírání určitého druhu souborů přes GUI. Jeho konkrétními potomky v GUI jsou ModelSelectorWindow a MarkerSelectorWindow obsahují objekt typu FileChooser z Kivy, který je modifikován v konstruktoru pomocí parametru allowed_extensions. 10. TextInputMinSize rozšíření třídy kivy.uix.textinput. Tento widget má totiž nevýhodu: nelze ve výchozím stavu určit jeho minimální velikost. To je při klasickém využívání relativního pozicování v layoutu nevhodné. TextInput by totiž mohl zejména na zařízeních s menším displayem mít

42 6.2 Implementace 42 malou velikost a nebylo by vidět jeho obsah. Pomocí metody bind() je tedy připojena změna příslušné Kivy property. Ta volá funkci guarantee_min_ size(), která postupně navýší velikost widgetu, aby dosáhla požadované hodnoty uložené v atributu min_size. Baĺıček UI implementace drag n drop v Kivy Hlavním funkčním rozšířením a velmi podstatnou částí práce byla implementace drag n drop v Kivy. Tento přístup ovládání totiž není v Kivy nativně přítomen (v ). Implementace vycházela z klasických metod a signálů, které jsou v Kivy dostupné. Využití našly zejména Kivy properties a metoda bind(). Drag n drop byl implementován nenásilnou formou jako rozšíření klasického Kivy widgetu. Implementace také umožňuje alternativní obsluhu GUI pro uživatele, pro které je drag n drop těžko pochopitelný nebo hůře použitelný. Implementovaný widget je k dispozici samostatně na koszta5/kivydnd. Po domluvě s autorem Kivy frameworku je velmi pravděpodobné, že tento kód z DP by měl být zařazen do master větve Kivy a měl by se stát součástí oficiálních budoucích vydání. Samotný objekt DragNDropWidget se nachází ve stejnojmenném modulu. Konfigurace drag n drop probíhá prostřednictvím základních atributů: bound_zone_objects (typ Kivy.properties.ListProperty) každý widget, který je tažitelný (draggable), je ohraničen. Tj. existuje ohraničená oblast, kam až je možno widget táhnout (nedá se táhnout libovolně přes celé okno aplikace). Aby se předcházelo problémům s absolutním a relativním zadáním polohy této oblasti, je tato oblast definována jinými widgety. Pokud tedy do tohoto seznamu přidáme objekty, bude možné daný drag n drop widget táhnout až do jejich x a y pozice v GUI. Nejlépe se pro tuto funkci hodí různé druhy kontejnerů, které takto jednoduše oblast ohraničí. droppable_zone_objects (typ Kivy.properties.ListProperty) tento seznam sdružuje objekty, kde je korektní drag n drop widget pustit. Tj. pokud je objekt puštěn v této zóně, provede se akce puštění, v opačném případě se objekt vrátí na své původní místo dragging byl neúspěšný. drag_opacity (typ Kivy.properties.NumericProperty) popisovaná třída DragNDropWidget umožňuje vlastní nastavení průhlednosti widgetu při jeho tažení (0.0 až 1.0). Průhlednost taženého objektu je nastavována touto property. Ve výchozím stavu je tato hodnota 1.0 drop_func (typ Kivy.properties.ObjectProperty) objekt Python funkce, která má být spuštěna po úspěšném puštění objektu (tj. daný objekt je puštěn v droppable_zone, je vyvolán příslušný signál a spuštěna on_drop funkce).

43 6.2 Implementace 43 drop_args (typ Kivy.properties.ListProperty) argumenty, které mají být při vykonání předány drop_func. remove_on_drag (typ Kivy.properties.BooleanProperty) speciální rozšíření. Ve výchozím stavu je nutné, aby objekt, který dědí z třídy DragNDropWidget, implementoval metodu deepcopy (). Při tažení totiž původní prvek nemizí, je pouze pro tažení kopírován. Pokud si přejeme, aby daný prvek po úspěšném přetažení nebyl již v původním umístění dostupný, nastavíme tuto property na True. V tomto případě ani není nutné implementovat metodu deepcopy () balíku copy. Implementace objektu obsahuje také privátní atributy _dragged a _draggable. První je stavovým indikátorem určujícím, zda je objekt právě tažen. Druhý je jakýsi absolutní override. Pokud je nastaven na False, objekt ztratí schopnost být tažen, ale bude si pamatovat všechny výše zmíněné properties. Tento atribut je vhodný k dočasnému vypnutí drag n drop. Pro správnou funkcionalitu je nutné definovat tři nové signály: 1. on_drag_start na začátku je detekováno, jestli vůbec má být tento signál vyvolán. Ve výchozím stavu trvá 0,2 sekundy, než se objekt stane draggable. To je proto, aby bylo možné rozlišit mezi tažením objektů a klasickým kliknutím na ně. Po vyvolání této události jsou spočítány maximální a minimální velikosti x a y, kterými je tažení ohraničeno (to obstará funkce set_bound_axis_positions()). Dále je také nutné zkopírovat příslušný objekt (pokud je nastaveno remove_ on_drag=false). Pro správné a funkční tažení je nutné, aby byl daný widget potomkem hlavního okna v hierarchii grafických prvků, které jsou právě zobrazovány (jinak by se pomocí statického nastavování změn x a y souřadnice nic nestalo). Toho docílíme funkcí reparent(). Pro případ neúspěšného tažení existují metody reborn() a deparent(), které odstraní widget z hlavního okna a vrátí jej do původního kontejneru. 2. on_being_dragged tento signál je vlastně shodný s existujícím signálem Kivy on_touch_move. Widget dynamicky mění svoji pozici x a y podle pozice x a y daného objektu třídy MoutionEvent. Tyto hodnoty jsou ale podrobovány kontrole a podřizovány hodnotám min/max x/y, které nastaví funkce set_bound_axis_positions(). 3. on_drag_finish tato metoda v prvé řadě detekuje, jestli byl objekt korektně puštěn (na jednom z objektů droppable_zone). Pokud ano, spustí úspěšnou fade-in animaci a přidá widget do příslušného kontejneru. Pokud ne, spustí animaci navrácení na původní místo. Pokud je tažení neúspěšné a je nastaveno remove_on_drag=true, je také nutné spustit metodu reborn().

44 6.2 Implementace 44 Protože princip fungování drag n drop nemusí být všem uživatelům (zejména těm méně zběhlým) srozumitelný, popř. nemusí být pro určitou skupinu uživatelů dostatečně efektivní, implementuje třída DragNDropWidget také alternativu k této manipulaci s pozicí widgetu. Tato alternativa je pojmenována jako easy access dnd. Představuje princip, kdy se po najetí kurzorem myši na konfigurovaný objekt objeví manipulační lišta (viz obrázek níže po najetí myši se pod objektem objeví křížek značící jeho přidání do určité jiné oblasti). Pomocí lišty jsme schopni kliknutím dosáhnout stejné funkcionality jako při použití drag n drop. Při použití této metody v praxi je nutné konfigurovat další signály a atributy objektu. Výhodou je potom komplexní objekt, který je schopen drag n drop provádět konvenční i netradiční formou. Obrázek 7: Princip easy access dnd Pro správnou funkcionalitu easy access dnd je třeba konfigurovat tyto atributy třídy DragNDropWidget: easy_access_dnd_function funkce, která je spuštěna při přijetí signálu on_motion_over viz níže. V principu může dělat cokoliv, ale podle návrhu by měla zobrazovat ovládací GUI prvky, které umožní clickable drag n drop. easy_access_dnd_function_out funkce spouštěná při signálu on_ motion_out. Obecně by se měla starat o odstranění zbytečných GUI prvků, které byly přidány výše uvedenou metodou. easy_access_dnd_function_binds funkce, které mají být vyvolány jako alternativa tažení (při zahájení simulovaného tažení prostřednictvím metody easy access dnd). Měly by se starat o přesun widgetu na příslušné místo a změny jeho rodiče v závislosti na widget tree. Tento atribut představuje Python list, je tedy možné tedy nabindovat libovolný počet funkcí jako akce, které mají být postupně provedeny.

45 6.2 Implementace 45 easy_access_dnd_function_arguments argumenty, které mají být předány v nezměněném stavu funkcím vyvolávaným postupně z listu easy_access_dnd_function_binds. Všechny tyto atributy jsou jednoduše nastavitelné za pomoci jediné funkce. Implementace tohoto pseudo-interface je tedy možná prostřednictvím funkce easy_access_dnd() příslušného objektu s výše uvedenými argumenty. Toto chování objektu zrušíme zavoláním disable_easy_access_dnd(). Je nutné také registrovat následující nové signály objektu: 1. on_motion nejdůležitější z trojice signálů spojených s easy access dnd. Pomocí statického objektu Kivy.core.window.Window získáme pozici myši v okně a připojíme ji na tento signál: Window.bind(mouse_pos=self.on_motion) 2. on_motion_over tento signál je volán v případě, že je zjištěno, že pohyb myši prošel přes hlídaný objekt s funkcí easy access dnd. Atribut fired_ already indikující volání funkce easy_access_dnd_function je nastaven na True, aby se zamezilo opakovanému volání. 3. on_motion_out pokud je pozice myši mimo objekt a fired_already= True, je vyvolán tento signál, na který je napojena funkce easy_access_ dnd_function_out. Základní funkcionalita je tedy umístěna v modulu DragNDropWidget.py ve stejnojmenné třídě. Z této třídy dědí další následnické třídy, které jsou v aplikaci hojně používány. Další widgety, které používají implicitně drag n drop jsou tyto: DragableImage jednoduché rozšíření třídy Kivy.uix.Image, táhnutelný obrázek používaný při párování markerů s modely. DragableArhellImage komplexní widget typu kontejner, který sdružuje obrázek, popisek a obslužnou lištu. PairedDragableArhellImage widget pro zobrazení již spárovaných modelů s markery. Na základě provedené implementace tedy není problém rozšířit jakýkoliv libovolný Kivy widget a přidat mu drag n drop funkcionalitu. Baĺıček UI aplikační logika Funkcionalita GUI aplikace je realizována v třídách představujících jednotlivá okna. Díky použití Kivy language je zcela odstíněna tvorba widgetů GUI v kódu, a proto je implementace přehlednější a odpovídá požadavkům MVC. Jedním ze základních principů GUI je vnoření a vkládání jednotlivých oken do sebe. Tento princip ušetří výpočetní výkon a zrychlí celou aplikaci (překresluje se

46 6.2 Implementace 46 pouze ta část okna, kterou je skutečně nutno překreslit). Princip vkládání oken do sebe je zobrazen na obrázku (jednotlivé části jsou potomky Kivy.uix.BoxLayout). Obrázek 8: Příklad vkládání oken do sebe preview modelu Jediné okno, které je v aplikaci vždy přítomné, je instance třídy MainWindow. Hlavním úkolem tohoto okna je být kontejnerem pro ostatní okna a měnit sekci aplikace pomocí hlavního menu. K tomu slouží funkce change_section(). Ta detekuje, na kterou položku menu bylo kliknuto, provede přechodovou animaci a zobrazí obsah příslušného okna sekce. Přidávání oken do hlavního obsahu se děje přes volání metody add_to_content_pane(). Všechna okna aplikace jsou napsána přehledně a velice analogicky. Primitivní okno aplikace je instancováno tímto způsobem: 1. Vytvoř instanci třídy okna (dědí ze třídy InformableWindow). 2. Kivy automaticky načte design třídy v Kivy language, který je už umístěný v paměti. 3. Kivy se automaticky postará o naplnění ObjectProperty třídy na základě id identifikátoru v.kv souboru. 4. Zavolá se funkce setup_ui(). Ta má na starost výchozí konfiguraci okna, pokud je nutná. 5. Zavolá se funkce connect_signals(). Tato funkce připojuje widgety a události na aplikační logiku obsaženou v dané třídě. Jednotlivá okna jsou díky vnořenému principu logicky provázána. Díky dostupnosti funkce get_app() (dědí se z InformableWindow) jsme schopni volat get_app().get_ main_window() a pracovat s obslužnými funkcemi hlavního okna, popř. jednotlivých

47 6.2 Implementace 47 oken sekce. Tímto způsobem je funkcionalita správně rozvrstvena podle úloh a důležitosti jednotlivých oken. Baĺıček errors Podobně jako Java i Python má velice sofistikovanou práci s chybami. Implementace chyb v Pythonu je Javě analogická. V balíčku errors jsou 3 jednoduché třídy vlastích chyb, které se v aplikaci mohou vyskytnout: InvalidProjectXML chyba značící chybnou XML definici projektu (je kontrolováno oproti.xsd souboru s XML schematem). NoServerRunning chyba vyvolaná při sít ové komunikaci klienta se serverem. Klient se snaží zavolat server, ačkoliv takový server není dostupný. ServerNotReady chyba vyvolaná v okamžiku, kdy se klient snaží komunikovat se serverem, který teprve renderuje modely ve výchozím natočení. Server není schopen na klientovy požadavky reagovat. S chybami souvisí také logování. V aplikaci je využit výchozí system logování frameworku Kivy. Kivy pro logování používá objekt Logger, který je importován v drtivé většině tříd a většina chování aplikace je důsledně logována. Úroveň logování pro aplikaci je shodná s nastavením úrovně logování v ~ /.kivy/kivy.ini. Využití objektu Logger je velice intuitivní, jak dokazuje následující ukázka. from kivy.logger import Logger Logger.trace(self. class. name + ": This is just a trace msg" ) Logger.debug(self. class. name + ": This is debug msg" ) Logger.info(self. class. name + ": This is info msg" ) Logger.warning(self. class. name + ": This is warn msg" ) Logger.error(self. class. name + ": This is error msg" ) Logger.critical(self. class. name + ": This is critical!!!" ) Baĺıček network Tento balíček se v zásadě týká renderování modelů pomocí sít ového spojení. Obsahem balíčku je několik tříd, z nichž většina patří k serveru, který renderování obsluhuje (obsahem balíčku jsou soubory klienta i serveru). Z hlediska klienta se používá pouze jedna třída ThreeDRenderClient z modulu stejného jména. Pro komunikaci se serverem se používá REST protokol (vysvětleno v následující kapitole). Klient samotný je poměrně jednoduchou třídou. Při jeho vytvoření se v konstruktoru nastavují základní parametry spojení (ip adresa serveru, port). Pro identifikaci jednotlivých požadavků používá klient unikátní ID, která jsou v klientovi udržována.

48 6.2 Implementace 48 Klient kontaktuje server prostřednictvím metody contact_server(). Ta vlastně pouze jednoduše vytvoří zprávu daného protokolu, pošle na server, získá odpověd a tu předá jako svou návratovou hodnotu. Parametry, které klient posílá serveru, jsou popsány v následující kapitole. Klient umožňuje také díky Python built-in knihovně ftplib kopírovat na server modely protokolem FTP. Jedná se o jakési uživatelské zjednodušení, kdy není nutné manuálně instalovat každý model na server, ale modely je možné nakopírovat na server prostřednictvím tohoto protokolu. FTP server běží pouze po dobu kopírovaní a sám se poté ukončí. Třída ThreeDRenderClient obsahuje mimo také metodu kill_server(), která se postará o korektní ukončení serveru a všech jeho procesů. Typické volání klienta probíhá z GUI. Klient je volán jako reference třídy App (samozřejmě nikoliv bez parametrů): #funkci contact_server je treba dodat prislusne parametry self.get_app().get_client().cotact_server()

49 7 VLASTNí PRÁCE SERVER 49 7 Vlastní práce Server Základním principem fungování aplikace je možnost vzdáleného renderování 3D objektů. Tuto funkcionalitu zabezpečuje ThreeDRenderServer. Klientská aplikace může běžet na libovolném mobilním nebo desktopovém operačním systému. Serverová část má jisté závislosti, které ji odkazují v možnostech použití pouze na operační systémy stolních počítačů. Stejně jako klient, i server je čistý Python (s využitím PyOpenGL bridge na OpenGL). 7.1 Použité knihovny a technologie Pro tvorbu serveru byly použity knihovny, které zastanou typické úlohy správy požadavků serveru. Bylo by zbytečné tvořit např. vlastní HTTP server a nevyužít již zavedených implementací. Je také nutné rozhodnout, jaký komunikační protokol bude pro interakci serveru s klientem použit. REST protokol Pro účely komunikace render serveru s klientskou částí aplikace byl v rámci DP zvolen standardní protokol REST, který navrhl Roy Fielding ve své dizertační práci. REST (Representational state transfer) protokol je silně ovlivněn HTTP protokolem, a bere si to nejlepší z něj, ale současně se snaží vyhnout jeho některým chybám. Cílem je zejména uniformnost rozhraní pro všechny služby, které daný protokol používají. Dále je to také minimalizace přenášených dat např. HTTP přenáší celou řadu zbytečných hlaviček (Fielding, 2000). Typická implementace RESTu využívá HTTP protokol pro požadavky na server a server vrací zpět json, popř. XML (typicky bez hlaviček). Tento protokol však není nadmíru svazující návratová data mohou být téměř jakákoliv. Jako user-agent může být díky povaze svého fungování použit klidně klasický webový prohlížeč (Fielding, 2000). Byla zvolena implementace RESTu, která používá pro požadavky protokol HTTP, server vrací zprávu v XML. Takový druh implementace totiž umožňuje velice širokou použitelnost a neklade na klienta téměř žádné požadavky. Klientem může být téměř cokoliv (webový prohlížeč nebo cokoliv jiného, co dokáže zpracovat XML zprávu). Framework twisted Server byl vybudován na jednom z nejrozšířenějších Python frameworků pro práci se sítí twisted ( Twisted je závislostí a součástí frameworku Kivy, a proto je možno jej efektivně využít, aniž by se zbytečně rozšiřovala závislost aplikace na dalších knihovnách. Základní vlastností twisted je asynchronní zpracování, které je také známé jako event-driven programování. Asynchronní přístup twisted je implementován

50 7.1 Použité knihovny a technologie 50 Obrázek 9: Konkrétní implementace protokolu REST návrhovým vzorem reactor. To znamená, že server v tomto frameworku reaguje dynamicky na jednotlivé události, není třeba nijak řešit operace s vlákny (Martelli, Ravenscroft, Ascher, 2005). Dice 3DS Pro renderování modelů ve formátu 3ds v programovacím jazyce Python je možné použít modul Dice 3DS ( Ten je schopen binární.3ds soubory načíst (více popis formátu zde net/topic/ ds-parsing-tutorial/), extrahovat patřičné informace pro rendering a scénu vykreslit. Tento modul pro vykreslení 3D scény používá PyOpenGL. V současné verzi frameworku (v. 0.13) se nachází poměrně nepříjemný a nereportovaný bug. Dice 3DS není totiž správně schopna načíst textury (z rastrového obrázku), pokud se k příslušnému meshi 5 nějaké váží. Oprava je naštěstí velmi jednoduchá. V modulu je potřeba editovat soubor Dice3DS/example/anygl.py následujícím způsobem: 47 def glgentextures(n): 48 # Pavel Kostelnik fix - 2 lines v~= ctypes.c_ulong() _pyglet_glgentextures(n,ctypes.byref(v)) v~= ctypes.c_uint() 52 _pyglet_glgentextures(n, v) 53 return v.value Tato oprava se váže k funkci, která generuje textury. Pro komunikaci s modulem pyglet, který textury zajišt uje, se pro zrychlení využívá nativní propojení modulem ctypes (viz oddíl 5.2). Tvůrce ale použil špatný datový typ, který korektní nahrání textur znemožňuje. Po nahrazení datového typu Dice 3DS bez problému pracuje i s modely, které mají textury ploch v přidružených obrázcích.png nebo.jpg. 5 Mesh je soustava vrcholů, hran a ploch, které v 3D modelování definují konkrétní objekt.

51 7.2 Implementace Implementace Praktickým cílem implementace serveru bylo vytvořit program, který bude schopen vzdáleně překreslovat 3D modely. Realizaci serveru bylo nutné rozložit do několika součástí, které spolu komunikují (viz obrázek). Obrázek 10: Zjednodušená architektura serveru Funkcionalita byla tedy podle objektového návrhu rozdělena do následujících celků: Objekt ThreeDRenderServer základ celého serveru. Implementuje princip fungování frameworku twisted. Objekt RenderWindow třída pro vykreslování jednoho konkrétního 3D modelu pomocí knihovny Dice3DS, respektive PyOpenGL. Objekt RenderServerFTP pro uživatelskou přívětivost obsahuje serverová část aplikace také FTP server fungující na on-demand principu. Objekt RenderProtokol abstrakce tvorby XML zpráv, které jsou ze serveru posílány klientovi. Objekt ThreeDRenderServer ThreeDRenderServer je jádrem serverové části aplikace. Stará se o spouštění RenderWindow objektů vykreslujících jednotlivé modely a zabezpečuje komunikaci s klientem. Nedílnou součástí instance serveru je reference na objekt třídy Root, která dědí z třídy twisted.web.resource. Třída Root představuje jednoduchý objektový router, který přeposílá jednotlivé požadavky na příslušnou třídu, jež je zpracovává.

52 7.2 Implementace 52 Jedná se vlastně o namapování url na objekt (view), které je široce rozšířené (J2EE, django,... ). Konkrétně server obsluhuje následující url: /RenderObject/.* URL v tomto tvaru zpracovává stejnojmenná třída. Jedná se o typické zprávy na server, které představují požadavek na překreslení objektu. /LoadModels/.* tyto požadavky spravuje třída LoadModels. Jedná se o servisní třídu, která vrátí klientovi soubor models.xml. Klient tedy nemusí složitě zjišt ovat, které modely jsou na serveru dostupné. Server mu seznam modelů sám nabídne. /ServerClosure/.* při vyvolání požadavku s tímto URL navázaná třída zavolá podle předaných parametrů korektní ukončení činnosti serveru. Je tedy možné ho tímto požadavkem jednoduše vypnout na dálku. /FTP/.* pro pohodlné přidávání modelů ze strany klienta je součástí serveru také FTP server. Ten je implementován děděním třídy z modulu PyFTPdlib ( PyFTPdlib je knihovna implementující FTP server v čistém Pythonu. Na stránkách projektu jsou uvedena srovnání s běžně používanými FTP servery, která ukazují na efektivitu a rychlost této knihovny. Hlavní třída se také stará o start oken, která vykreslují jednotlivé objekty načtené z konfiguračního souboru models.xml. Tato funkcionalita je implementována v metodě start_model_renders(). Ta postupně konstruuje instance třídy RenderWindow pro každý model jednu. Tyto instance představují samostatné procesy (OS X, Linux), popř. samostatná vlákna (Windows). Samotná okna pak drží v listu self._renders. Zároveň jim také ale pro potřeby vnitřní komunikace přiděluje staticky číslo UDP portu, na kterém okna poslouchají výskyt událostí (viz popis třídy RenderWindow). Čísla přidělených portů jsou ordinální čísla od výše. Objekt RenderWindow RenderWindow je okno, které je zodpovědné za překreslování jednoho konkrétního modelu. O vykreslení modelu se stará Dice 3DS. Aby bylo vůbec možné provádět překreslování několika modelů najednou (tedy aby server současně mohl obsluhovat několik modelů), je nutné odstínit komunikaci objektů RenderWindow a ThreeDRenderServer od komunikace ThreeDRenderServer s ThreeDRenderClient. Řešením je použití jednoduché komunikace mezi instancemi RenderWindow a ThreeDRenderServer na loopbacku. Protože se jedná o komunikaci, při které nehrozí ztráta packetů, je pro rychlost vhodnější použít UDP protokol. Ve svém konstruktoru dostává RenderWindow dva parametry absolutní cestu k modelu, který má načíst a také číslo UDP portu, na kterém bude probíhat komunikace s hlavní částí serveru. Při startu se zavolá funkce prerender_model(),

53 7.2 Implementace 53 která vykreslí model v základním natočení. Vrátí konkrétně instanci třídy GLModel modulu Dice3DS. Ve vnořené třídě Options je možné nastavit některé vlastní parametry vykreslování (podrobněji dokumentace Dice3DS). Pro korektní fungování okna je nutné vytvářet každý model (okno) jako zvláštní proces. Pro správu oken a jejich získávání je totiž použit framework pygame, který nepodporuje tvorbu více oken v jednom vlákně (pygame je postaven na starší verzi SDL 6 ). Objekt RenderServerFTP Tento objekt vzniká dynamicky na základě pokynu objektu FTP, který zpracovává příslušný požadavek klienta. FTP server je otevřen na portu Při startu se automaticky přidá výchozí uživatel, který představuje spojení z libovolného klienta (není potřeba je rozlišovat). Jako výchozí domovská složka je zvolena složka ~/.arhell/models. Zde jsou následně modely kopírovány. Po dokončení přenosu je FTP server opět uzavřen. Objekt RenderProtokol Tento modul a třída v něm obsažená generuje XML zprávy, které jsou následně zasílány klientovi. Pro tvorbu XML se používá knihovna lxml, která je napsaná v jazyce C a pro Python je k dispozici její binding. Tvorba XML (ta představuje velkou část režie serveru) je tedy zrychlena na úroveň provádění strojového kódu. Render protokol je jednoduchý XML soubor. Je vytvořen na základě konfigurace objektu této třídy, který je následně marshalizován 7. <?xml version= 1.0 encoding= UTF-8?> <msg ip=" " origin="server"> <type>render</type> <raw_data><!-- base64 encoded image --> </raw_data> </msg> V této ukázce XML generovaného objektem třídy RenderProtokol jsou zřejmé základní tagy tohoto komunikačního protokolu. Atributy ip a origin charakterizují původce zprávy. Type určuje typ zprávy: zde je to render tedy zpráva o překresleném objektu. V tagu raw_data, který je u některých zpráv prázdný, se v tomto případě bude vyskytovat obrázek ve formě řetězce zakódovaného do base64. Toto kódování je použito jednak z integritních důvodů, ale také kvůli samotné podstatě přenosu (v XML nelze přenášet binární data). 6 Více na 7 Object marshalling je převod objektů z paměti do podoby, která je transformovatelná a dále přenositelná. Typicky se používá právě XML nebo JSON.

54 7.2 Implementace 54 Postup při překreslování Typickým požadavkem na server je požadavek o překreslení nějakého 3D objektu. Překreslení samotné je poměrně složitý proces. Skládá se z několika kroků, které provádějí různé objekty tvořících server. Následuje příklad postupu při překreslení modelu. 1. Vytvoření požadavku na začátku je nutné vytvořit příslušné URL a HTTP požadavek, který informuje server o nutnosti model překreslit. URL pro překreslování mají následující tvar: Dále je třeba zakódovat jako minimální hodnoty následující parametry: file absolutní cesta souboru.3ds na serveru, který má být překreslen (slouží pro server jako identifikaci okna, které má být přerenderováno). position řetězec, který představuje za sebou jdoucí parametry výšku, úhel a vzdálenost určující nové požadované natočení modelu. type druh zprávy, která je serveru zasílána (tedy jakým způsobem se má nakládat s obsahem position parametru). Výhodou serveru je, že obsluhuje stejně GET i POST HTTP požadavky. Proto je velice lehké všechny parametry zakódovat do URL jednodušší cestou a použít pro jejich uložení GET. Takové výsledné URL, kde parametry budou součástí GET požadavku, může vypadat např. takto: position=10,45,1.0&type=update 2. Routing požadavku třída Root, obsažená v modulu ThreeDRenderServer.py zavolá příslušnou funkci render_get() třídy obsluhující toto URL. Tato funkce prostřednictvím metody update_render() vytvoří jednoduchou zprávu, kterou pošle protokolem UDP na příslušný lokální port. Na portu poslouchá instance RenderWindow zodpovědná za daný 3D objekt. Správný port je získán díky vazbě mezi portem a názvem souboru. Vazba je uložena v atributech _render_local_ports, respektive _model_files hlavní třídy serveru. 3. Překreslení modelu RenderWindow si prostřednictvím metody update() hlídá ve smyčce událostí pygame, jestli na jejím lokálním portu nedošla nějaká zpráva. Pokud tomu tak je, vytvoří následujícím způsobem novou pygame událost, která pak ovlivní hlavní smyčku.

55 7.2 Implementace 55 ev = pygame.event.event(pygame.userevent, { data : data, addr : addr, clientid : clientid}) Této události jsou v Python dictionary předány parametry překreslení ve formátu výška, úhel, vzdálenost je natočení předáno jako parametr data. Ip adresa klienta je předána jako parametr addr. Dále je předán jednoznačný identifikátor klienta generovaný automaticky při spojení. Vytvořená událost je zachycena v hlavní smyčce RenderWindow. Při zpracování této události jsou dekódovány parametry nutné pro překreslení a proměnná redraw okna je nastavena na hodnotu True. Následuje automatické překreslení okna. Při překreslení se výsledný surface (obrazovka pygame) vyfotografuje a uloží jako string do dočasného souboru (v adresáři ~/.arhell/server/msgs) metoda post_model_update(). 4. Odeslání odpovědi ThreeDRender server objekt čeká na odpověd překreslení od RenderWindow. Jakmile je tato odpověd k dispozici (ve formě dočasného souboru), vytvoří server instanci RenderProtocol. Její tag raw data naplní obsahem souboru a instanci marshalizuje. Výsledné XML odešle klientovi jako odpověd. 5. Přijetí a zpracování zprávy i po přijetí zprávy je od XML odpovědi až ke grafickému widgetu v Kivy ještě poměrně dlouhá cesta. XML je třeba rozparsovat a zpracovat obsah tagu raw data. Typickou funkcí, která se stará o nahrání překresleného modelu do GUI klienta, je funkce handle_image_2gui_load() třídy ModelsWindow balíčku UI. def handle_image_2gui_load(self, server_xml, model, parent_widget, react_function=none, class_to_construct=arhellmodelimage): xml_tree = etree.iterparse(stringio(server_xml)) for action,element in xml_tree: if element.tag == "raw_data": texture = Texture.create(size=(200, 200), colorfmt= rgb ) data = element.text.decode( base64 ) texture.blit_buffer(data) texture.flip_vertical() img = class_to_construct(size=texture.size, texture = texture, desc=model.get_name(), backed_object= model, window= self) img.bind(on_touch_down=react_function) parent_widget.add_widget(img) Postupné pořadí argumentů funkce:

56 7.2 Implementace 56 server_xml řetězec XML, který byl získán jako odpověd serveru, model model balíčku models, který widget zastupuje, parent_widet kontejner, do kterého má být widet vsazen, react_function funkce, která má být spuštěna po stisknutí widgetu, class_to_construct třída grafického widgetu, jehož instance má být vytvořena. Funkce vytvoří z dekódovaného base64 objekt Kivy.graphics.texture. Texture. Jedná se o klasickou tříbarevnou texturu vzniklou rozšířením textury knihovny PIL 8. Následně je vytvořena instance widgetu, kterému je textura předána v konstruktoru a ten ji použije pro vykreslení sebe sama. Tato funkce je velice univerzální, protože je schopna dynamicky vytvářet objekty libovolných tříd pracujících s texturou objektu a připojovat k nim funkce předané parametrem. Zpracování odpovědi je pouze ukázkou, která se využívá v konkrétní implementaci klientské aplikace napsané v programovacím jazyce Python v Kivy. Největší výhodou serveru je totiž jeho výstupní formát. Komunikace pomocí REST protokolu zpřístupňuje tuto službu pro velice širokou škálu zařízení. Render server může využívat téměř libovolný klient. Klienti mohou disponovat grafickým rozhraním a výsledky přímo vykreslovat nebo mohou získávat odpověd na příkazové řádce a tu dál přeposílat. Vytvořit HTTP požadavek a zpracovat XML odpověd zvládne prakticky libovolný počítač, se kterým uživatelé v dnešní době pracují (včetně mobilních zařízení). 8 Python Imaging Library je nejpoužívanější knihovna v jazyce Python pro manipulaci s obrázky.

57 8 HODNOCENí 57 8 Hodnocení 8.1 Omezení současného řešení Pro samotný chod serverové části aplikace je nutná oprava modulu Dice3DS (popsáno v části 7.1). Serverová část aplikace musí být provozována na některém z desktopových operačních systémů. Vykreslování v rámci PyOpenGL totiž používá některá volání, které nejsou součástí specifikace OpenGL ES 2.0 obstarávající běh Kivy na mobilních platformách (Munshi, Ginsburg, Shreiner, 2008). Výhodou vytvořené aplikace jsou zejména prakticky nulová omezení na straně klienta. Klient nezávisí na žádných externích Python knihovnách. Veškeré funkce jsou součástí frameworku Kivy, at už se jedná o knihovnu lxml pro parsování konfiguračních souborů a zpráv ze serveru nebo o sít ový framework twisted. 8.2 Možnosti využití aplikace Výsledná aplikace slouží primárně jako uživatelsky přívětivé GUI pro správu projektů software Aurel. Obecně má však ale daleko širší využití. Vzhledem k použitému univerzálnímu protokolu nic nebrání tvorbě dalších klientů. Mohou to být např. nativní klient pro Android nebo webová aplikace využívající funkcionalitu serveru. Webová aplikace je pouze otázkou napsání programu v příslušném (libovolném) jazyce, který se na server připojí. Tvorba takových aplikací je velice jednoduchá a spočívá pouze ve vytvoření a zpracování příslušného požadavku a odpovědi protokolu REST. Díky architektuře klient/server může aplikace také poskytovat službu překreslování 3D objektů i mnoha klientům, jejichž zátěž by při těchto operacích byla zbytečně velká. Architektura serveru samotného umožňuje překreslování prakticky libovolného počtu objektů. Každý je renderován ve vlastním vlákně, a proto je server schopen využít výpočetního výkonu nejmodernějších počítačů s mnoha procesorovými jádry. Aplikace může také sloužit k obecné kategorizaci 3D modelů pro libovolné účely. Schéma projektů, kolekcí a modelů je znovu použitelné a volně přenositelné do libovolných podmínek. To umožňuje zejména formát ukládání (soubory.xml s jednoduchou sémantikou). Budoucnost vývoje aplikace je možné vidět v rozvoji nových klientů pro ThreeDRenderServer. Jinou možností rozšíření aplikace je podpora dalších formátů 3D modelů. Takové rozšíření by znamenalo dědit ze třídy RenderWindow a implementovat vlastní vykreslování modelu příslušného formátu. 8.3 Ekonomické hodnocení Koncept vykreslování 3D modelů na dálku prostřednictvím REST protokolu může být pro implementace, které rendering 3D používají, velice zajímavou alternativou. To

58 8.3 Ekonomické hodnocení 58 platí zejména pro dnešní dobu, kdy je snaha stávající programy propojit s mobilními zařízeními. V tomto případě by implementovaná aplikace ušetřila velké náklady za analýzu i vlastní vývoj. Náklady je možné snížit zejména díky velice jednoduchému API, které server poskytuje. Není potřeba vytvářet robustní klienty. Stěžejní výhodou implementace je celková nenáročnost na klienta. Pro provoz klientské části aplikace není nutný ani speciální hardware s grafickou akcelerací. Návrh je rozšiřitelný a snadno adaptovatelný (např. přidáním podpory dalšího formátu modelů). Výsledná aplikace, jak její klientská, tak serverová část může také usnadnit nasazení této technologie v praxi. Představuje vzorovou implementaci, která využívá moderních protokolů, metod a frameworků pro tvorbu komplexní služby s nízkými nároky na klienta. Rovněž může sloužit jako vzorová aplikace s využitím frameworku Kivy, tím podstatně usnadnit nasazení tohoto multiplatformního frameworku v libovolném prostředí, a snížit tak náklady.

59 9 ZÁVĚR 59 9 Závěr Tato práce si kladla za cíl zhodnotit grafické knihovny pro vývoj multiplatformních aplikací v jazyce Python a následně na vybrané knihovně implementovat experimentální aplikaci rozšířené reality. Tento cíl byl splněn v rámci podrobného hodnocení knihoven s přihlédnutím k moderním způsobům ovládání a jejich funkčním možnostem. Pro praktickou implementaci byla zvolena dosud ne příliš rozšířená knihovna Kivy, která umožňuje tvorbu aplikací se stejným kódem pro všechny desktopové i mobilní operační systémy (Windows, OS X, Linux, ios a Android). Splnění požadavků praktické části práce představuje tvorba aplikace pro vzdálené vykreslování 3D objektů. Byla provedena podrobná analýza rozložení jednotlivých prvků grafického rozhraní. Při implementaci se uplatnil moderní protokol REST a asynchronní webový framework twisted. Serverová část komunikuje naprosto průhledným způsobem, který umožňuje tvorbu libovolných klientů. Klientská část představuje praktickou demonstraci možností knihovny Kivy. Tato část aplikace umožňuje rychlou a přehlednou kategorizaci 3D objektů. Aplikace je implementována objektově a její rozšíření či doplnění je díky tomu velice snadné. Na závěr práce lze konstatovat dvě významné skutečnosti. Jednak implementované řešení prakticky ověřilo možnosti knihovny Kivy, která se ukázala jako velice vhodný prostředek pro tvorbu moderních uživatelských rozhraní. Kivy framework je snadno adaptovatelný a umožnil tvorbu přehledného grafického rozhraní. Právě pro realizovaný typ aplikace se Kivy ukázalo být velmi dobrou volbou. Druhou skutečností je, že v rámci realizované experimentální aplikace byla také prozkoumána a prakticky dokázána možnost renderování 3D objektů po síti. Tento druh zpracování je efektivní a umožňuje minimalizovat požadavky na klienta, který rendering 3D modelů požaduje.

60 10 LITERATURA Literatura Apple, Inc. Cocoa - Mac OS X Technologies [online] [cit ]. Dostupný z WWW: < cocoa.html>. Beazley, D. Python Essential Reference. Minneapolis: Addison-Wesley Professional, s. ISBN Blanchette, J., Summerfield, M. C ++ GUI programming with Qt 4.2. Westford: Upper Saddle River: Prentice Hall in association with Trolltech Press, s. ISBN Darcey, L., Conder, S. Android User Interface Design [online] [cit ]. Dostupný z WWW: < android-user-interface-design/>. Digia, Plc. QGesture class reference [online] [cit ]. Dostupný z WWW: < Erens, R. Kivy / python relationship schematic [online] [cit ]. Dostupný z WWW: < Ferrill, P. Pro Android Python with SL4A. New York: Apress, Inc., s. ISBN Fielding, R. T. Fielding dissertation thesis Representational State Transfer (REST) [online] [cit ]. Dostupný z WWW: < uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>. Google, Inc. Android fragments [online] [cit ]. Dostupný z WWW: < GTK+ Team. GTK Features [online] [cit ]. Dostupný z WWW: < Guzman, J., Abrahams, D.. Boost::Python documentation [online] [cit ]. Dostupný z WWW: < libs/python/doc/tutorial/doc/html/python/hello.html>. Hackborn, D.. Multitasking the Android Way [online] [cit ]. Dostupný z WWW: < multitasking-android-way.html>. Juneau, J., Baker, J., Ng, V., Soto, L., Wierzbicki, F. The Definitive Guide to Jython: Python for the Java Platform. New York: Apress, Inc., s. ISBN Kivy community. Kivy framework [online] [cit ]. Dostupný z WWW: <

61 10 LITERATURA 61 Kuchling, A, M. Python Advocacy HOWTO [online] [cit ]. Dostupný z WWW: < Martelli, A., Ravenscroft, A., Ascher, D. Python cookbook. Sebastopol: O Reilly, s. ISBN Mundi, A., Ginsburg, D., Shreiner, D. OpenGL ES 2.0 Programming Guide. Upper Saddle River: Addison-Weasley, s. ISBN Petty, B. About the wxwidgets Project [online] [cit ]. Dostupný z WWW: < Riecken, M. Extending Swing to Run Multi-Touch Applications [online] [cit ]. Dostupný z WWW: < Riverbank computing, ltd. Using SIP [online] [cit ]. Dostupný z WWW: < a-simple-c-example>. Smart, J., Hock, K., Csmor, S. Cross-Platform GUI Programming with wxwidgets. Crawfordsville: Prentice Hall PTR, s. ISBN Struhár, J. Qt Developer Days: jaké bude Qt v rukou firmy Digia? [online] [cit ]. Dostupný z WWW: < SWIG community. SWIG history [online] [cit ]. Dostupný z WWW: < Tidwell, J. Designing interfaces. Bejing: O Reilly, s. ISBN

62 Přílohy

63 A OBSAH CD 63 A Obsah CD Přiložené CD obsahuje veškeré zdrojové soubory aplikace (serveru i klienta). Server je spustitelný z /src/network/threedrenderserver.py, klient z /src/main.py. Obsaženo je také ukázkové video z používání aplikace /src/video_demo_aplikace a ukázkové konfigurační soubory /src/ukazkove_nastaveni_aplikace. / src Backend ProxyObj.py SoLibConnector.py deployscript deployrenderserver.sh deploy.sh errors InvalidProjectXML.py NoServerRunning.py ServerNotReady.py misc project.xsd Models Collection.py ImportPlayground.py Marker.py ModelDB.py Project.py ThreeDModel.py network PyFTThreaded.py RenderServerProtocol.py RenderServerWindow.py ThreeDRenderClient.py ThreeDRenderServer.py UI ArhellButtonBase.py ArhellModelImage.py ArhellProjectTreeViewLabel.py AvailableModelsBox.py CollectionWindow.py DeleteWarning.py DragNDropWidget.py DragableArhellImage.py

64 A OBSAH CD 64 DragableImage.py EditProjectWindow.py ExportWindow.py FileSelectorWindow.py ImportProjectWindow.py InformableWindow.py KivyArhellWidget.py MainWindow.py MarkerInfo.py MarkerSelectorWindow.py MarkersBox.py MenuItemBase.py ModelInfo.py ModelSelectorWindow.py ModelSetupWindowStep1.py ModelSetupWindowStep2.py ModelSetupWindowStep3.py ModelViewWindow.py ModelsWindow.py Museum.py NewCollectionWindow.py NewProjectWindow.py PairedDragableArhellImage.py ProjectWindow.py RenderServerSettingsWindow.py RunSettingsWindow.py SettingsWindow.py TextInputMinSize.py arhellbutton.kv available models box.kv collection detail window.kv collection explorer.kv delete warning.kv export window.kv file selector window.kv mainwindow.kv marker info box.kv model info box.kv model view window.kv model window setup step1.kv model window setup step2.kv model window setup step3.kv models window.kv

65 A OBSAH CD 65 new collection window.kv new project window.kv project window.kv render server settings.kv run settings.kv settings window.kv Main.py Settings.py ThreadQueue.py ukazkove nastaveni aplikace.arhell collections markers markers.xml models models.xml projects server settings.xml video demo aplikace demo.mp4 builds poznamky k testovani.txt MACOS renderserver.app client.app Windows instalacni instrukce windows.txt Linux instalacni instrukce redhat like linux.txt

66 B SCREENSHOTY APLIKACE 66 B Screenshoty aplikace Obrázek 11: Project explorer Obrázek 12: Import projektu (filesystem view)

67 B SCREENSHOTY APLIKACE 67 Obrázek 13: Model explorer Obrázek 14: Párování modelů a markerů (drag n drop)

68 B SCREENSHOTY APLIKACE 68 Obrázek 15: Překreslování modelu a jeho detaily Obrázek 16: Nastavení