Aktualna verzia diplomovej prace - TUKE

Technická univerzita v Košiciach 

Fakulta elektrotechniky a informatiky 

Automatická tvorba skriptovaného GUI s 

využitím umelej inteligencie 

Diplomová práca 

2013 Michal Širochman

Technická univerzita v Košiciach 

Fakulta elektrotechniky a informatiky 

Automatická tvorba skriptovaného GUI s 

využitím umelej inteligencie 

Diplomová práca 

Študijný program: Umelá Inteligencia 

Študijný odbor: 9.2.8 Umelá Inteligencia 

Školiace pracovisko: Katedra Kybernetiky a Umelej Inteligencie (KKUI) 

Školiteľ: Ing. Rudolf Jakša, PhD. 

Konzultant: 

Košice 2013 Michal Širochman

Erráta 

Automatická tvorba skriptovaného GUI s využitím umelej 

inteligencie 

Michal Širochman 

Košice 2013 

Ak je potrebné, autor na tomto mieste opraví chyby, ktoré našiel po vytlačení práce. 

Opravy sa uvádzajú takým písmom, akým je napísaná práca. Ak zistíme chyby až 

po vytlačení a zviazaní práce, napíšeme erráta na samostatný lístok, ktorý vložíme 

na toto miesto. Najlepšie je lístok prilepiť (Katuščák, 1998). 

Forma: 

Strana Riadok Chybne Správne 

12 6 publikácia prezentácia 

22 23 internet intranet

Abstrakt v AJ 

This thesis investigate possibilities of automatic creation of graphical user interface 

via tools of artificial intelligence. Importance of graphical user interface is common 

knowledge, as for developers and administrators who are using more complex soft- 

ware solutions day by day focused mainly on assisting them with their tasks, and as 

for common users which can not know every owned program so thoroughly that they 

could use command prompt, not to mention today multimedial needs of users. They 

need intuitive and simplistic interface so they could input their mostly abstract re- 

quirments for programs. For contemporary large software companies is common to 

have vast design department for graphical user interface, as in general this applies: 

more effective comunication with device I can have, more productive I can become. 

Also, learning curve for user friendly interfaces tends to be smoother, allowing users 

for faster and better accommodation to the new technology. Therefore this thesis’s 

goal is to cover possibilities of potential use cases of artificial intelligence technology 

and obstacles related to them. This applies mainly to a question, whether we are 

capable of creating system that designs graphical user interface in innovative way, 

and to a question of whether we are able to create system that can even remotely 

get close to the quality work of their human counterparts. Throughout the thesis 

we will present kind of wrapper, which creates simplified API to graphical interface 

toolkit suitable for use with means of artificial intelligence, in this case an evolu- 

tionary algorithm, and also suitable for human operator. At the end of the Thesis, 

there will be demonstration of using this API. 

Kľúčové slová v AJ 

Automatic creation of graphical user interface, artificial intelligence 

Abstrakt v SJ

FEI KKUI 

Táto práca skúma možnosť automatickej tvorby grafického užívateľského rozhra- 

nia pomocou prostriedkov umelej inteligencie. Dôležitosť grafického rozhrania je 

všeobecne známa, ako pre vývojárov a administrátorov používajúcich toto rozhranie 

pre manažovanie čoraz komplexnejších systémov určených najmä pomáhať im pri 

ich práci, tak aj pre bežných užívateľov, ktorí nemôžu poznať všetky svoje zakúpené 

programy tak, aby im stačil príkazový riadok, nehovoriac o multimediálnych potre- 

bách dnešných užívateľov. Potrebujú intuitívne a zjednodušené rozhranie, ktoré 

im pomôže vyjaviť programu ich abstraknté požiadavky. Dnes je bežné pre veľké 

softvérové firmy, aby mali rozsiahlé oddelenie zaoberajúce sa návrhom grafického 

užívateľského rozhrania, pretože v princípe platí: čím efektívnejšie sme schopní ko- 

munikovať s daným zariadením, tým sa stávame pri práci s ním produktívnejši. 

Taktiež učiaca krivka na zariadeniach s priateľským užívateľským rozhraním zvykne 

byť plynulejšia a užívateľ sa s danou technológiou skôr stotožní. Preto si táto práca 

dáva za cieľ zistiť možnosti efektívnej implementácie týchto technológií a možné 

prekážky s tým spojené. Týka sa to najmä otázok, či sme schopní zostrojiť systém 

schopný inovatívneho návrhu grafického rozhrania, a či sme schopní zostrojiť as- 

poň systém schopný priblížiť sa kvalite dnešných grafických užívateľských rozhraní 

tvorených človekom. V priebehu práce uvedieme príklad kvázi wrappera, ktorým 

vytvoríme zjednodušené API ku nástrojom grafického prostredia vhodné pre spra- 

covanie prostriedkami umelej inteligencie, v tomto prípade evolučným algoritmom, a 

rovnako použiteľné pre ľudského pracovníka, spolu s ukážkami na záver diplomovej 

práce. 

Kľúčové slová 

Automatická tvorba grafického užívateľského rozhrania, umelá inteligencia 

5

Zadanie práce

Čestné vyhlásenie 

Vyhlasujem, že som diplomovú prácu vypracoval(a) samostatne s použitím uvedenej 

odbornej literatúry. 

Košice, April 29, 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Vlastnoručný podpis

Poďakovanie 

Rád by som vyjadril vďačnosť svojemu školiteľovi Ing. Rudolf Jakša, PhD. za jeho 

podporu a pomoc počas tvorby a písania celej diplomovej práce, a najmä za pomoc 

pri tom, keď som sa zasekol a nevedel ako ďalej. Všetkým ostatným, ktorí prispeli 

nejakou myšlienkov, patrí moje ďakujem.

Contents 

Introduction 1 

1 Úvod do problematiky toolkitov pre tvorbu grafického užívateľského 

rozhrania 2 

1.1 Toolkit wxWidgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Toolkit Qt/KDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3 Toolkit Gtk+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.4 Perl Gtk+ toolkit verzia 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 

2 Umelá inteligencia 11 

2.1 Evolučný Algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3 Systém pre podporu tvorby skriptovaného grafického užívateľského 

rozhrania 17 

3.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.1.1 Výber programovacieho jazyka . . . . . . . . . . . . . . . . . . 18 

3.1.2 Gtk wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.1.3 Návrh AItk API . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.2 Evolučný Algoritmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3.2.1 Štruktúra Jedincov . . . . . . . . . . . . . . . . . . . . . . . . 26 

3.2.2 Priestor Prehľadávania . . . . . . . . . . . . . . . . . . . . . . 28 

3.2.3 Vhodnosť a Výber jedincov . . . . . . . . . . . . . . . . . . . 30 

4 Experimenty 31 

4.1 Použitie „Spinner“widgetu . . . . . . . . . . . . . . . . . . . . . . . . 31 

4.2 Použitie „CheckButton“widgetu . . . . . . . . . . . . . . . . . . . . . 37 

4.3 Evolúcia grafického užívateľského rozhrania . . . . . . . . . . . . . . . 43 

5 Záver 51

FEI KKUI 

Bibliography 53 

Appendices 55 

Appendix A 56 

Appendix B 57 

10

FEI KKUI 

Úvod 

Cieľom tejto práce je navrhnúť a zostrojiť API pre zlepšenie možnosti aplikácie 

umelej inteligencie pri návrhu grafického užívateľského rozhrania. Motiváciou pre 

toto zadanie bola diplomová práca Milana Ilavského (ilavsky, 2011), ktorá sa za- 

oberala interaktívnou evolúciou pri návrhu používateľského rozhrania. V danej práci 

používal, tak ako ďalší ľudia spomínaní v jeho práci, najmä XML, a jeho rozšírená o 

CSS a JavaScript forma XUL. Princípom interaktívnej evolúcie je navrhovať XML 

templaty, ktoré užívateľ ohodnocuje, a postupne privádza algoritmus ku želanému 

výsledku. Zadanie tejto práce spočíva vo vytvorení možnosti pre to, aby sa pri gen- 

erácii GUI použitím prostriedkov umelej inteligencie nemuseli používať nepriame a 

komplikované metódy, ktoré treba šiť na mieru ako v prípade (ilavsky, 2011), ale 

aby bolo možné manipulovať priamo s widgetami toolkitu priamo v programe, ktorý 

ich definuje. Toho je snaha dosiahnuť tak, že zaobaľuje jednotlivé funkcie Gtk+ API 

do malých blokov funkcií, ktoré zjednodušujú ich volanie, nastavujúc prednastavené 

hodnoty a ukladajúc jednotlivé widgety do zoznamu, spolu s ďalšími vlastnosťami, 

podľa ktorých sa algoritmy budú môcť lepšie orientovať pri ich spracovaní. Vlast- 

nostiam ako farba widgetu, pozadia, typ písma a pod., ktorým bolo v práce môjho 

predchodcu venovaná značná časť, budú vynechané ako nepodstatné. Farba a ďalšie 

drobnosti by mali byť nastavované voľbou „témy“, ktorých funkcionalita je bežne 

dostupná v moderných toolkitoch. Dôraz sa bude klásť na funkčnú časť grafického 

užívateľského rozhrania, teda na štruktúru widgetov, a najmä kontajnerov. 

1

FEI KKUI 

1 Úvod do problematiky toolkitov pre tvorbu grafick- 

ého užívateľského rozhrania 

GUI je skratkou pre anglické „Graphical User Interface“, čoho slovenský preklad 

znamená „grafické užívateľské rozhranie“. Jedná sa o rozhranie komunikujúce s uží- 

vateľom pomocou obrázkov namiesto textových príkazov. Informácie sa zobrazujú 

pomocou vizuálnych prvkov a zadávanie inštrukcií zvyčajne prebieha formou ma- 

nipulácie ku tomu dedikovaných vizuálnych komponentov. 

V priebehu rokov vzniklo množstvo systémov implementujúcich GUI, využívajúc 

pri tom rôzne prístupy spracovania informácií ako výstupných, tak aj vstupných 

od užívateľa. Niektoré systémy sú proprietárne, alebo zakomponované priamo do 

aplikácie, ktorej slúžia, iné majú otvorený zdrojový kód. Vo všeobecnosti sa pro- 

gramové vybavenie, umožňujúce tvorbu GUI, nazýva „grafický toolkit“. 

Existuje nepreberné množstvo grafických toolkitov. Niektoré z najrozšítenejších 

zahrňajú Qt, wxWidgets, KDE a Gtk. V princípe každý grafický toolkit používa 

elementy pre zobrazenie obsahu, pričom tie sa zvyknú spájať a reťaziť do kompaktnej 

a ucelenej formy, tvoriac tak výsledný obraz aplikácie. Aplikácia je vykreslená v 

okne, v ktorom sú vykreslené ovládacie prvky ako menu, východ z aplikácie, vykonaj 

činnosť, a podobne. Tieto ovládacie prvky sú však tiež uložené v ďalších malých 

„okienkach“, ktoré sú usporiadané tak, aby každý set ovládacích prvkov bol na 

svojom mieste, aby správy boli vypísané na mieste pre ne určenom, a podobne. 

Všetky tieto elementy sa zhodne volajú „widgety“. 

Okno je napríklad widget, ktorý slúži ako najhraničnejší widget medzi grafickým 

rozhraním poskytovaným pre stolový počítač, a medzi samotnou aplikáciou a ich 

elementami. Tu sa nastavujú vlastnosti ako „stále na vrchu“ alebo „nezobrazuj sa 

