Revolučné GUI.

2.6.2005 10:34 | Přečteno: 1170× | nápady | poslední úprava: 17.8.2005 07:31

Programátori sa často hrajkajú s GUI. Viem to, lebo aj ja som to robil, kým som robil pod X-i. To je však zlý prístup - GUI netreba navrhovať. Užívateľ si ho neskôr može jednoducho a rýchlo navrhnúť sám.

Základom všetkých GUI toolkitov a builderov, ktore som videl je presný návrh rozloženia. Zadefinujeme si okno, do neho správcov rozloženia a rôzne kontaineri a potom tlačidla a ...

Teraz mám iný návrh. Postup tvorby frontend vrstvy bude rovanaký. Definujeme pre vstupy akcie, ktore narabajú so vstupnymi dátami. Stalačenie tlačidla -> doClickedOK(), písanie do inputboxu -> regenerateTitle(char*)

Tu sa treba zastaviť. Naša aplikacia vie robiť všetko čo treba, len užívateľ nevie akcie vyvojať. My však pre užívateľa nenamodelujeme GUI, ale definujeme vlastnosti, ktoré musia ovládacie prvky mať, aby ich vedel užívateľ použiť.

Takze povieme [prvok, ktory vie explicitne vyvolať doClicked()], [prvok, ktorý vie primať ľubovoľný text a pri zmene textu volá regenerateTitle()].

Ďalej však treba definovať skupiny prvkov, dôležitosť prvkov v skupine, priradzovať popisy, atď. Nás proste nezaujíma, ako bude aplikačné GUI vyzerať. To nech rozhodne GUI engine podľa nejakých desktop-enviromentálnych šablôn. Hlavne aby vedel volať naše akcie so správnymi dátami.

Mňa teraz nezaujíma, či by popis bol v externom súbore v špecialnom formáte, alebo by sa narábalo s funkciami, objektami, atď.

Plynie z toho jedna významná výhoda. Užívateľ by dostal možnosť meniť, cele rozloženie GUI a GUI ako také. Niektoré prvky by fungovali rovnako dobre ako combobox, aj ako radio-button, ako na jednom okne, tak na inom okne, ak sa užívateľovi nepáči, zmení. Dôležitá je však úspora casu.

UPDATE: Oprava tagu <code> na </code>, pardon.

       

Komentáře

[nobody]

Cim menej ma uzivatel moznost volby, alebo zmeny, tym lepsie.

[Yin]

Oprava: nie užívateľ, ale Linuxák (kcontrol, gnome-control-center, atď. Sa tým dajako neriadia)

[VícNežNic]

Ale normální člověk si takový software nikdy nepořídí, protože se ho nemůže z příručky naučit nazpaměť.

[Yin]

Jak by nie. V GUI-engine môžu byť štandardizované šablóny a ich zmena predvolene zakázaná. V príručke budú štandardizované sreenshoty. Ale nechaj tak, je to experiment.

[orin]

Teda - mozno mi nieco uslo, ale nie je to proste obycajne oddelenie GUI od aplikacie ? To sa predsa uz bezne robi (napr. mozilla/firefox)

Ja pouzivam gtk-glade. User interface mam nadesignovany v .glade suboroch (xml format) a v kode mam len (no "takmer len" ) odvolavky na pomenovane prvky gui. Tie glade subory moze uzivatel pokojne editovat pomocou glade-2. Neviem ale o tom, ze by sa o to niekto pokusil, asi o tom ani skoro nikto spomedzi tych par sto uzivatelov nevie...

[unchallenger]

Problém je, že bez toho, abys musel měnit i kód, můžeš dělat v GUI v podstatě jen triviální (izomorfní) změny. Zajímavé změny vyžadují změnu chování, aplikační logiky, a tu v .glade souboru neuděláš.

[Yin]

