Vlákno názorů k článku Historie vývoje grafického uživatelského rozhraní (2) od Biktop - Myslím, že je to velká pravda, co řekl...
-
Biktop (neregistrovaný)
Myslím, že je to velká pravda, co řekl Alan Kay o těch nesprávně pochopených a špatně implementovaných myšlenkách. Díky Commodore 64 a jeho systému GEOS se s GUI i CLI přístupy střetávám prakticky „odmalička“ a za tu dobu jsem dospěl k názoru, ve kterém se stále více utvrzuji: přístupy, jež nám z jednoduchých problémů dělají problémy triviální, nám z obtížněji řešitelných problémů udělají problémy neřešitelné. Je přeci úplná pitomost řešit nějaké plochy přilepené na nějakou virtuální krychli, okna navěšená jak na nějaké šňůře na prádlo, fasády („skiny“) atp. Já osobně spatřuji největší rezervy ve vývoji UI právě ve vyváženém a účelném propojení GUI s CLI. To je podle mne ten problém, na který by se měli designéři UI zaměřit – co řešit knoflíkem, co příkazem, co obojím a jak uživateli pomoci k tomu, aby to co nejefektivněji zvládnul a bylo to celé co nejintuitivnější. A ať mi někdo ukáže systém, který to rozvinul lépe než Smalltalk (konkrétně třeba ten Squeak). Nemyslím implementaci, nemyslím technické detaily, myslím logiku věcí. Když se nad tím zamyslíme, tak skutečně dospějeme k tomu, že za těch uplynulých 30 let se to vzalo, ořezalo se to (protože běžné počítače by to tehdy byly nezvládly) a nějak se implementovala určitá podmnožina té myšlenky s dokonale zpřetrhanými logickými vazbami a zbylých 30 let se tohle torzo akorát technicky vylepšovalo a doplňovalo o šlehačku.
Je to jako by primitivní národ, znající jen malůvky uhlím na skalách, našel torzo nějaké sochy a na základě něj dělal nová torza, vylepšoval je – dělal je barevná, zvyšoval počet bradavek atp. Ale nikoho zatím nenapadlo, že tomu chybí hlava, nohy, ruce a že 5 bradavek nemá smysl, neboť nikdo nechce vidět, že torzo nebylo cílem autora, že torzo je jen to, co z jeho myšlenky zbylo. -
>> Je to jako by primitivní národ, znající jen malůvky uhlím na skalách, našel torzo nějaké sochy a na základě něj dělal nová torza, vylepšoval je – dělal je barevná, zvyšoval počet bradavek atp.
To se mně fakt líbilo! :)
Jestli on nebude problém taky trochu v tom, že na to torzo už si zvyklo takový množství lidí, že jakákoli změna je nesena nelibě… -
Hmmm… Ja si myslim, ze na system GUI uz tezko vymysli nekdo jinak, nebo dokonce lepe – i kdyz … nikdy nerikej nikdy…
Podle meho nazoru je mozna chyba v tom, jak se dneska stavi k programovani aplikaci samotnych. Stredem pozornosti u drtive vetsiny aplikaci je prave GUI a system komunikace s uzivatelem vubec. Jiste, je to velmi dulezita vec a navic co si budem povidat – u drtive vetsiny uzivatelu je to prvni, co na aplikaci zaujme, ale na programu samotnem je podle meho nazoru nejdulezitejsi to co dela, jak to dela a jak moc univerzalne to lze vyuzit.
Dovedu si predstavit system (prikladem budiz situace jako na Linuxu kde je k dispozici slusne mnozstvi GUI frameworku napr. QT, GTK, FLTK, FoxToolkit, WXWidgets, atd…), kde funkcionalni jadro aplikace je programovano jako modul pro nejaky system distribuovanych objektu, nebo RPC (dale jen DO/RPC – napr DBUS, Corba, …) a GUI ( mozna i CLI) je reseno jako XML soubor s podporou skriptovani a stylovani pomoci css2 (fakt nechapu, proc se to dneska nevyuziva pro vetsinu frameworku. Minimalne by to resilo jednoduchy prenos stylu a vzhledu GUI mezi jednotlivymi frameworky).
Vyhod vidim mnoho. Jednak by bylo pomerne jednoduche tvorit aplikace jednoduchym integrovanim jedne do druhe, nemluve o komunikaci mezi aplikacemi a usnadneni jejich spoluprace. Odpadly by vyrazne rozdily mezi jednotlivymi toolkity, ktere mnohdy zamezi jak vyuziti jiz existujiciho projektu v jinem projektu, nebo kolikrat jen jejich komunikaci, nebo integraci do prostredi vytvoreneho v odlisnem freamworku (rozdily teoreticky skryje vrstva DO/RPC).
Navic diky tvorbe komunikacniho rozhrani mezi aplikaci a uzivatelem pomoci XML a css2 by nebyl problem vytvorit jednoduchy a univerzalni editor pro tvorbu GUI a mozna i CLI rozhrani jednotlivych aplikaci. Navic by na nem nebyly zavisle … atd.
Je to hruby a mozna trochu naivni nastin myslenky, a urcite by nesel realizovat uplne vzdy (napr. hry?), ale zas az tak nerealne se mi to taky nezda … :) -
Úplně v živých barvách vidím, jak by to zas bylo pomalý a věčně by to RPC spojení padalo :) Nehledě na to, že by se všechny aplikace znovu přepisovaly a po tu dobu by stagnovaly jejich featury a celková stabilita by opět o několik řádů klesla… Myslím že přechod na KDE4 nebo třeba nový audiosystém málem co rok úplně stačí k takovému „štěstí“…
>> prikladem budiz situace jako na Linuxu kde je k dispozici slusne mnozstvi GUI frameworku napr. QT, GTK, FLTK, FoxToolkit, WXWidgets, atd…
To je spíš zářným příkladem toho, že nikdo zřejmě nebyl schopen udělat pořádný toolkit, který by nebylo potřeba nahrazovat něčím jiným… -
„Úplně v živých barvách vidím, …“
Pomale? Pomale by bylo co? DO/RPC? Dynamicky generovane GUI/CLI? nebo komunikace funkcionalniho jadra pres DO/RPC? At se na to divam jak chci tak ve vsech pripadech je rychlost zavisla hlavne na implementaci. Navic vemte si jaky je rozdil mezi scriptovanym GUI (napr. TK, PyQT) a GUI popisovanem s pomoci XML? No z hlediska pocitace a uzivatele defakto zadny. Z hlediska programatora muze byt propastny. Mimo to me osobne napr. takovy DBUS neprijde ani pomaly a ani nestabilni (i kdyz muzete mit jine skusenosti) a da se rici, ze implementuje v sobe obe technologie DO/RPC.
Co se tyce prepisovani aplikaci, ano, ale taky jsem nikde nepsal, ze je to nutno vse provest hned a naraz. U KDE 4 je ten problem, ze zmeny prisly moc rychle a nahle. Zmeny by mely probihat v klidu a pomalu. Uzivatel by si temer nemel vsimnout, ze ke zmene dochazi a navic je dost casu a prostoru pro reseni chyb, nedostatku, a pripadne spetne kompatibility (je-li potreba).
„To je spíš zářným příkladem toho, že nikdo zřejmě nebyl schopen udělat pořádný toolkit, který by nebylo potřeba nahrazovat něčím jiným…“
Ano, to je do jiste miry pravda. A problem je jeste navic mnohem hlubsi a komplexnejsi a netyka se jen GUI. Mysleni a potreby lidi je obecne neuveritelne variabilni a z toho vychazi jednoznacne potreba variability nastroju, ktere jsou lidmi vyuzivany (Programovaci jazyky, GUI, Desktop/WM, atd…). Podle me je nemozne vytvorit univerzalni a pro vsechny vyhovujici GUI, nebo programovaci jazyk. (ironicky: ) No, v Linuxu mate moznost – XLib. Preji prijrmnou zabavu (konec ironie :-D ). Jinak opstatni Toolkity se navzajem nijak neprebijeji a nenahrazuji. Spis se da rici, ze vzajemne koexistuji, aby vyhovely ruznym programatorum a ruznym uzivatelum… Existuji vsak technologie – napriklad zminovane kaskadove styly, ktere jsou schopne nektere vlastnosti vsech Frameworku do jiste miry standartizovat a zjednodusit; jednoznacna vyhoda jak pro uzivatele, tak i pro programatory. Jen me hlava nebere proc uz nejsou davno implementovany a pouzivany ( v tomto kontextu. jak treba funguje CSS2 v kombinaci s GUI se muzete presvedcit u ClanLib, ktere je prave pro tyto ucely vyuziva) -
Byl to víceméně vtip – s reálným jádrem.
Vrstva DO/RPC je prostě vrstva navíc a tímpádem příležitost k dalšímu zdržení, chybám a selháním.
Netvrdím, že to nejde udělat, ale trvám na tom, že udělat to dobře je o fous těžší než udělat klasickou monolitickou aplikaci. A nevidím tam žádný výrazný přínos ani pro vývojáře, ani pro uživatele. Je to zajímavá a možná správná myšlenka, ale to je např. Hurd taky ;) -
petr_p (neregistrovaný)
Hurd. Právě že o to jde. S postupující paralelizací je nutné přejít na asynchronní model a zrovna uživatelské rozhraní je první kandidát. Tak dlouho se lidi budou posmívat X11 až jim vleze do systému jinudy :)
Podívejte se na Linux, kolik měl jaderných vláken před pěti lety a kolik jich má teď. Když píšete grafickou aplikaci, kde UI nemá chcípnout, když se zablokuje I/O, tak si uděláte řídící smyčku a kvůli výkonu místo aktivního čekání použijete select(2) nebo zámky.
A z druhé strany máme webové aplikace a všechna ta oblaka.
A někde uprostřed CORBU, D-Bus, Bonobo, KParts, XPCom a tak dále.
-
Téměř přesně to, o čem mluvíte, je možné už dnes pomocí XULRunneru. Tedy že o zobrazování GUI se stará jednoúčelová aplikace, jejíž nespornou výhodou je, že o její vývoj a korektní chování a vzhled na všemožných platformách se stará někdo jiný s poměrně kvalitním zázemím :-)
Jediné, co samotná aplikace musí pro zobrazení GUI udělat, je chovat se jako webový server, který podobně jako u klasického webu předhazuje XULRunneru XML popis rozhraní, styly a nějaký ten JavaScript.
Samozřejmě se to nehodí na všechno, také je třeba dbát na bezpečnost, ale pro intranetové client-server „kancelářské“ aplikace je to ideální řešení.
Tuto myšlenku jsem se pokusil realizovat v tomto projektu: http://code.google.com/p/seasidexul/ -
Jj. me se taky XUL do jiste miry libi, a jeho sily jsem si vsiml uz davno. Presne toto se mi vybavi, kdyz se rekne netaplikace.
Ale zatim mam ten pocit, ze hodne projektu jednak trochu vzdycky pripomina mozillu na niz je napasovany jiny vzhled a funkce a obcas je trochu… nespolehlivy (nestabilni? A nevim, nebo spis zatim nemohu posoudit proc). Nicmene zurive se na tom pracuje a myslim, ze XUL jeste ceka budoucnost :-) -
Pavel TišnovskýZlatý podporovatelHoj Pavle, zrovna XULRunneru jsem chtel napsat, opet jsi rychlejsi ;-) Osobne si myslim, ze az se trosku XULRunner vychyta a vyjde pro nej 1–2 killer aplikace, tak se stane velmi dulezitou soucasti desktopu. Nemusi se jednat jen o webovky, tj. aplikace, kde logika a data jsou nekde na serveru, ale i lokalni aplikace, ktere proste oddeli logiku od GUI.
Proste tam, kde se neprosadily applety a kde nevyhovuje uzavrenost Flashe nebo JavaFX ;-)