v panely otvorených aplikácií“. Avšak také okno akceptuje len jedného potomka, 

len jeden widget, pretože widgety sú štruktúrované pre maximálnu efektivitu kódu 

2

FEI KKUI 

a tvorby prostredia. Do okna sa vloží tabuľka, „box“, alebo iný element, ktorý 

ovplyvňuje výsledné rozloženie aplikácie. Takýto widget akceptuje len technicky 

limitované množstvo potomkov, ale ich usporiadanie je podľa možností daného wid- 

getu nastaviteľné do značnej miery. Kombináciou takýchto widgetov sa dosahuje 

výsledný efekt ako ho väčšinou poznáme, a to menu navrchu, zaberajúce len úzky 

pásik, tlačidlá schované do štruktúr prepínajúc sa záložkami, panel s nástrojmi po 

ľavom boku, a podobne. Až potom nasledujú widgety, do ktorých vieme vložiť 

funkčný kód, implementujúci jednu či druhú funkcionalitu našej aplikácie, ako sú 

tlačidlá, textový vstup, ukladanie práce na disk, a ľubovoľné iné, ktoré aplikácia 

implementuje. 

1.1 Toolkit wxWidgets 

wxWidgets je grafický toolkit s otvoreným zdrojovým kódom. Napísaný je v jazyku 

C++, a prístup ku jeho API je možný pomocou mnohých programovacích jazykov. 

Projekt bol začatý v roku 1992 a v priebehu rokov sa rozrástol na veľmi používaný a 

obľúbený toolkit. Podľa domovskej stránky projektu ?? našiel wxWidgets použitie 

aj v týchto oblastiach: 

Priemysel - geologické modely pre ropný priemysel, software pre tlačiarne, testo- 

vanie nových polovodičových čipov, simulácia a kontrola bezpilotného lietadla, 

grafika a spracovanie audia. 

Výučba a verejný sektor - National Human Genome Reaseach Institute, 3D model 

prehliadač pre biomolekulárne štruktúry, simulácia prechodu rentgenových 

lúčov cez fantómové objekty, interaktívna vizualizácia a analýza 3D lazerových 

snímaní pre archeológov. 

Projekty s otvoreným kódom - existuje nepreberné množstvo verejných projek- 

tov, medzi najznámejšie patria Code::Blocks IDE, FTP klient FileZilla, a 

3

FEI KKUI 

Figure 1 – 1 Ukážka aplikácie používajúcej wxWidgets pre svoje GUI 

Caedium, ktorý simuluje správanie sa plynu alebo kvapaliny v spojitosti s 

rôznymi objektami. 

Individuálne projekty - projekty vedené jednotlivcom alebo malou skupinou ľudí 

s nízkym rozpočtom alebo nedostatkom času sa často obracajú práve na wxWid- 

gets, lebo im dovoľuje vytvoriť aplikácie pre viacero platforiem za relatívne 

malého vynaloženého úsilia. 

Medzi dôležité vlastnosti wxWidgets podľa ich vlastných slov ?? patria aj tieto z 

nich vybrané: 

Cross-platform - možnosť skompilovať ten istý kód pre použitie na viacerých plat- 

formách, umožňujúc sprístupniť program viac užívateľom. 

Otvorený zdrojový kód - môže byť použitý pre iné opensource projekty alebo aj 

pre proprietárne systémy. 

4

FEI KKUI 

Dokumentácia - dôkladne vypracovaná dokumentácia s množstvom príkladov v 

podobe minimalistických aplikácií. 

Tlač - zabudovaná podpora pre tlač na Windowse aj UNIX platformách. 

Debugging - detekovanie pretekania pamäti a jej asociácia s kódom, kde bola 

alokovaná. 

Prekladače - rozsiahla podpora prekladačov, umožňujúca kompiláciu na širokej 

škále platform. 

Drag & Drop - podpora na všetkých platformách. 

Multithreading - dovoľuje programátorovi lepšie využiť výpočtový potenciál mod- 

erných mnoho-jadrových procesorov. 

Taktiež treba spomenúť, že narozdiel od iných toolkitov, ktoré emulujú natívny 

vzhľad na rôznych platformách, wxWidgets v skutočnosti používa abstraktnú vrstvu, 

ktorú prekladá do natívneho toolkitu danej platformy. To spôsobuje priredzenejšie 

vyzerajúcu aplikáciu, častokrát aj zlepšujúc jej výkon oproti toolkitom emulujúcich 

natívny vzhľad. 

1.2 Toolkit Qt/KDE 

KDE toolkit vyšiel prvý krát v roku 1997. Vychádza z Qt frameworku, ktorý posky- 

tuje okrem iného prostriedky pre tvorbu GUI. Je to moderný grafický toolkit, a 

jeden z dvoch najrozšírenejších toolkitov na Linux platforme, po boku s Gtk toolk- 

itom. Je pôvodom z grafického prostredia pre stolové počítače, ktorý sa neskôr 

rozrástol do plnohodnotného projektu s množstvom produktov. Narozdiel od už 

spomínaného wxWidgets, KDE emuluje natívny vzhľad na platformách, nepoužíva 

ich natívne knižnice na viac ako na overenie svojich predpokladov pri vykreslovaní 

5

FEI KKUI 

Figure 1 – 2 Ukážka aplikácie používajúcej Qt pre svoje GUI 

widgetov. Taktiež, KDE nie je cross-kompilovateľný, ale je portovaný na platformy 

mimo Linuxu. Pri jeho komplexnosti to však nie je žiadne prekvapenie. 

Dokáže vytvoriť GUI na základe XML pomocou svojeho XML GUI Builder-u, a 

dokáže vložiť jednu aplikáciu do druhej akoby sa jednalo o widget. Implementuje 

aj aplikačné I/O rozhranie v separátnom procese, umožňujúc tvorbu neblokujúceho 

GUI s prístupom k mnohým protokolom ako napríklad HTTP, FTP, POP, IMAP, 

LDAP alebo proste prístup ku lokálnym súborom, a povoľuje pridať ďalšie pro- 

tokoly, ktoré sa takto stávajú automaticky viditeľné pre všetky aplikácie používa- 

júce KDE. Poskytuje tiež KHTML Rendering Engine, čo v stručnosti znamená, že 

dokáže vykresliť čokoľvek podľa inštrukcií jazykov ako sú javaScript, Java, HTML 

4.0, CSS-2. 

Elementárna architektúra KDE na Linux platforme je zobrazená na obrázku 1 – 3. 

6

FEI KKUI 

Figure 1 – 3 Základná architektúra KDE toolkitu na platforme Linux 

1.3 Toolkit Gtk+ 

Názov Gtk+ nachádza svôj pôvod v názve Gtk - „Gimp Toolkit“, ktorý bol vytvorený 

pre program GIMP. Znak „+“ bol pridaný až neskôr, aby sa zdôraznila nová vylepšená 

verzia. Je dostupný natívne pre Linux, na iných platformách neemuluje natívny 

vzhľad, a je dostupný len ako port. Je na ňom založené jedno z najpopulárnejších 

grafických rozhraní pre stolové počítače používajúce Linux, prostredie „Gnome“. 

Developeri tohoto prostredia teraz pokračujú v údržbe a vylepšovaní Gtk+ toolk- 

itu, ktorý je základom mnohých ďalších aplikácií a dokonca aj ďalších grafických 

rozhraní, zamierených na ďalšie platformy alebo na minimalistický dizajn. Medzi 

najdôležitejšie patria: 

Gnome - Jeden z najobľúbenejších a najrozšírenejších grafických rozhraní pre Linux 

vôbec, spolu už so spomínaným KDE. 

Xfce - zjednodušené rozhranie, zamerané na nájdenie rovnováhy medzi náročnostou 

prostredia a jeho dostupnými funkciami. 

LXDE - jeho cieľom je minimalistické prostredie. 

Sugar - zameraný na interaktívnu výučbu detí. 

7

FEI KKUI 

Figure 1 – 4 Ukážka aplikácie používajúcej Gtk+ pre svoje GUI 

Figure 1 – 5 Základná architektúra KDE toolkitu na platforme Linux (Gtk overview, 2013) 

Gtk+ API je prístupné z asi dvoch tuctoch programovacích jazykov. Dokonca exis- 

tuje aj niekoľko aplikácií zamerané na dizajn GUI, ktoré umožňujú „naklikať“ si wid- 

gety vizuálne. Po dokončení sa vytvorí XML súbor reprezentujúci naše GUI, ktorý 

je možné naťiahnuť do aplikácie pomocou na to určených funkcií v Gtk+. Gtk+ 

narozdiel od niektorých iných prostredí nevyžaduje, aby práve aktívne prostredie 

bolo vytvorené pomocou Gtk+. To znamená, že aplikácia s Gtk+ GUI pôjde bez 

problémov aj v iných rozhraniach, pokiaľ sú nainštalované potrebné knižnice. Toho 

využívajú aj mnohé aplikácie, ktoré si želajú osloviť viac užívateľov sprístupnením 

8

FEI KKUI 

svojich aplikácii pre platformy iné ako Linux. Jediné, čo ku tomu potrebujú, sú 

knižnice, ktoré stačí pribaliť priamo ku programu. Naznámejšie aplikácie založené 

na Gtk+ sú tieto (Gtk+ app, 2013): 

AbiWord - textový procesor. 

Anjuta - integrované vývojové prostredie. 

Chromium - webový prehliadač. 

Firefox - webový prehliadač. 

Ekiga - VoIP a video konferenčná aplikácia. 

Epiphany - oficiálny webový prehliadač prostredia Gnome. 

gconf - nástroj pre konfiguráciu Linux kernelu. 

GIMP - editor rastrovej grafiky. 

GRAMPS - program pre ukladanie genealogických dát. 

Inkscape - editor vektorovej grafiky. 

LiVES - video editor. 

Midori - minimalistický webový prehliadač. 

Pidgin - aplikácia pre „rýchle správy“ (pozn.: z anglického „Instant Messenger“). 

Wireshark - analyzér paketov. 

9

FEI KKUI 

1.4 Perl Gtk+ toolkit verzia 3 

Gtk3 jenázov modulu pre programovací jazyk Perl, ktorý poskytuje prístup ku 

funkciám Gtk+. Kapitola „3.1“ pojednáva o výbere programovacieho jazyka pre 

tento účel, avšak tu je potrebné podoktnúť, že bol vybraný Perl. Je to prepis mod- 

ulu Gtk2 určeného pre predchádzajúcu verziu Gtk+, a sprístupňuje skoro všetky 

funkcionality Gtk knižníc. Tých pár čo chýba sú zvláštneho typu, a pre nápravu 

je potrebné nájsť riešenie v module Glib-Object-Introspection, ktorý dynamicky 

vytvára konekcie ku API funkciám Gtk+, a na ktorom je modul Gtk3 závyslí. S 

použitím tohoto modulu sa vytvorí nový modul, pomenovaný AItk - „Artificial In- 

telligence Toolkit“. 

10

FEI KKUI 

2 Umelá inteligencia 

Umelá inteligencia nemá jednu, univerzálnu definíciu. Z časti za to môže aj fakt, že 

aj samotná „inteligencia“ nemá jednoznačnú definíciu. Odpoveď na otázku „Čo je 

to inteligencia?“ sa úspešne vyhýba odborníkom z oblasti matematiky, psychológie, 

ale aj filozofom všetkých vekov. Niektoré definície inteligencie z rôznych hľadísk 

zahŕňajú: 

∙ Inteligencia je schopnosť získavať a aplikovať vedomosti. Schopnosť myslieť a 