Lenže stále povieš 'Tlačidlo', nie 'Niečo, čo pošle jeden signál'. niekomu vadí rozloženie tlačidial v Gnome, niekomu rodielnosť GUI toolkitov a ich stále zmeny (ext. link).

Preto ja chcem vytvoriť len popis prianí na GUI. Ten sa dá prehnať nejakým AI (rule engine, fuzzy logik). (Napríklad!)

[orin]

Aha - takze chces dalsiu medzivrstvu abstrakcie medzi aplikaciou a interface?

V najjednoduchsom pripade by to bol akysi wraper, ktory by prerabal GUI-kniznice (alebo zmienenu AI) na jednotny interface.

Keby sa to malo odflaktnut, mohli by sa pouzit obycajne shared libraries, inac by nebola zla nejaka komponentova architektura (CORBA, XPCOM, ... ?), pripadne RPC.

Este by sa to dalo chapat ako rozdelenie programu na server (aplikaciu) a

a) hodne univerzalneho klienta schopneho spolupracovat s roznymi aplikaciami (vytvarat pre ne GUI) - to uz dost pripomina browser a webove aplikacie

b) specializovanych klientov (napr. AI) - napr. skript vyuzivajuci webovu aplikaciu (bash + wget )

Je tu filozoficky problem - spolupraca s GUI (alebo niecim inym) nie je jednoducha. - Bud ju spravis tak aby vedela "vsetko" a bude tym padom zlozita a bude obsahovat podobne konstrukcie ako volania nejakeho GUI API - Alebo spravis nejaku uroven abstrakcie - bude to prehladnejsie, jednoduchsie, ale nutne obmedzene co do funkcnosti.

[Yin]

Dobrý postreh! Ale nechcel som hneď rozmýšlať 'ako to imlementovať', alebo 'ako to bude fungovať', chcem len _rozmýšlať_...

Takto by mohol vyzerať externy format:

[recommended] 'Gnome dialog template';
[komponents] 'but' {
  [send-signal] 'OK';
  [send-signal] 'Cancel';
  [send-signal] 'Wait';
}
[komponents] {
  [store-text][on-change-signal] 'message';
  [return-index][dynamic] 'category combo';
}
[group][linear please] {
  [safe] 'but'.'Wait';
  [unsafe][default] 'but'.'OK';
  [unsafe] 'but'.'Cancel';
}
[group] {
  'category combo' [note] 'Vyberte si kategoriu';
  [default] 'message' [note] 'Sem zapíšte text';
}
[signals] {
  'but'.'OK'.[send-signal] = 'doOK()';
  'but'.'Cancel'.[send-signel] = 'doCancel()';
  'but'.'Wait'.[send-signal] = 'doWait()';

  'message'.[on-change-signal] = 'updateTitle()';
}

Takto kod v C:

GUI_dialog* d;

void initGUI(char** loaded_kategories) {
  d = GUI_load("gui.conf");
  GUI_dynamicData(d, "category combo", loaded_kategories);
  GUI_makeActual(d);
}

void doOK() {
  server_send(GUI_get(d, "message"));
}

void updateTitle() {
  if(is_well_formed(GUI_get(d, "message"))) {
    printf("recipient will be happy!\n");
  } else {
    printf("recipient will be unhappy!\n");
  }
}

Vsimnite si, ze v externom formate o rozlozeni nehovorim, len odporucam, skupinky a sablonu. V kode sa z inicializaciou a obsluhou GUI nehram.

Ale to nieje dolezite!

[orin]

Ok, rozmyslam rad

Teda - nie ze by som vsetkemu rozumel... Skusim napisat, ako som to pochopil:

[recommend] doporucuje vseobecny mechanizmus, ktorym sa ma vyrobyt GUI z doporuceni
[komponents] definuju casti GUI - formulare a dialogy,
[group] urcuje layout
[signals] signal binding

Povedal by som, ze by bolo uzitocne oddelit tieto veci:

- definiciu interface aplikacie - (na to sa bezne pouziva IDL)