uvažovať. 

∙ Inteligencia je rozumová schopnosť, nadanie, chápavosť. 

∙ Inteligencia je schopnosť úspešne reagovať na ľubovoľnú, najmä novú situáciu 

pomocou odpovedjúcich korekcií správania. Schopnosť chápať súvislosti medzi 

faktami reálneho sveta za účelom vypracovania akcií vedúcich k dosiahnutiu 

vytýčeného cieľa. 

∙ Inteligencia je to čo sa meria v inteligenčných testoch. 

Po dôkladnom zamyslení sa je človek schopný nájsť niektoré paralely, naprílad prvý 

bod tvrdí, že „Inteligencia je schopnosť získavať a aplikovať vedomosti“, čo imp- 

likuje tvrdenie tretieho tvrdenia, že „Inteligencia je schopnosť úspešne reagovať na 

ľubovoľnú, najmä novú situáciu pomocou odpovedjúcich korekcií správania“, a vice 

versa. Posledné tvrdenie zasa reprezentuje všeobecný prístup psychológov ku otázke 

inteligencie. 

Čo však s ostatnými tvrdeniami? Ako zadefinovať napodobeninu niečoho, čo nevieme 

definovať? Najschodnejšie, a samozrejme najvšeobecnejšie, by bolo definíciu „nahradiť“ 

opisom vlastností, ktoré sa snažíme napodobniť. Asi tri najrozšírenejšie definície 

umelej inteligencie sú tieto: 

11

FEI KKUI 

M. Minský - UI je veda o vytváraní strojov alebo systémov, ktoré budú na riešenie 

úloh používať postup, ktorý, ak by ho použil človek, by sme považovali za 

prejav jeho inteligencie. 

Z. Kotek - UI je vlastnosťou človekom umelo vytvoreného systému, vyznačujúceho 

sa schopnosťou rozpoznávať javy, predmety, situácie, analyzovať vzťahy medzi 

nimi a tak vytvárať vnútorné modely sveta a na základe toho robiť účelné 

rozhodnutia, vrátane schopnosti predvídať dôsledky týchto rozhodnutí a schop- 

nosti objavovať nové zákonitosti. 

M. Arbin - UI možno charakterizovať ako snahu programovať počítače tak, aby 

sa chovali spôsobom, ktorý by sme nazvali inteligentným, keby šlo o človeka 

(keby sme nevedeli, že to dokáže aj počítač). 

V ďalšej sekcii sa budeme zaoberať evolučným algoritmom. Prečo práve tomuto 

prístupu a nie inému je vysvetlené v sekcii „Návrh, Evolučný Algoritmus“. 

2.1 Evolučný Algoritmus 

Evolučný algoritmus je nedeterministická metóda riešenia problému, a patrí medzi 

slabé algoritmy. Jedinec je označenie pre reprezentanta bodu v stavovom priestore, 

ktorý plní funkciu nosiča informácie. Jedinec má v sebe zakódované hodnoty jed- 

notlivých „dimenzií“ priestoru prehľadávania, ktoré jednoznačné určujú jeho polohu 

v tomto priestore. Generácia je súbor takýchto jedincov. Všetky jedince jednej 

generácie sa nazývajú populáciou. Evolučný algoritmus podľa pravidiel určených 

jeho implementátorom vyberá najvhodnejších jedincov, ktorých informácie ďalej 

zúžitkuje, a zvyšných jedincov zahodí. Z vybraných jedincov vznikne nová gen- 

erácia, ktorej údel je rovnaký, ako tej predchádzajúcej. 

Silný algoritmus sa vyznačuje vysokým výkonom ale len pre špecifický okruh 

12

FEI KKUI 

úloh, väčšinou sa jedná o konkrétny typ problému, pre ktorý bol navrhnutý. 

Slabý algoritmus je narozdiel od silného algoritmu všeobecný a mal by pokrývať 

široké spektrum úloh, ktoré je schopný riešiť. 

Vo všeobecnosti sa evolučný algoritmus používa vtedy, neexistuje silná metóda pre 

daný problém alebo keď požadovaný výsledok nie je presne špecifikovaný. Jeho 

výhodou sú relatívne dobré výsledky a rýchlosť hľadania suboptimálnych riešení. 

Jeho nevýhodou je častá potreba vytvoriť prekladač, prevádzajúci kandidátov medzi 

priestorom prehľadávania a priestorom kandidátov, a množstvo parametrov algo- 

ritmu, pre ktoré neexistuje žiadny jednoznačný postup, podľa ktorého dôjdeme ku 

optimálnemu nastaveniu parametrov. Všeobecná štruktúra evolučného algoritmu je 

ilustrovaná na obrázku 2 – 1. 

Inicializácia jedincov je začiatok každého evolučného algoritmu. Pokiaľ nemá jed- 

incov, nemá čo evaluovať a ani čo evolvovať. Spôsob inicializácie je veda sama 

o sebe, lebo inicializácia vie ovplyvniť výsledok naozaj výrazným spôsobom. 

Generovanie jedincov môže nadobúdať rôzne formy. Môžeme jedincov gen- 

erovať náhodne, alebo aby rovnomerne pokrývali priestor prehľadávania, 

alebo napríklad použiť heuristiku v prípade, že sú dostupné nejaké infor- 

mácie, ktoré by mohli napomôcť k nájdeniu vhodného kandidáta. 

Evaluácia jedinca je funkcia, alebo súbor funkcií, ktoré sú schopné jednoz- 

načne kvantifikovať vhodnosť jedinca. Je to kritický blok programu, 

ktorý umožňuje evolučnému algoritmu určiť relatívnu vhodnosť jedincov 

medzi sebou. Takto vieme jednoznačne identifikovať najlepšieho jedinca 

z generácie, rovnako ako aj najhoršieho. Pokiaľ sa ohodnotí každý bod 

priestoru prehľadávania, vytvorí sa plocha vhodnosti, kde každý jedinec 

existuje na tejto ploche vhodnosti ako bod. Plocha vhodnosti je často– 

krát „hrboľatá“, tzn. vyskytujú sa na nej údolia a pohoria. Tu je presne 

13

FEI KKUI 

vidno silu inicializácie - pokiaľ napríklad zinicializujem jedincov v lokál- 

nom extréme, tak podľa možností genetických operátorov sa ľahko môže 

stať, že sa generácie „zaseknú“ v tomto lokálnom extréme. Presne kôli 

tomuto existujú metódy, ktoré sa snažia rozprestrieť jedince po väčšej 

ploche, zabraňujú zhlukovaniu jedincov alebo generujú prvú populáciu 

podľa špeciálnych pravidiel tak, aby sa jedince vyskytli v rôznych „kú- 

toch“ tejto plochy vhodnosti. 

Podmienka je najčastejšie obmedzenie, ktoré kladieme na kandidátov, pokiaľ majú 

byť pridaný medzi riešenia. Vyjadrujú isté minimálne požiadavky pre to, 

aby jedinec mohol byť akceptovaný ako riešenie. Menej časté, avšak nemenej 

dôležité je zadefinovať ukončovaciu podmienku ako maximálny počet preskú- 

maných generácii, alebo ako počet generácií, počas ktorých sa nenašiel lepší 

jedinec ako ten, ktorého už máme. Mnoho ukončovacích podmienok zahŕňa 

obe prístupy, keďže evolučný algoritmus generuje generácie nových jedincov 

donekonečna. 

Reprodukcia je blok, v ktorom sa pokúša algoritmus vziať najlepšie vlastnosti 

jedincov aktuálnej generácie, a implementovať ich do novej generáce, aby sa v 

nej vyskytovali lepšie ohodnotení jedinci ako v aktuálnej generácii. 

Selekcia vyberá jedincov, ktorí sa stanú rodičmi nasledujúcej generácie. Výber 

je najčastejšie uskutočnovaný podľa vhodnosti jedincov, a jedinec s lepšou 

vhodnosťou nebude vybraný menej–krát ako jedinec s horšou vhodnosťou. 

Genetické operátory rozhodujú o tom, ako a aké informácie budú z rodičov 

vyextrahované a a ako ich spoja v novom jedincovi. Podľa počtu rodičov, 

ktorých potomkovia potrebujú, poznáme genetické operátory asexuaálne 

(1 rodič), sexuálne (2 rodičia) a panmiktické (2+ rodičov). Najčastejšie 

v praxi vidno použitie mutácie ako asexuálneho operátora, a kríženia ako 

sexuálneho operátora. Mutácia zahŕňa zmenu náhodnej informácie v jed- 

14

FEI KKUI 

incovi, kým kríženie je výmena zodpovedajúcich si segmentov informácií 

medzi rodičmi. 

Evaluácia v tomto bloku je tou istou ako evaluácia v bloku „Inicializácia“. 

Náhrada je proces, ktorý nahradí existujúcu aktuálnu populáciu novou, ktorá sa 

stane aktuálnou populáciou nasledovnej generácie. 

Migrácia je špeciálny blok, ktorý zabezpečuje komunikáciu medzi oddelenými evolučnými 

cyklami, pokiaľ sa uvažuje o viac ako jednom evolučnom cykle pre generáciu. 

Poskytuje možnosť výmeny jedincov medzi týmito samostatne vystupujúcimi 

populáciami. 

t = t + 1 reprezentuje prechod od generácie „t“ ku generácii „t + 1“. 

15

FEI KKUI 

Figure 2 – 1 Všeobecná štruktúra evolučného algoritmu (MACH, 2009) 

16

FEI KKUI 

3 Systém pre podporu tvorby skriptovaného grafick- 

ého užívateľského rozhrania 

V úvode boli uvedené základné pojmy, vzťahujúce sa na danú problematiku, a bolo 

uvedených niekoľko zaujímavých grafických toolkitov, z ktorých je nutné si jeden 

vybrať. Gtk+ toolkit vyšiel ako jednoznačná voľba spomedzi uvedených toolkitov. 

∙ Rozšírenosť Gtk+ vytvorila bohatú komunitu a bude možné dohľadať na in- 

ternete mnoho relevantných materiálov týkajúcich sa vývoja GUI v Gtk+, 

napriek slabšej dokumentácii oproti wxWidgets. 

∙ Nezávisloť od grafického rozhrania bežiacom na operačnom systéme. Stačí 

nainštalovať knižnice a zavolať ich. KDE vyžaduje nainštalované celé prostredie. 

∙ Množstvo programovacích jazykov, ktoré Gtk+ podporuje. 

3.1 API 

Prvou úlohou potrebnou pre splnenie zadania je pripraviť vhodné prostredie pre 

implementáciu prostriedkou umelej inteligencie. Poskytnúť algoritmom umelej in- 

teligencie vhodné abstratkné prostriedky pre manipuláciu aspektov súvisiacich s 

cieľovými atribútami je kľúčové, pokiaľ je cieľom mať možnosť vybudovať pomerne 

ľahko zrozumiteľný a priamočiary program. To zamedzí problémom, ktoré by mo- 

hol spôsobiť prekladač. Pod pojmom „prekladač“ sa bude chápať časť kódu, ktorá 

obsluhuje prevod funkčného kódu do jeho reprezentácie v algoritme a späť. Ako 

príklad môžeme uviesť nereprezentatívne odozvy vzhľadu aplikácie na zásahy, ktoré 

vykoná evolučný algoritmus, alebo problém zakódovať isté požiadavky priamo na 

funkčný kód, čo v podstate znamená, že je potrebné vytvoriť priamo v algoritme 