- rozlozenie gui (analogia k html alebo xml) a jeho napojenie na aplikaciu

- styl/tema/skin (analogia k css)

GUI prostredie potrebuje vsetky tri veci, zatial co napr. tie AI skripty len tu prvu.

Taketo rozdelenie je obvykle. Mozno blizsie k tomu co navrhujes by bolo nedefinovat rozlozenie gui, ale len pomenovat prvky gui a ich prepojenie na aplikaciu a potom nadefinovat samotne gui, ktore by sa odvolavalo na tieto pomenovane prvky.

Priklad:

- mam funkciu "doOK()": void doOK();
- Na jej obsluhu potrebujem button, pomenujem ho "OKbutton":
Button OKbutton
bind OKbutton.clicked -> doOK()
- Mam formular 1 obsahujuci OKbutton
<form name="formular_1">
<button name="OKbutton" label="OK"/>
<button name="Cancelbutton"/>
</form>
- Mam styl pripadne obsahujuci lokalizovane retazce:
button.OKbutton {color:red;}
button.Cancelbutton {label:"Zrus";}

[Yin]

Dobre, postupujes logicky! Lenze definujes vzhlad. Ja chcem len funkcnost. Zabudni na moje 1-urovnove [vsetko]. Ponechaj v popise len obsahy oboch [komponents] a zostane:

[send-signal] 'ok';
[send-signal] 'cancel';
[send-signal] 'wait';
[store-text][on-change-signal] 'text' [note] 'Vyberte si kategoriu';
[return-index][dynamic] 'category' [note] 'Sem zapíšte text';

send-signal vysle signal, ked si ho uzivatel vyberie. engine vzycajne vyberie tlacidlo.
store-text drzi text od uzivatela zvycajne inputbox.
return-index vrati index vyberu radio-buttony, combobox
dynamic obsah urci app. (definovane polozky, alebo rozsahy...)
...

Nikdy nepoviem [button], alebo farba, tento v lavo, tento v pravo. Ja chcem totiz usporit cas a sekundarne definovat dost abstraktny model na to, zby sa dal pouzit v GTK, QT, NCurses, ale aj konzole!

Nechcem hovorit o farbe, velkosti, polohe. Len o tom ako som ja schopny prijmat signaly a data, nech sa user, ako to chce. Podme na to __abstraktne.

Mozno by sme sa mohli o tom viacej pobavit, ak by s chcel... a mozno rozsirit nejaky uz funkcny projekt/vlastny projekt...

[orin]

Privela abstrakcie skodi. (ale to len tak naokraj) A u tych platforiem si este zabudol na html, wap a hlavne na komunikaciu esemeskami