istý abstrakt, ktorý bude plniť špecificky túto úlohu. Takýmto komplexným blokom 

17

FEI KKUI 

kódu treba zamedzovať, lebo sú menej transparentné, ťažšie sa udržiavajú, sú menej 

flexibilné, a celkovo komplikujú spôsob spracovania nielen evolučným algoritmom, 

ale aj každému inému, ktorý chce prvky GUI reprezentovať abstraktne. 

Tento pohľad nás teda privádza na myšlienku oddeliť kód reprezentujúci vykreslenie 

Gtk3 a kód obstarávajúci zmeny vo vykreslení aplikácie. Bolo by predsa vhodné, 

aby sa nemusel pri každej zmene rozhrania meniť evolučný algoritmus - jediné, čo 

by sa zmenilo, by bolo API, o ktorom by evolučný algoritmus ani nemusel vedieť, 

ako funguje. Takéto API by malo vyzerať ako skript, ktorý sa ľahko číta, a je s časti 

samodokumentujúci. Je potrebné teda naprogramovať prostredníka medzi Gtk3 a 

evolučným algoritmom, nezabúdajúc pri tom na už uvedené vlastnosti, ktoré by mal 

spĺňať. 

1. Abstraktná reprezentácia prvkov Gtk3. 

2. Jednoduchá a čitateľná syntax. 

3. Prednastaviť niektoré vlastnosti Gtk3 tak, aby som musel nastavovať len tie 

parametre, ktoré ma zaujímajú. 

3.1.1 Výber programovacieho jazyka 

V teoretickej časti bolo spomínané Gtk3 ako voľba pre grafické rozhranie našeho 

výberu, avšak Gtk3 je napísané v programovacom jazyku C. To samo o sebe kladie 

na systém, ktorý chceme navrhnúť, vzhľadom na spomínané podmienky uvedené o 

trošku vyššie v sekcii API, niekoľko závažných obmedzení: 

∙ Striktná syntax - C je považovaný za nízko-úrovňový jazyk, no nám treba 

jazyk vyššej úrovne, ktorý nám zabezpečí aj abstraktné potreby pre evolučný 

algoritmus. Vytvorenie modulárneho a ľahko použiteľného API, ktoré bude 

prostredníkom medzi Gtk a evolučným algoritmom, potrebuje taktiež voľnejší 

18

FEI KKUI 

programovací jazyk. 

∙ Zložitosť a časová náročnosť - implementácia API v jazyku C by nám 

nedovoľovala vytvoriť samodokumentujúce API, ktoré by prezentovalo samo 

seba ako skript. Samozrejme, v C jazyku sa dá napísať skoro čokoľvek, ale 

treba si uvážiť, či vynaložená snaha za to naozaj stojí a nepresiahne veľkosťou 

samotnú úlohu, ktorú riešime. 

Vzhľadom na už spomínané požiadavky v API sekcii, tieto vlastnosti jazyka C sú s 

nimi v konflikte. Navyše, pre ich uspokojenie, je potrebné spomenúť ešte niekoľko 

bodov, ktoré je potrebné zohľadniť pri výbere jazyka pre implementáciu API. Tieto 

body sú: 

∙ bind na Gtk C API, 

∙ abstraktnosť, 

∙ modulárnosť, 

∙ tvorba vlastnej syntaxe, 

∙ bohaté programové prostriedky. 

Už prvý bod vymedzuje skupinu programovacích jazykov, z ktorých sa bude vy- 

berať. Podľa oficiálnej dokumentácie(gtk lang bind, 2013) Gtk+ projekt podporuje 

v aktuálnej verzii 3.6 bindy pre nižšie uvedené programovacie jazyky, s vynechaním 

pre Gtk+ natívneho C. 

C++ je rozšírenie jazyka C o triedy/objekty a ďalšie vylepšenia. Nevhodný pre 

striktnú syntax. 

Java je na tom podobne ako C, striktná syntax a objektovo orientovaný jazyk nie 

je vyhovujúci. 

19

FEI KKUI 

Python je interpretovaný, avšak ďalší natívne objektovo orientovaný jazyk. 

Javascript vychádza z jazyku Java, ten istý problém. 

Vala je opäť objektovo orientovaný jazyk, ktorý navyše prevádza svoj zdrojový kód 

do jazyka C a až z toho sa vykompiluje finálny program. 

Perl je moderný jazyk z množstvom funkcií jazykov vyššej úrovne, je interpretovaný 

a teda pôsobí ako skriptovací jazyk, poskytuje možnosť vytvorenia funkcií 

správajúcich sa podobne ako natívne zabudované funkcie, a poskytuje veľmi 

rozsiahlu databázu balíkov s rozšíreniami o dodatočné prostriedky, za čo môže 

aj jeho modulárnosť 

Pascal má opäť striktnú syntax a slabú modularitu. 

Lua bol navrhnutý ako minimalistický skriptovací jazyk s rozšíriteľnou sémantikou. 

Nie je až taký populárny ako C, Java, Python či Perl a neposkytuje prostriedky 

moderných jazykov vyššej úrovne. 

Haskell je funckionálny programovací jazyk, voľnou sémantikou a statickým typo- 

vaním. Hlavným programovacím prostriedkom je funkcia, avšak od skriptu a 

samodokumentácie má pomerne ďaleko. 

FreeBASIC trpý tým istým ako Pascal. 

D je modernizovaný a redizajnovaný C++ jazyk, nevhodný pre striktnú syntax. 

Z vyššie uvedených programovacích jazykov sa ukazuje ako najlepší kandidát Perl. 

Objektovo orientované jazyky boli vyradené najmä kôli striktnej syntaxy, ktorá sa 

spája s implementovaním tried a metód. 

20

FEI KKUI 

3.1.2 Gtk wrapper 

Perl používa ako rozhranie ku Gtk3+ API modul Gtk3. Tento modul povoľuje 

programovať v API veľmi podobnom originálnemu Gtk API, avšak perlovským spô- 

sobom. Je závislý na niekoľkých ďalších moduloch - hlavný komponent je modul 

Glib-Object-Introspection. Tento modul dynamicky vytvára konekcie z knižníc 

do Perl rozhrania, vytvárajúc tak možnosť volať originálne funkcie priamo z Gtk 

knižníc. Narozdiel od wrapperov sa takýto systém ľahšie udržiava a zmena v Gtk 

knižnici sa prenesie priamo do Perlu, bez potreby zaktualizovať modul. Tu prichádza 

na rad Gtk3 modul, ktorý je vo svojej podstate wrapper, sprístupňujúci toto pre- 

nesené API z Gtk knižnice a dopĺňa funkcie na pripájanie kódu, upravuje niek- 

toré názvy funkcií a rieši pár ďalších menších nepríjemností, ktoré môžu nastať pri 

takomto dynamickom bindovaní API knižnice. Ukázalo sa to ako veľmi efektívny 

spôsob, najmä pri vypustení novej verzie Gtk3. Pokiaľ v Gtk3 module ma menilo len 

zopár vecí, a dokonca väčšina bola skopírovaná z Gtk2 modulu, tak v Glib-Object- 

Introspection sa nemenilo nič v spojení s novou verziou Gtk. 

Modulárnosť je jedna z podmienok vytýčených pre tento modul. V princípe sa mod- 

ulárnosť bude chápať ako rozčlenenie funkcionality do blokov elementárnych funkcií, 

ktorých logickým prepojením sa dosiahne výsledný efekt totožný s tým, ktorý by 

nastal v prípade implementácie ako jedného celku. Tomuto účelu poslúži nový perl 

modul, ktorého názov je AItk.pm. Skratka „pm“ pochádza z „perl module“, a 

„AItk“ je obmenou Gtk, teda namiesto „Gnome toolkit“ znie plný názov „Artificial 

Intelligence toolkit“. 

3.1.3 Návrh AItk API 

Gtk3 ako moderný toolkit poskytuje množstvo prostriedkov pre tvorbu grafického 

užívateľského rozhrania. V rámci implementácie vlastnej API je potrebné každú z 

21

FEI KKUI 

týchto funkcií previesť zvlášť do novej formy pomocnými funkciami. To znamená, že 

každej Gtk3 funkcii prináleží aspoň jedna funkcia nového API, ktorá ju zaobaľuje, 

dopĺňa o prednastavené hodnoty niektorých atribútov a zjednodušuje prístup ku 

nej. Samozrejme, pre potreby výskumu možnosti uplatnenia prostriedkov umelej 

inteligencie netreba mať plnú implementáciu, stačí dostatočne početná množina na- 

jčastejšie používaných widgetov. 

Pre lepšie pochopenie je uvedený skrátený list implementovaných widgetov a niek- 

torých vybraných funkcií s ich krátkym popisom. 

GtkWindow je jeden z hlavných widgetov. Jedná sa o kontajner, ktorý akceptuje 

jedného potomka. 

GtkBox predstavuje widget, ktorý akceptuje ľubovoľný počet widgetov ako svojich 

potomkov, zoradiac ich do jednej rady. GtkBox môže byť vertikálny alebo 

horizontálny, čo zodpovedá tomu, ktorým smerom budú jeho potomkovia zo- 

radení. 

GtkGrid je náhradou GtkTable, ktorá je od verzie Gtk3 zastaralá a neodporúča 

sa jej použitie v nových aplikáciach. Jedná sa o kvázi „raster“, ktorý ak- 

ceptuje widgety nastaviteľných pomerných rozmerov do voliteľných slotov. 

Zjednodušene je to variabilná tabuľka, ktorej widgety avšak nie sú limitované 

veľkosťou jednotlivej bunky, jednotlivý potomkovia sa umiestňujú relatívne je- 

den k druhému, narozdiel od absolútneho umiestnenia v tabuľke. To znamená, 

že pokiaľ je potrebné vykonať zmenu rozloženia widgetov v Gride, nemusím 

prepísať celé rozloženie, ako v prípade tabuľky. 

GtkDrawingArea je widget, ktorý povoľuje vykreslenie grafiky pomocou GDK a 

Cairo na svoju plochu. V praxi sa väčšinou používa na vloženie obrázku zo 

súboru. 

GtkButton je asi najdôležitejší widget. Skoro každá aplikácia má nejakú formu 

22

FEI KKUI 

tlačidla, minimálne na potvrdenie vstupu. 

GtkCheckButton je implementáciou zaškrtávacích políčok. 

GtkEntry je textový vstup pre užívateľa. 

GtkLabel slúži ako menovka. Niektoré widgety ho používajú pre ich pomenovanie 

v aplikácií, alebo ako spôsob výpisu správ užívateľovi. 

GtkSeparator je presne to čo znie, separátor. Môže byť horizontálny alebo ver- 

tikálny. Vykresľuje „čiaru“ v rozpätí relevantnej dimenzie widgetu. 

add() je generickou funkciou na pridávanie potomkou widgetom. 

remove() je rovnako ako add() generickou funkciou, avšak odoberá potomkov widgetom. 

reparent() je funkciou implementujúcou reparent funkciu widget triedy, slúži na 

premiestnenie potomka z jedného widgetu do druhého. 

expand() je ďalšou funkciou, ktorá zjednodušuje prístup ku atribútom widget 

triedy. Dovoľuje nastavit horizontálnu aj vertikálnu expanziu widgetu, ktorá 

nastáva, ak dostane widget od jeho rodiča viac priestoru (napríklad rozšírením 

dimenzie okna). Prednastavená hodnota nepovoľuje expanziu, teda viac mi- 

esta dostupného pre widget by znamenalo len rožšírenie nepoužitej plochy. 

homogeneous() funkcia zabezpečuje rovnomerné rozloženie priestoru medzi všetky 

potomky widgetu. Gtk implementuje túto funkciu pre GtkBox a GtkGrid 

spomedzi tu zmienených widgetov. 

signal() funkcia je jednou z najdôležitejších. Spája widget s funkčným kódom, 

ktorý sa má vykonať pri aktivácii widgetu. 

Z uvedeného listu sa poskladá jednoduché GUI spôsobom, aký je uvedený na obrázku 

3 – 1.Do GtkWindow sa vloží GtkBox v horizontálnej orientácii pomocou funkcie 

23

FEI KKUI 

add(). Ten istý postup platí aj pri vkladaní widgetov „W1“ a „W2“ do GtkBox. Za 

predpokladu, že widget W1 má plniť funkciu tlačidla „OK“, a widget W2 funkciu 

tlačidla „CANCEL“, pripojíme widgetom pomocou funkcie signal() kód reprezentu- 

júci im prislúchajúcu funkcionalitu, spolu s typom signálu, ktorý ma spustiť volanie 

kódu. Pod typom signálu môžeme rozumieť napríklad pri stlačení tlačidla, jeho 

pustení, a pod. 

Figure 3 – 1 Ukážka tvorby jednoduchého GUI použitím niekoľkých kľúčových funkcií 

Pokiaľ by sa skladalo toto jednoduché ukážkové GUI podľa pravidiel originálneho 

Perl modulu pre Gtk, museli by sme s jednotlyvými widgetami pracovať ako s ob- 

jektami, a všetky funkcie, ktoré sa na nich vzťahujú, sú vlastne metódami im pris- 

luchajúcich tried. Nežiadúce správanie. 

Prototypy v jazyku Perl povoľujú programátorovi zvoliť si, aké vstupy pre danú 

funkciu očakáva. Takýto zápis funkcie taktiež umožnuje volať funkciu rovnakým spô- 

sobom, ako built-in funkciu. To poskytuje priestor pre prispôsobenie každej funkcie 

tak, aby povoľovala skrátené volanie pre tvorbu widgetov, pripájanie signálov, pred- 

nastavovania hodnôt priamo pri tvorbe widgetu, a ďalších pomôcok, ktoré šikovný 

programátor vymyslý pre uľahčenie svojej ale aj užívateľovej práce. Takto sa pretvo- 

24

FEI KKUI 

ria aj jednotlivé metódy na funkcie asociované ich triedam. Každá funkcia má 

vlastný zoznam prednastavených hodnôt, ktoré aplikuje pri tvorbe nového Gtk ob- 

jektu. Tieto prednastavené hodnoty je možné modifikovať či už podsunutím argu- 

mentov volanej funkcii, alebo neskôr volaním funkcie reprezentujúcou danú metódu. 

Bohužial, takýto prístup je náchylný na zmenu prístupných modifikácii objektov v 

Gtk. To znamená, že keď nová verzia Gtk odstráni metódu, ktorú používame, alebo 

zmení spôsob, akým funguje, je nutné zmeniť v AItk module kód prináležiaci týmto 

zmeneným prvkom. 

Ďalšou doplňenou funkcionalitou do AItk je možnosť zadefinovať „triedu“ widgetov. 

Každý widget môže patriť do inej triedy, podľa toho akú funkciu plní. Používa 

sa to najmä pre widgety ako sú tlačidlá, zaškrtávacie políčka, a podobne, a nie 

pre kontajnery. Dôvodom je zoskupenie tlačidiel podľa toho, akú úlohu v aplikácii 

zastávajú. Pôvodný plán bol zhlukovať jednotlivé funkcie aplikácie podľa ich názvov, 

a tak poskladať GUI, ktorý má navzájom relevantné tlačidlá pokope, avšak nakoniec 

z toho vyplynula dostatočne zložitá úloha na samostatnú prácu. Pokiaľ nie je zadaná 

trieda, priradí sa widgetu prednastavená. Dôležitosť tejto funkcionality je obrovská 

pre evolúciu, pretože množstvo nezaradených listových widgetov by zahltil evolučný 

algoritmus a drasticky znížil jeho výkon. 

3.2 Evolučný Algoritmus 

Teória evolučného algoritmu bola vysvetlená v teoretickej časti tejto diplomovej 

práce. Prečo však evolučný algoritmus? V kontexte tejto práce je zapotreby pro- 

gram, ktorý je schopný ohodnotiť štruktúru widgetov a rozhodnúť sa, či je aktuálne 

riešenie dostatočné. Tento program by mal spĺňať nasledovné požiadavky: 

Reprezentácia dát je dôležitou súčasťou každého algoritmu. Ideálne by mala byť 

reprezentácia čo najjednoduchšia a intuitívna, keďže spôsob reprezentácie a 

25

FEI KKUI 

jej odlišnosť od reálneho modelu ovplvňuje zásadným spôsobom funkciu, a 

dokonca aj samotnú existenciu, prekladača. 

Prekladač je vrstva medzi reálnymi dátami, ktoré je potrebné spracovať, a medzi 

dátami transformovanými tak, aby dotyčný program týmto dátam porozumel 

a vedel s nimi pracovať. Čím je zložitejší prekladač, tým je väčšia šanca, že 

nechtiac orežeme priestor prehľadávania o možnosti, a tým pomalšie algoritmus 

pobeží. 

Rýchlosť programu je v tomto prípade signifikantná podmienka pre výber vhod- 

ného prostriedku z repertoára umelej inteligencie. Ako si neskôr ukážeme, 

priestor prehľadávania nelineárne narastá s počtom zadefinovaných tried, ktoré 

potrebujem zaradiť do aplikácie. 

Inkrementálnosť nie je kľúčová, ale rozhodne sa hodí, keď chceme začat z miesta, 

kde posledný pokus prestal. 

Evolučný algoritmus bol podľa týchto požiadaviek jednoznačný výber. Každý jedinec 

bude môcť byť samostatne ohodnotený ako prípustný a neprípustný a podľa toho 

aj posunutý ďalej alebo vyradený. Taktiež obmena riešenia je veľmi jednoducho 

realizovateľná. 

3.2.1 Štruktúra Jedincov 

Každý jedinec populácie je typu Tree::Simple, ktorý poskytuje perl modul ako 

jednoduchú implementáciu n-árneho stromu. V podstate sa jedná o objekt, ktorý v 

obsahuje vlastnosti daného uzla, jeho obsah, a zároveň odkazy na svojich potomkov. 

Strom je vhodná údajová štruktúra pre reprezentáciu objektov Gtk3 a pre evolúciu 

hned pre niekoľko dôvodov: 

26

FEI KKUI 

1. Logická následnosť - samotný Gtk toolkit skladá svoje widgety ako strom. 

Ako koreň si môžeme predstaviť widget GtkWindow, jeho potomok bude Gtk- 

Box, a jeho potomkovia budu zase GtkButton, čo budú jeho listové uzly. 

2. Názornosť reprezentácie - strom bude reprezentovať Gtk widgety presne 

1:1, čo umožnuje použiť jedinca ako manuál pre vyskladanie GUI. Stačí si prečí- 

tať strom zhora dole a z jednej strany na druhú (funguje to zrkadlovo, nezáleží 

či sa postupuje zľava doprava alebo naopak), a máme vytvorené rozhranie 

pripravené na zobrazenie. 

3. Implicitne jednoduché genetické operátory - jediný dôvod, prečo je 

potrebné zmeniť štruktúru stromu je len ten, keď sa rozdelujú alebo spájajú 

listové uzly. Zmena sa vykoná proste prepísaním hodnoty daného uzla. 

Pre praktické dôvody bol počet uzlov obmedzený takým spôsobom, aby každý uzol 

musel byť najďalej 2 uzly od listového uzlu. Toto obmedzenie bolo zavedené preto, 

aby sa nestalo, že sa jednotlivé uzly budu kombinovať niekoľkonásobne bez možnosti 

zaplniť včetky svoje voľné „sloty“, vytvárajúc mnoho „mŕtveho“, nevyužitého mi- 

esta, alebo proti hromadeniu sa uzlov na jednu kopu. Navyše to odľahčuje mutáciu 

a netreba aplikovať korekčné funkcie pre jedince každu generáciu, čo zvyšuje výkon 

a efektivitu generovania riešení. 

Listové widgety sú rozdelené podľa ich „triedy“. Každá trieda widgetov dostane 

jedného rodiča, teda jeden kontajner. pre jednoduchosť sa tieto triedy nedelia medzi 

viac rodičov. Ich poradie je nešpecifikované a evolučný algoritmus ho neevolvuje. 

prvky jednej triedy hadzem do jedneho kontajnera, kontajner musi mat aspon je- 

den dalsi kontajner co ma listove uzly alebo mat sam listovy uzol, implementovane 

kontajnery: grid, box, notebook implementovane widgety: button, spin, checkbox, 

... 

27

FEI KKUI 

3.2.2 Priestor Prehľadávania 

Priestor prehľadávania zavisí na počte prvkov, ktoré je potrebné zaradiť do GUI. 

Čím viac grafických prvkov a tried ktorým prináležia bude zadefinovaných, tým 

viac kombinácií a tým väčší priestor treba prehľadať. Povedzme, že potrebujeme do 

okna aplikácie pridať 2 tlačidlá jednej triedy. Jedinec môže vyzerať aj tak ako je 

vyobrazený na obrázku 3 – 2. 

Figure 3 – 2 Jednoduchý jedinec s dvomi tlačidlami 

Celkom jednoduchá štruktúra, v rámci jedinca môžeme zameniť len kontajner „Box H“ 

za iný, v podstate nemá zmysel robiť evolúciu. Pokiaľ by sme brali do úvahy len 

kontajner typu Box, tak máme na výber z 2 možností: Box H a Box V. Avšak 

povedzme, že máme 2 triedy prvkov, a každá trieda má po 4 prvky. Jedinec môže 

nadobudnúť rôzne formy, ako vidíme na niekoľkých obrázkoch 3 – 3. 

28

FEI KKUI 

Figure 3 – 3 Možnné kombinácie horizontálnych a vertikálnych boxov pri statických listových 

uzloch. 

29

FEI KKUI 

Stačilo mať dve triedy na to, aby možnosti len pri implementácii jedného konta- 

jneru vzrástli z dvoch na šesť, a to bez ohľadu na počet prvkov v triedach widgetov. 

Čo sa stane pri viac triedach? Povedzme že máme päť tried widgetov. Každej z 

nich podľa pravidiel bude priradený jeden kontajner. Tieto kontajnery budú ďalej 

považované za okrajové. Všetky tieto „okrajové“ kontajnery môžu byť potomkami 

jedného rodiča, alebo každý môže mať vlastného rodiča, dokonca rodič jedného okra- 

jového kontajnera može byť ďalší okrajový kontajner. Existujú desiatky možnosti 

pre usporiadanie kontajnerov. Vynásobené počtom permutácií, a počtom rôznych 

kontajnerov, dostávame tisíce možností, ktoré tvoria priestor prehľadávania. Výber 

evolučného algoritmu je teda jednoznačný, aj za cenu suboptimálneho výsledku, 

pre jeho relatívnu rýchlosť v porovnaní s úplnými algoritmamy, ktoré prehľadávajú 

priestor systematicky celý. Bežné aplikácie obsahujú omnoho viac ako smiešnych 

päť „tried“ tlačidiel, kontajnery nie sú obmedzené v reťazení, a celkovo obsahujú 