Teda na konzolu (ak mas na mysli nieco na sposob "Proceed ? [Y/n] :", tak na to by som sa uz asi fakt vykaslal... Zmysel to ale mozno predsa len ma - pre postihnutych (napr. nevidiacich). SWING v jave by vraj mal byt schopny nejak tymto stylom komunikovat (pomocou hlasoveho rozhrania), ale nikdy som to nevidel.

To co si napisal hore je v podstate deklaracia signalov s nenapadnymi doplnkami (napr. [note]), ktore na jednej strane pomahaju vyrobit gui, ale na strane druhej na skutocne zobrazenie gui nestacia (a to je predpokladam pointa).

Ako to gui teda vlastne vznikne ? Vytvori ho na zaklade hintov nejaky genialny algoritmus ? Alebo bude definovane v dalsom subore ?

V praxi asi oboje - pocas vyvoja aplikacie sa vykasles na GUI a nechas automatiku, nech nejake vyrobi. A ked uz ides odovzdat program zakaznikovi, tak este narychlo zlepis nejake krajsie GUI, vyfarbis ho na ruzovo a mame to!

Mam dalsie napady, ale nechcem to tu prilis zahltit.

Je to zaujimava debata, rad v nej budem pokracovat. Co sa tyka nejakeho projektu, mozme to zvazit, ale teraz mam tri nekonecne projekty (na ktorych robim len vo volnom case) a nestiham.

[Yin]

Už ma chápeš do detailov. Ak to proste nestihaš, uvítal by som podporu... čo koľvek, čo by pomohlo projektu (napr. zhrnutie tých 150 strán jak na projekt na sourceforge a podobne). Nevies o tom nejakom projekte, ktorý by dokázal prijať túto koncepciu?

[orin]

Pravdupovediac sam som mal v plane spravit nieco nie uplne vzdialene tomu, co hovoris. Robim programovaci jazyk (jeden z tych troch projektov) a chcel by som, aby sa k objektom automaticky generoval user interface. Ale zatial tak daleko nie som

Ak to myslis vazne, mal by si pozistovat co a ako robia ostatni. Ked som chcel ziskat prehlad v tom co sa deje, jednoducho som presiel vsetky projekty (v jednej kategorii) na freshmeate. Je to sice typicky niekolko sto, ale ide to pomerne rychlo a nakoniec najdes mozno 5 naozaj zaujimavych.

Uz som spominal glade a mozillu. Z mozilly by si mohol zobrat XPCOM. To je ta komponentova architektura, interface sa opisuje pomocou IDL. Alternativy su Orbit v gnome, nieco dalsie velmi podobne je v OpenOffice. Mozno ti to bude pripadat prilis zlozite (mne to tak pripada), ale stoji to za uvahu. Mozilla ma tiez celkom prepracovane GUI definovane v XML a poprepajane s komponentami pomocou javascriptu. Zas tak velmi do toho nevidim, ale myslim ze je to dobre vidiet aspon pre inspiraciu.

Inac - nebolo by zle najprv si overit koncepciu. Dajmetomu napisat nejaky skript (ja pouzivam python), ktory by vyparsoval tu definiciu signalov a vygeneroval by rozhranie. Ako format doporucujem XML a parsovat pomocou DOM - usetris vela casu pri vyrobe parsera.

Tiez nie je zle zoznamit sa s API viacerych GUI a ich moznostami. Na povrchu vyzeraju podobne, ale koncepcne riesia mnohe veci rozdielne.

SourceForge je dzungla, hlavne ta ich dokumentacia. Ale nie je to nakoniec take zlozite - aj ked mohli to spravit aj jednoduchsie. Najprv sa musis prihlasit, napisat im popis projektu, jeho nazov a licenciu. Oni to odsuhlasia - pomerne rychlo - tak do troch dni, ale mozes to cakat uz na druhy den. Detaily si uz nepametam, prihlasoval som sa tam niekedy pred dvoma rokmi...

IMHO dost cudne je uploadnovanie - posielas to tam cez FTP do spolocneho adresara a potom to cez webove rozhranie zaregistrujes a presunie sa to tam kde to ma byt.

[Yin]

Radšej pobím v Perle, ale to je nepodstatné, aj tak, by som rád vyrobil niečo takéto:

parser modul:    XML ASCII Binary
                  |    |      |
                štrukturálny model
                       |
layout modul:    múdri aloritmus
                   |    |    |
GUI backend:       QT  KDE  ...

To je však hudba budúcnosti a možno absoltne zlý návrh...

sourceforge.net: zaujíma ma mailing-listu a tiež,či nepodporujú niečo iné ako CVS... ja by som radšej Darcs...

[Petr Zelenka]

Zdravím, ale asi jsi zapoměl uzavřít jeden z tagů code, resp. ti u toho zavíracího chybí lomítko. Pak se vše pod tím formátuje tak, jak se to formátuje :)

Jinak téma GUI se tu docela rozmohlo. Obecně si myslím, že nic není ideální a když už se k ideálu přiblížíš, je to jen tvůj ideál. Někomu jinému to může připadat naopak nepoužitelné.

[Yin]

Opravene.
Ano, súhlasím.