viac komponentov. Pri takejto úlohe by nebol problém len prehľadať celý priestor, 

ale aj vybrať najvhodnejšie riešenie. 

3.2.3 Vhodnosť a Výber jedincov 

bol plan robit zhlukovanie na prvkoch GUI, podla ich nazvu, ale nevydalo = trebalo 

slovník, korene slov, co ak sa volaju 2 tlacitka s roznou ulohou rovnako? nutnost 

poznat kontext... falllback to class 

30

FEI KKUI 

4 Experimenty 

Táto kapitola je venovaná ukážkam schopností AItk, sústreďujúc sa na zjednoduše- 

nie volania funkcií, účinnosť novej syntaxe a tvorbe lepšie zrozuminetľného kódu. 

Jedná sa o malé ukážky, ktoré sa venujú špecifickému widgetu a jeho implemen- 

tácii v tradičnom Perl Gtk3 module, porovnávajúc ho s novým AItk modulom. 

Pre reprezentáciu jeho užitočnosti pri aplikácii prostriedkov umelej inteligencie je 

posledná podkapitola venovaná vytvoreniu grafického užívateľského rozhrania po- 

mocou AItk a evolučného algoritmu. 

4.1 Použitie „Spinner“ widgetu 

Spinner je widget vyobrazujúci animáciu točenia. Častokrát sa používa namiesto 

progress baru, reprezentujúc aktivitu s nejasným časom ukončenia. Tento kód 

ukazuje, ako vyzerá implementácia widgetu Spinner spolu s prepínacím tlačidlom, 

ktoré ho štartuje a zastavuje. 

#!/usr/bin/perl 

use strict; 

use warnings; 

use Gtk3 ’-init’; 

my $window = Gtk3::Window->new (’toplevel’); 

$window->set_title ("Spinner Example"); 

$window->set_border_width (5); 

$window->signal_connect (’destroy’, sub { Gtk3->main_quit }); 

$window->set_default_size (250, 100); 

31

FEI KKUI 

my $vbox = Gtk3::Box->new("vertical", 5); 

$window->add ($vbox); 

my $spinner = Gtk3::Spinner->new; 

my $toggle1 = Gtk3::ToggleButton->new_with_label(’Spin’); 

$toggle1->set_active (0); 

$toggle1->signal_connect ( toggled => \&toggled ); 

$vbox->pack_start ($spinner, 1, 1, 5 ); 

$vbox->pack_start ($toggle1, 1, 1, 5 ); 

$window->show_all; 

Gtk3->main; 

sub toggled { 

} 

my ($widget, $data) = @_; 

if ( $widget->get_active == 1 ) { 

$spinner->start; 

$toggle1->set_label ("Stop"); 

} else { 

} 

$spinner->stop; 

$toggle1->set_label ("Spin"); 

return 0; 

exit 0; 

32

FEI KKUI 

Dohromady 39 riadkov, kód vyzerá ako klasický objektovo orientovaný kód. Pre 

vytvorenie objektu sa zavolá jedna metóda, pre nastavenie vlastností sa použijú 

ďalšie metódy, jedna vlastnosť po jednej metóde. Programátor je donútený štruk- 

túrovať svoj kód striktne. Nie veľmi Perlovský spôsob :). Taktiež sa veľmi nehodí 

pre užívateľa, ktorý nechce investovať čas do Gtk+ toolkitu ešte naviac, oberajúc 

ho o čas, ktorý mohol stráviť programovaním svojej aplikácie. Ťažko si je pred- 

staviť aj ako by mala vyzerať implementácia umelej inteligencie pre účely automat- 

ickej tvorby GUI pri takto napísanom kóde. Ako vyzerá implementácia Spinnera s 

použitím AItk? 


use strict; 

use warnings; 

use AItk qw(:basic); 

window my $window, ’Spinner Example’; 

size $window, 250, 100; 

box my $vbox, "vertical", 5; 

add $window, $vbox; 

spinner my $spinner; 

toggle my $toggle1, ’Spin’, \&toggled; 

pack $vbox, $spinner, $toggle1; 

main_loop $window; 

33

FEI KKUI 

sub toggled { 

} 


if ( get_active $widget == 1 ) { 

start $spinner; 

set_label $toggle1, "Stop"; 

} else { 

} 

stop $spinner; 

set_label $toggle1, "Spin"; 

return 0; 

exit 0; 

Z 39 riadkov nám ostalo 32, pričom ak by sa rátali len riadky týkajúce sa Gtk3 a 

AItk, dostali by sme pomer 16:9, keďže sa vo funkcii nič neušetrilo, ale zato v tele 

programu sa toho ušetrilo pomerne dosť. Výsledné GUI vytvorené programami je 

vyobrazené na tomto obrázku 4 – 3. 

Najviac bolo ušetrené na tvorbe widgete „Window“ 4 – 1, kde sa zadal želaný ná- 

zov okna rovno do volania pre jeho tvorbu 4 – 2. Atribút „toplevel“ je jeden z dvoch 

možných, ktoré tento widget akceptuje. Tým druhým je „popup“, avšak skoro každé 

okno je vytvárané ako „toplevel“, preto je táto hodnota prednastavená. Taktiež, v 

budúcnosti sa plánuje implementovať funkciu „popup“, aby sa vedel tento typ okna 

vytvárať priamo a rozlíšiteľne od okna typu „toplevel“. Prednastavené je aj ohraniče- 

nie okna v šírke 5 pixelov, a funkcia ukončujúca program pri stlačení krížika na 

okne. V prípade tvorby aplikácie s viac aktívnymi oknami je potrebné prepísať túto 

funkciou podľa potreby inou, ktorá len zavrie okno, ale neskončí program. Veľkosť 

okna pokrýva funkcia „size“4 – 2, ktorú je možné aplikovať aj na ďalšie widgety. 

34

FEI KKUI 


$window->set_title ("Spinner Example"); 




Figure 4 – 1 Definícia okna pomocou Perl Gtk3 modulu. 

window my $window, ’Spinner Example’; 


Figure 4 – 2 Definícia okna pomocou AItk modulu. 

Figure 4 – 3 Naľavo je GUI vyobrazené pomocou Perl Gtk3 modulu, vpravo je použitý AItk 

toolkit. Oba výsledky sú totožné. 

V porovnaní tvorby toggle tlačidla 4 – 4 4 – 5 je vidno silu AItk syntaxe. Funkcie 

vytvárajúce tlačidlá sú programované tak, aby boli schpné prijať variabilný počet 

argumentov. Môžeme definovať tlačidlo aj bez mena a funkcie, lebo jediný povinný 

argument je premenná, do ktorej bude widget uložený. V tomto prípade definu- 

jeme v jednom riadku na začiatku programu neaktívne toggle tlačidlo s aktivovanou 

funkciou „toggled“. 

my $toggle1 = Gtk3::ToggleButton->new_with_label(’Spin’); 

$toggle1->set_active (0); 

$toggle1->signal_connect ( toggled => \&toggled ); 

Figure 4 – 4 Definícia neaktivovaného toggle tlačidla s pripojenou funkciou pomocou Perl Gtk3 

modulu. 

35

FEI KKUI 

toggle my $toggle1, ’Spin’, \&toggled; 

Figure 4 – 5 Definícia neaktivovaného toggle tlačidla s pripojenou funkciou pomocou Perl AItk 

modulu. 

Aktivovať a deaktivovať tlačidlo sa dá jednoducho pomocou funkcií „active“ a „in- 

active“, ako to bude ukázané v ďalšej podkapitole. Typ signálu aktivujúci funkciu 

je prednastavený na „toggle“, lebo to je väčšinou to, čo po tlačidle užívateľ očakáva. 

36

FEI KKUI 

4.2 Použitie „CheckButton“ widgetu 

Widget „CheckButton“ sa používa pre funkcie, ktoré môžu mať dve stavy. Jedná sa 

o štvorček, ktorý je buď prázdny s hodnotou FALSE, alebo je vyplnený a reprezen- 

tuje hodnotu TRUE. Pomocou nich môžeme prepínať rôzne ovládacie prvky GUI 

alebo aj meniť funkcionalitu samotného programu. Určite je zaškrtávacie políčko, 

čí súhlasím s podmienkami užívania softvéru, všetkým dobre známe. Nižšie je kód 

implementujúci CheckButton pomocou Perl Gtk3 modulu. 


use strict; 

use warnings; 

use Gtk3 ’-init’; 


$window->set_title ("Basic Check Boxes"); 




my $vbox = Gtk3::Box->new ("vertical", 5); 

$window->add ($vbox); 

my $entry = Gtk3::Entry->new; 

$entry->set_text ("Hello World"); 

$vbox->pack_start ($entry, 1, 1, 0); 

my $hbox = Gtk3::Box->new ("horizontal", 6); 

37

FEI KKUI 

$vbox->pack_start ($hbox, 1, 1, 0); 

my $checkbox1 = Gtk3::CheckButton->new_with_label (’Editable’); 

$checkbox1->signal_connect (toggled => \&toggle_checkbox, "editable"); 

$checkbox1->set_active (1); 

$hbox->pack_start ($checkbox1, 1, 1, 0); 

my $checkbox2 = Gtk3::CheckButton->new_with_label ("Visible"); 

$checkbox2->signal_connect (toggled => \&toggle_checkbox, "visible"); 



my $checkbox3 = Gtk3::CheckButton->new_with_label ("Icon"); 

$checkbox3->signal_connect (toggled => \&toggle_checkbox, "icon"); 



$window->show_all; 

Gtk3->main; 

sub toggle_checkbox { 


my $value = $widget->get_active; 

if ($data eq ’visible’) { 

$entry->set_visibility ($value); 

} elsif ($data eq ’editable’) { 

$entry->set_editable ($value); 

} elsif ($data eq ’icon’) { 

38

FEI KKUI 

} 

} 

my $stock_id = undef; 

if ($value == 1) { 

} 

$stock_id = Gtk3::STOCK_FIND; 

$entry->set_icon_from_stock (’secondary’, $stock_id); 

return 0; 

exit 0; 

Počet riadkov implementácie Gtk::CheckButton pomocou Perl Gtk3 modulu dosia- 

hol 59, a opäť je ukážkou syntakticky striktného objektovane orientovaného kódu. 

ďalšia ukážka kódu je implementácia widgetu CheckButton pomocou AItk toolkitu. 


use strict; 

use warnings; 

use AItk qw(:basic); 

window my $window, "Basic Check Boxes"; 


box my $vbox, "vertical", 5; 

add $window, $vbox; 

entry my $entry, "Hello World"; 

box my $hbox, "horizontal", 6; 

pack $vbox, $entry, $hbox; 

39

FEI KKUI 

checkbox my $checkbox1, "Editable", \&toggle_checkbox, "editable"; 

checkbox my $checkbox2, "Visible", \&toggle_checkbox, "visible"; 

checkbox my $checkbox3, "Icon", \&toggle_checkbox, "icon"; 

active $checkbox1, $checkbox2; 

inactive $checkbox3; 

pack $hbox, $checkbox1, $checkbox2, $checkbox3; 

main_loop $window; 

sub toggle_checkbox { 

} 


my $value = get_active $widget; 

if ($data eq ’visible’) { 

$entry->set_visibility ($value); 

} elsif ($data eq ’editable’) { 

$entry->set_editable ($value); 

} elsif ($data eq ’icon’) { 

} 

my $stock_id = undef; 

if ($value == 1) { 

} 

$stock_id = Gtk3::STOCK_FIND; 

$entry->set_icon_from_stock (’secondary’, $stock_id); 

return 0; 

40

FEI KKUI 

exit 0; 

Pomocou AItk zabrala implementácia 46 riadkov, čo je oproti celkom 59 slušné. 

Opäť rátajúc len riadky týkajúce sa Perl Gtk3 a AItk, dostávame pomer 26:14. 

To je prakticky skrátenie o polovicu. Funkciu obstarávajúcu prepínanie vlastností 

widgetov sa veľmi skrátiť nepodarilo, ale to je očakávateľné, keďže vo funkcii očaká- 

vame manipuláciu konkrétneho widgetu konkrétnym spôsobom, narozdiel od tela 

programu, kde sa využíva syntax spájaním viacerých úloh do jedného volania. 

my $checkbox1 = Gtk3::CheckButton->new_with_label (’Editable’); 

$checkbox1->signal_connect (toggled => \&toggle_checkbox, "editable"); 



my $checkbox2 = Gtk3::CheckButton->new_with_label ("Visible"); 

$checkbox2->signal_connect (toggled => \&toggle_checkbox, "visible"); 



my $checkbox3 = Gtk3::CheckButton->new_with_label ("Icon"); 

$checkbox3->signal_connect (toggled => \&toggle_checkbox, "icon"); 



Figure 4 – 6 Definícia troch CheckButton widgetov spolu s priradením funkcionality, 

TRUE/FALSE stavu, a pridaním do vertikálneho checkboxu použitím Perl Gtk3 modulu. 

Hlavný rozdiel je zásluhou definície widgetov CheckButton 4 – 6, ktoré AItk zápis 

4 – 7 skrátil nesmierne. Okrem možnosti zadefinovať úplný button v jednom volaní 

funkcie, ako to bolo vysvetlené v predchádzajúcej podkapitole, sa o to zaslúžila aj 

funkcia „pack“. Tá umožňuje priradiť ľubovoľné množstvo widgetov kontajneru typu 

41

FEI KKUI 

Box. Rozhodnutie, či použije metódu „pack_start“ alebo „pack_end“, spočíva v 

umiestnení widgetu vo volaní funkcie. Všetky widgety až po prvý prázdny argument 

budú spracované metódou „pack_start“, ostatné metódou „pack_end“. 

checkbox my $checkbox1, "Editable", \&toggle_checkbox, "editable"; 

checkbox my $checkbox2, "Visible", \&toggle_checkbox, "visible"; 

checkbox my $checkbox3, "Icon", \&toggle_checkbox, "icon"; 

active $checkbox1, $checkbox2; 

inactive $checkbox3; 

pack $hbox, $checkbox1, $checkbox2, $checkbox3; 

Figure 4 – 7 Definícia troch CheckButton widgetov rovnako ako v kóde vyobrazenom na 4 – 6, 

avšak použitím AItk modulu. 

Figure 4 – 8 Naľavo je GUI vyobrazené pomocou Perl Gtk3 modulu, vpravo je použitý AItk 

toolkit. AItk má kúsok siršie okno, spôsobené prednastavenou hodnotou padding pri packovaní 

widgetov do boxu. Originálny kód si zaťiadal padding „0“ pixelov, avšak prednastavená hodnota 

AItk je „5“ pixelov 

Výsledok obidvoch implementácií je totožný, až na padding checkboxov v boxe, 

kde si Perl Gtk3 pýta pri pack_start metóde padding 0 pixelov, avšak AItk má 

prednastavenú hodnotu 5 pixelov. Celková efektivita AItk z pohľadu pohodlnosti, 

prístupnosti a najmä počet ušetrených riadkov je tesno spätá s komplexnosťou im- 

plementácie GUI a početnosti widgetov. 

42

FEI KKUI 

4.3 Evolúcia grafického užívateľského rozhrania 

Pre účel overenia vhodnosti AItk pri implementácii prostriedkov umelej inteligencie 

bol aplikovaný principiálne nie zložitý evolučný algoritmus, ktorý mal nájsť vhodné 

rozloženie grafického užívateľského rozhrania. Bola použitá mutácia kontajnerov 

a ich typov, a funkciu vhodnosti reprezentoval súčet „x“ a „y“ rozmerov okna, 

pričom sa hľadalo minimum tejto funkcie. To spôsobí, že budú preferované jedince 

bližšie tvaru štvorca, a teda kompaktnejšie. Reprezentácia jedincov ako aj gentoyp 

sú uvedené v kapitole číslo 3. Inicializácia jedinca prebieha vygenerovaním stromu 

použitím užívateľom definovaných widgetov spojených s rodičmi, ktorí obsahujú kon- 

tajner. Kontajner je zatial len textová reprezentácia jeho typu, skutočný sa vytvorí 

až neskôr pomocou funkcie, ktorá prekladá tento text do widgetov a následne system- 

aticky pospája celý strom. Na tomto obrázku 4 – 9 je príklad čerstvo vygenerovaného 

jedinca. 

Figure 4 – 9 Príklad vygenerovaného jedinca evolučného algoritmu. Veľmi jasne vidno množstvo 

nedostatočne využitej plochy, ako aj nadmerné naťahovanie jednotlivých widgetov. 

43

FEI KKUI 

Ako selekčný mechanizmus je použité orezanie , ktoré odstráni horšiu polovicu a 

nahradí ju lepšou polovicou, ktorú následne zmutuje. Elitizmus zachováva lepšiu 

polovicu generácie nedotknutú, teda sa nemôže stať, že sa zníži vhodnosť najlepších 

jedincov. Môže jedine stagnovať, alebo stúpať. Povolené kontajnery boli len ver- 

tikálny a horizontálny box. Grid bol použitý ako potomok pre okno, a ako kontajner 

pre všetky ďalšie widgety, ktoré sa potrebujú zaradiť do okna. 

Parametre evolúcie zahŕňali populáciu o veľkosti 100. Počet generácií bol stanovený 

na 5 a šanca pre mutáciu kontajnera 30%. Oproti inicializovanému jedincovi, evolú- 

cia dokázala zlepšiť výzor a účelnosť jedincov aj napriek primitívnej funkcii vhod- 

nosti a slabej mutácii, ktorá nemala povolené premiestňovať podstromy medzi sebou 

a meniť ich štruktúru. 

Medzi najzaujímavejšie výsledky sa prepracoval jedinec vyobrazený na obrázku 4 – 

10. Funkcionalita reprezentovaná tlačidlami sa nachádza oddelená zvislou menu 

lištou od textu. Veľmi podobný výsledok je vyobrazený na obrázku 4 – 11 s rozdielom 

jedného panela, ktorý je umiestnený pod textovou plochou, vytvárajúc a trochu 

kompaktnejší vzhľad. 

Iný typ jedinca, uznaného ako najlepšieho svojej poslednej generácie, je zobrazený 

na obrázku 4 – 12. Tento jedinec je podlhovastého kompaktného tvaru, s relatívne 

dobre rozloženou plochou. 

Posledný typ jedinca sa nachádza na obrázku 4 – 13. Tento jedinec má prakticky 

tradičné rozloženie GUI podľa dnešného štandartu, teda tlačidlá sa nachádzajú ro- 

zložene pri dvoch krajoch okna. Rozdielom je použitie dolného okraja oproti bežne 

používanému hornému okraju, a pozícia menu lišty, ktorá plní učel delimitera medzi 

textom a panelom. 

Vo všeobecnosti sú tieto výsledky nedostatočné pre generáciu reálneho GUI, čo bolo 

spôsobené najmä veľmi obmedzenými možnosťami genetických operátorov a funkcie 

44

FEI KKUI 

Figure 4 – 10 Rozloženie GUI s použitím menu ličty ako predelom medzi textovou časťou a časťou 

s tlačidlami. 

Figure 4 – 11 Podobne ako 4 – 10, avšak jeden panel nástrojov je vložený pod textovú časť. 

vhodnosti. Mutácia bola do naozaj značnej časti závislá od vygenerovaného jedinca, 

keďže nemala povolené meniť štruktúru stromu. Jednoducho povedané, mutáciu 

45

FEI KKUI 

Figure 4 – 12 Zvislo orientované okno aj spolu s tlačidlami, pripomína minimalistickú aplikáciu 

pre písanie básničiek. 

46

FEI KKUI 

Figure 4 – 13 Takmer tradičné rozloženie tlačidiel po dvoch krajoch okna, avšak menu lišta našla 

svoje miesto ako predel medzi tlačidlami a plochou venovanej textu. 

sa snažila len „doklepnúť“ jedinca na čo najlepšiu úroveň vhodnosti, ale vhodnosť 

jedinca bola do značnej miery určená už pri jeho vygenerovaní. 

Navyše funkcia vhodnosti závisela len od vonkajčích rozmerov okna, a nebrala do 

úvahy vnútorné rozloženie widgetov a ich efektívne umiestnenie v priestore, čo malo 

za následok prílišnú veľkosť tlačidiel, ako je vidno na niektorých obrázkoch. 

Použitím metódy „add“ namiesto „pack_start“, alebo zrušením atribútov „expand“ 

a „fill“ pri použití „pack_start“, sa však dá tomuto rozťahovaniu widgetov zamedziť. 

47

FEI KKUI 

Na obrázkoch 4 – 14 4 – 15 4 – 16 sú znázornené rozloženia widgetov použitím tejto 

drobnej úpravy v algoritme. Zlepšenie vidno hneď na prvý pohľad, avšak miestami 

zanechávajú widgety nevyužitú plochu, keďže nie sú nastavené, aby ju vypĺňali, ako 

pri predchádzajúcich pokusoch. 

Figure 4 – 14 Po vypnutí expanzie a vypĺňania sa okamžite prejavili neželané následky. Na druhú 

stranu, tlačidlá vyzerajú prirodzenejšie. 

Pôvodne bolo zamýšlané aj zhlukovanie tlačidiel podľa ich názvov, ale to sa ukázalo 

ako téma na ďalšiu prácu. Taký systém by musel rozumieť čo daný názov reprezen- 

tuje v plnom kontexte, čo nie je žiadna sranda. Dve tlačidlá s rovnakým názvom 

by ho veľmi ľahko mohli popliesť, a keď už musím pridávať doplňujúcu informáciu 

v podobe kontextu, prečo by som rovno ich nezaradil do triedy sám, že. 

48

FEI KKUI 

Figure 4 – 15 Toto rozloženie tlačidiel v tvare „U“ je celkom príjemne pôsobiace, aj keď umiest- 

nenie menu lišty v hornom pravom rohu je kúsok neprirodzené. 

49

FEI KKUI 

Figure 4 – 16 Ďalšie rozloženie tlačidiel v tvare „U“, tentokrát však pôsobí omnoho elegantnejšie 

a kompaktne. Prázdne miesto v dolnom pravom rohu okna nepôsobí rušivo, a menu lišta je uložená 

na veľmi vhodnom mieste. 

50

FEI KKUI 

5 Záver 

Po vykonaní experimentov sa ukázalo, že AItk toolkit pre podporu tvorby skripto- 

vaného grafického užívateľského rozhrania je naozaj tým, čím si dalo za cieľ byť. 

Odstraňuje prísnu syntax, zlepšuje čitateľnosť kódu a v neposlednom rade šetrí 

námahu a čas užívateľov tým, že umožňuje skrátiť zápis GUI o štvrtinu až polovicu. 

Tieto vymoženosti slúžia najmä dobru implementácie umelej inteligencie do procesov 

návrhu GUI, kde im poskytujúmožnosť jednoduchšej a kompaktnejšej implementá- 

cie. Referované práce sa doteraz snažili zmeňiť vzhľad aplikácie až po tom, ako bola 

poskladaná, a to úpravou CSS alebo XML kódu, ktorým mohli ovládať niektoré 

widgety a ich vlastnosti. AItk toolkit umožňuje priamo vygenerovať grafické uží- 

vateľské rozhranie použitím užívateľom definovaných widgetov, čo predstavuje istý 

pokrok od obmieňania poradia widgetov v kontajnery a ich farby pomocou CSS a 

XML. 

Bohužial, dizajn AItk zapĺňa menný priestor programu exportovaním množstva 

funkcií, ktoré užívateľovi poskytuje. Odporúčaná implementácia spočíva v zabalení 

volania AItk a jeho použitia do jedného bloku kódu, dedikovaného práve tvorbe GUI. 

Takýmto spôsobom je možné bezpečne definovať funkcie vo svojom kóde, a naviazať 

ich na widgety v zaobalenom kóde implementujúcom GUI. Pri výskyte totožného 

mena funkcie si však treba uložiť jej referenciu do premennej, lebo po zavolaní AItk 

bude predefinovaná počas trvania bloku. Elegantným spôsobom by bolo definovať 

skaláry obsahujúce odkaz na rovnomenné funkcie, ktoré by sme použili v AItk bloku. 

Ďalšia skutočnosť je rozsah AItk, ktorý nie je dostatočný. AItk implementuje 

niekoľko desiatok widgetov a metód, avšak to pri tvorbe reálnej aplikácie stále nes- 

tačí. Okrem iného potrebuje pridať niekoľko dôležitých vlastností pre widgety, ktoré 

si zaznačuje do svojho zoznamu. Zatial je tam len jeho trieda, typ, a okno, do 

ktorého patrí. V prípade box widgetu by sa napríklad hodilo mať vlastnosť „orien- 

tácia“, alebo „expanzia“, a určite sa najde mnoho ďalších atribútov, ktoré umožnia 

51

FEI KKUI 

prostriedkom umelej inteligencie náležito pracovať so zadefinovanými widgetami. 

Trebalo by implementovať aj spôsob, ktorý by globálne diktoval niektoré prednas- 

tavené hodnoty niektorých funkcií, pre lepšiu prispôsobiteľnosť konkrétnej aplikácii. 

AItk by mohlo aj poskytovať nejaké základné prostriedky umelej inteligencie ako 

pomoc programátorovi, ktoré by mu urýchlili a skvalitnili prácu. 

Myslím si, že AItk by prospelo použitie reálnym projektom, pri ktorom by mo- 

hol autor doplniť niektoré chýbajúce funkcie, a rozhodne by sa AItk dalo lepšie 

implementovať so skúsenosťou z návrhu GUI pre nejakú aplikáciu. Ukázalo by to 

jednoznačne, ktoré dizajnové rysy sú dostatočné, a ktoré treba pridať alebo prerobiť. 

52

FEI KKUI 

References 

wxWidgets Who uses wxWidgets? http://www.wxwidgets.org/about/whouses. 

htm 2013 

wxWidgets wxWidgets Features http://www.wxwidgets.org/about/feature2. 

htm 2013 

Gtk+ project Language Bindings http://www.gtk.org/language-bindings.php 

2013 

Wikipedia, The Free Encyclopedia GTK+ https://en.wikipedia.org/wiki/GTK+ 

2013 

Gtk+ project Overview of GTK+ and its Libraries http://www.gtk.org/ 

overview.php 2013 

MACH, M. 2009. Evolutionary algorithms: elements and principles. Košice : Elfa, 

2009, 250 s. ISBN 978-80-8086-123-0, pp. K 12 

Ilavský, M. 2011. Interaktívna evolúcia grafického používateľského rozhrania v toolkite 

GTK+. Diplomová práca 

BARANČOK, D. et al. 1995. The effect of semiconductor surface treatment on LB 

film/Si interface. In: Physica Status Solidi (a), ISSN 0031-8965, 1995, vol. 108, 

no. 2, pp. K 87–90 

GONDA, V. 2001. Ako napísať a úspešne obhájiť diplomovú prácu. Bratislava : Elita, 

2001, 3. doplnené a prepracované vydanie, 120 s. ISBN 80-8044-075-1 

Jadrová fyzika a technika: Terminologický výkladový slovník. 2. rev. vyd. Bratislava : 

ALFA, 1985. 235 s. ISBN 80-8256-030-5 

53

FEI KKUI 

KATUŠČÁK, D. 1998. Ako písať vysokoškolské a kvalifikačné práce. Bratislava : 

Stimul, 1998, 2. doplnené vydanie. 121 s. ISBN 80-85697-82-3 

LAMOŠ, F. – POTOCKÝ, R. 1989. Pravdepodobnosť a matematická štatistika. 

1. vyd. Bratislava : Alfa, 1989. 344 s. ISBN 80-8046-020-5 

REJTHAROVÁ, V. – SKÁLOVÁ, E. 1981. Příručka anglického odborného stylu. 

Praha : Academia, 1981, 220 s. 

SÝKORA, F. a iní. 1980. Telesná výchova a šport. 1.vyd. Bratislava : SPN, 1980. 

35 s. ISBN 80-8046-020-5 

STEINEROVÁ, J. 2000. Základy filozofie človeka v knižničnej a informačnej vede. 

In: Kimlička, Š., Knižničná a informačná veda na prahu informačnej spoločnosti. 

Bratislava : Stimul, 2000. ISBN 80-2274-035-2, s. 327–334 

ŠUMICHRAST, Ľ. 1995. On the performance of higher approximations of radia- 

tion boundary conditions for the simulation of wave propagation in structures of 

integrated optics. In: Photonics ’95. Prague : CTU, 1995, pp. 159–161 

54

Zoznam príloh 

Príloha A Prílohy 

Príloha B Bibliografické odkazy 

Príloha C Vytvorenie zoznamu skratiek a symbolov 

Príloha D

FEI KKUI 

Príloha B 

Bibliografické odkazy 

Táto časť záverečnej práce je povinná. V zozname použitej literatúry sa uvádzajú 

odkazy podľa normy STN ISO 690–2 (01 0197) (Informácie a dokumentácia. Bib- 

liografické citácie. Časť 2: Elektronické dokumenty alebo ich časti, dátum vydania 

1. 12. 2001, ICS: 01.140.20). Odkazy sa môžu týkať knižných, časopiseckých a iných 

zdrojov informácií (zborníky z konferencií, patentové dokumenty, normy, odporúča- 

nia, kvalifikačné práce, osobná korešpondencia a rukopisy, odkazy cez sprostredku- 

júci zdroj, elektronické publikácie), ktoré boli v záverečnej práci použité. 

Forma citácií sa zabezpečuje niektorou z metód, opísaných v norme STN ISO 690, 

1998, s. 21. Podrobnejšie informácie nájdete na stránke http://www.tuke.sk/anta/ 

v záložke Výsledky práce/Prehľad normy pre publikovanie STN ISO 690 a STN ISO 690-2. 

Existujú dva hlavné spôsoby citovania v texte. 

∙ Citovanie podľa mena a dátumu. 

∙ Citovanie podľa odkazového čísla. 

Preferovanou metódou citovania v texte vysokoškolskej a kvalifikačnej práce je podľa 

normy ISO 7144 citovanie podľa mena a dátumu (Katuščák, 1998; Gonda, 2001). 

V tomto prípade sa zoznam použitej literatúry upraví tak, že za meno sa pridá rok 

vydania. Na uľahčenie vyhľadávania citácií sa zoznam vytvára v abecednom poradí 

autorov. 

Príklad: . . . podľa (Steinerová, 2000) je táto metóda dostatočne rozpracovaná na to, 

aby mohla byť všeobecne používaná v . . . 

Druhý spôsob uvedenia odkazu na použitú literatúru je uvedenie len čísla tohto 

57

FEI KKUI 

zdroja v hranatých zátvorkách bez mena autora (autorov) najčastejšie na konci 

príslušnej vety alebo odstavca. 

Príklad: . . . podľa [13] je táto metóda dostatočne rozpracovaná na to, aby mohla 

byť všeobecne používaná v . . . ako je uvedené v [14]. 

Citácie sú spojené s bibliografickým odkazom poradovým číslom v tvare indexu alebo 

čísla v hranatých zátvorkách. Odkazy v zozname na konci práce budú usporiadané 

podľa týchto poradových čísel. Viacero citácií toho istého diela bude mať rovnaké 

číslo. Odporúča sa usporiadať jednotlivé položky v poradí citovania alebo podľa 

abecedy. 

Rôzne spôsoby odkazov je možné dosiahnuť zmenou voľby v balíku natbib: 

% Citovanie podla mena autora a roku 

\usepackage[]{natbib}\citestyle{chicago} 

% Možnosť rôznych štýlov citácií. Príklady sú uvedené 

% v preambule súboru natbib.sty. 

% Napr. štýly chicago, egs, pass, anngeo, nlinproc produkujú 

% odkaz v tvare (Jones, 1961; Baker, 1952). V prípade, keď 

% neuvedieme štýl citácie (vynecháme \citestyle{}) v "options" 

% balíka natbib zapíšeme voľbu "colon". 

Keď zapneme voľbu numbers, prepneme sa do režimu citovania podľa odkazového 

čísla. 

% Metoda ciselnych citacii 

\usepackage[numbers]{natbib} 

Pri zápise odkazov sa používajú nasledujúce pravidlá: 

V odkaze na knižnú publikáciu (pozri príklad zoznamov na konci tejto časti): 

58

FEI KKUI 

∙ Uvádzame jedno, dve alebo tri prvé mená oddelené pomlčkou, ostatné vynecháme 

a namiesto nich napíšeme skratku et al. alebo a i. 

∙ Podnázov sa môže zapísať vtedy, ak to uľahčí identifikáciu dokumentu. Od 

názvu sa oddeľuje dvojbodkou a medzerou. 

∙ Dlhý názov sa môže skrátiť v prípade, ak sa tým nestratí podstatná informá- 

cia. Nikdy sa neskracuje začiatok názvu. Všetky vynechávky treba označiť 

znamienkami vypustenia „. . . “ 

Pri využívaní informácií z elektronických dokumentov treba dodržiavať tieto zásady: 

∙ uprednostňujeme autorizované súbory solídnych služieb a systémov, 

∙ zaznamenáme dostatok informácií o súbore tak, aby ho bolo opäť možné vy- 

hľadať, 

∙ urobíme si kópiu použitého prameňa v elektronickej alebo papierovej forme, 

∙ za verifikovateľnosť informácií zodpovedá autor, ktorý sa na ne odvoláva. 

Pre zápis elektronických dokumentov platia tie isté pravidlá, ako pre zápis „klasick- 

ých“. Navyše treba uviesť tieto údaje: 

∙ druh nosiča [online], [CD-ROM], [disketa], [magnetická páska] 

∙ dátum citovania (len pre online dokumenty) 

∙ dostupnosť (len pre online dokumenty) 

Poradie prvkov odkazu je nasledovné: Autor. Názov. In Názov primárneho zdroja: 

Podnázov. [Druh nosiča]. Editor. Vydanie alebo verzia. Miesto vydania : Vyda- 

vateľ, dátum vydania. [Dátum citovania]. Poznámky. Dostupnosť. ISBN alebo 

ISSN. 

59

Aktualna verzia diplomovej prace - TUKE

Create successful ePaper yourself

Delete template?

Save as template?