Reflexe grafických rozhraní

17.1.2017 15:01 | Přečteno: 2749× | Obecné IT | | poslední úprava: 28.1.2017 20:55

Nedávno zde proběhla diskuze o desktopu, kde byl nakousnut i Smalltalk a jeho GUI, kde jsem zmíňil „morphic halo“ jako prvek, který smalltalkovským GUI umožňuje reflexi. V diskuzi jsem byl požádán o další informace, proto vám dnes přináším článek na téma reflexe grafického rozhraní nejen ve Smalltalku.

Reflexe

In computer science, reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime.

-- Reflection (computer programming). Wikipedia [online]. [cit. 2017-01-12].

Volně přeloženo:

Reflexe je v teoretické informace schopnost počítačového programu za běhu procházet, zkoumat, a modifikovat svou vlastní strukturu a chování.

V případě Objektově Orientovaného Programování (OOP) to typicky znamená, že je možné zjišťovat informace o objektech, například jméno třídy, ze které jsou instancovány, či kontrolovat přítomnost atributů, nebo metod. Existují ale také programovací jazyky, které takto mohou modifikovat cokoliv pomocí vyhodnocování datových struktur. K typickým zástupcům těchto jazyků patří například Lisp.

V případě grafického rozhraní je reflexí chápána možnost modifikace „oken“ a jejich chování, ale také možnost modifikace samotných programů, které „okna“ generují.

Reflexe grafického rozhraní v X Window / Gnome

Budu předpokládat, že všichni znáte a používáte grafické uživatelské rozhraní v nějaké jeho formě. Já osobně používám Linux Mint s grafickým prostředím Mate, což je fork Gnome 2. Toto prostředí je ve svých principech podobné všem ostatním linuxovým grafickým rozhraním s okny - myší a klávesnicí můžete pohybovat s okny na jedné, či více plochách. Okna můžete zavírat, minimalizovat, maximalizovat a tak podobně.

Grafické rozhraní v typických linuxových desktop managerech funguje všechno podobně. Program pomocí bindingů (napojení) na knihovny grafického serveru (xlib) generuje po svém spuštění nějaké „okno“. Grafický server reaguje na informace, které jsou mu bindingy předávány a uživatelské zprávy posílá zpět programu, který na ně může, ale nemusí nějak reagovat.

_{(Princip fungování X Window System. Zdroj: Volume One: Xlib Programming Manual.)}

_{(Detailnější schéma principu fungování X Window Systému. Zdroj: google dotaz v obrázcích na „x window system architecture“)}

Co se týče běžného uživatele, pro něj většinou žádná reflexe kromě té, kterou mu nabízí samotný program, přítomná není. Uživatel může myší či klávesovými zkratkami okno zmenšovat, zvětšovat, různě přesouvat a případně zavřít. Pokud mu to neumožní program, tak například nemůže změnit titulek běžící aplikace, či přidávat a ubírat položky v menu. Většina programů podobné chování uživatelům nenabízí, i když jsem již potkal takové, které tuto funkcionalitu umožňovaly.

Pokročilý uživatel má možnost používat nástroje, které jsou typicky s X Window systémem distribuovány. Jedná se například o program xev, který uživateli umožňuje testovat klávesnici a myš.

_{(Výstup z programu xev spolu s grafickým oknem. V konzoli je možné vidět ID okna aplikace, názvy eventů a kódy stisknutých kláves.)}

Dále pak třeba program xwininfo, který umožňuje zobrazit informace pro okno, na které kliknete:

Tyto informace je pak možné používat s programy jako třeba wmctrl, či devilspie, které na základě nich umožňují okna přesouvat a obecně ovládat například z nějakého scriptu, či programu, který si pokročilý uživatel napíše. Do velké míry se však stále jedná pouze o jiný přístup ke klasickému ovládání počítače, protože informace získané reflexí oken není možné využít například k přidání nového prvku do menu programu.

Pokud by uživatel něco takového chtěl udělat, nezbývalo by mu nic jiného, než získat přístup ke zdrojovým kódům aplikace, upravit je, zkompilovat a program znovu spustit s upravenými změnami. Obecně lze tedy říct, že ačkoliv klasický přístup k ovládání počítače reflexi nabízí, je velmi malá a špatně použitelná.

Reflexe v prostředí Endless OS

Před několika týdny se zde mihla zprávička zmiňující Endless OS, která mě na první pohled zaujala velmi netradičním přístupem k reflexi grafického rozhraní. Součástí zprávičky je video (youtube záloha), kde je prezentována schopnost „otočit“ aplikaci a ihned začít upravovat zdrojové kódy:

Pod videem se nachází diskuze:

<Havoc Pennington> does it live-update the front of the window with your changes?
<Jono Bacon> I don't think it does right now, but I believe that is the plan. This is an early cut of the feature.
<jrb> definitely the plan and it does, though it's fragile.

Volně přeloženo:

<Havoc Pennington> dochází se změnami k úpravám přední strany okna?
<Jono Bacon> Nemyslím, že teď ano, ale věřím, že takový je plán. Jedná se o první verzi téhle funkcionality.
<jrb> rozhodně je to v plánu a funguje to tak, i když je to křehké.

V podstatě se jedná o podobnou reflexi, jako v případě klasického desktopu, ale zajímavě zautomatizovanou tak, že kroky [editace - kompilace - běh aplikace] jsou notně usnadněny a zjednodušeny.

Osobně musím říct, že na mě toto demo velmi zapůsobilo. Rozhodně se jedná o krok zajímavým směrem a budu sledovat, jak moc se ujme. Endless OS jsem si stáhl a chtěl vyzkoušet možnosti úpravy aplikací, v současném release zatím ale tato funkcionalita naneštěstí není přibalená.

Doufám, že se nebude jednat jen o věc pro vývojáře a dokáži si představit systém, kde by uvedená funkcionalita byla v každé části grafického rozhraní a každé aplikaci. Zatím však bohužel nic takového neexistuje.

Reflexe grafického rozhraní ve Smalltalku

Smalltalk je programovací jazyk, který vznikl v roce 1972 a tehdy také fungoval jako „operační systém“ pro počítače Xerox Alto.

_{(Zrekonstruovaný počítač Xerox Alto. Zdroj: http://www.righto.com/2016/10/restoring-ycs-xerox-alto-day-9-tracing.html)}

Smalltalk se celý točí kolem konceptu image - virtuálního počítače, ve kterém běží jak grafické rozhraní, tak i celý jazyk a aplikace. Virtuální počítač je možné pauzovat, ukládat a znovu spouštět tam, kde jste přestali.

Abych se vrátil k původnímu tématu reflexe grafického rozhraní ve Smalltalku - celý koncept je postavený kolem ovládacího prvku nazvaného „morphic halo“. Dovolím si ukázku s kódem;

Morphic halo

Začnu tím tím, že si vytvořím widget modrého čverečku, jako ukázkový morph (prvek grafického rozhraní Morphic), takové malé hello world. To udělám tak, že do Playgroundu (ekvivalent konzole) napíši aMorph := Morph new openInWorld.

Pak text vyberu, kliknu na „Do it“ a tím kód vykonám - berte to podobně, jako kdybych ho napsal do terminálu;

Tím vznikne proměnná aMorph, ve které je uložena reference na objekt, který se zároveň zobrazí na obrazovce.

„Morphic halo“ je dialog, který se objeví okolo prvku na obrazovce po použití speciální klávesovo-myšové zkratky ALT+SHIFT+Kolečko:

V tomhle případě je tím prvkem který chci prozkoumat modrý čtvereček (ukázkový demo morph), okolo kterého se objevila spousta ťuplíků, na které se dá kliknout. K čemu jednotlivé ťuplíky slouží? Pokud nad nimi podržíte myš, zobrazí se krátká nápověda. Zde je přehled všech nápověd:

Ťuplíky jsou vytvářeny dynamicky a u různých morphů (prvků grafického rozhraní) se zobrazují různé. Zde například chybí ťuplík pro rotaci morphu.

Objekty

Trochu odbočím; považuji za důležité vysvětlit, že jakýkoliv viditelný i neviditelný prvek ve Smalltalku je objekt. Modrý čtvereček na obrazovce je objekt. Tlačítka morphic halo jsou objekty. Co mají objekty společného? Reagují na zprávy. Zprávy fungují podobně, jako volání metod v jiných programovacích jazycích.

Morphic halo nedělá nic jiného, než že vám zpřístupňuje interface pro posílání zpráv objektu, který je na pozadí grafického rozhraní. Pokud s objektem pohnete pomocí morphic halo, nebo třeba změníte barvu či velikost, morphic halo posílá (někdy zprostředkovaně přes zbytek morphic frameworku) objektu zprávy, aby se změnil a ten se na základě toho změní.

Zajímavý je v tomhle ohledu ťuplík „Debug“, který vám umožňí otevřít si Inspector. Inspector je grafický pohled na interní stav objektu. Jakékoliv změny provedené v objektu se propisují do Inspectoru a naopak.

V Inspectoru můžete vidět jednotlivé properties objektu, jako třeba color (objekt Color blue - objekt vrácený jako odpověď na zprávu blue poslanou objektu Color), nebo bounds (rozměry čverce).

V dolní části Inspectoru pak máte textovou plochu, která funguje podobně jako playground, tedy jako jakýsi shell. Cokoliv co sem napíšete se vykonává v kontextu objektu. Například můžete poslat zprávu self color a dostanete zpět objekt modré barvy. Stejně tak můžete například přiřadit jinou barvu, čímž změníte objekt na pozadí, což změní i reprezentaci na obrazovce a čtverec třeba zčervená.

V Inspectoru je také možné zobrazit si poděděné metody objektu a spoustu dalších vecí:

Jakýkoliv prvek grafického rozhraní může být takto zkoumán a upravován. Následující sekvence obrázků to ilustruje:

_{(Zde v okně označím pomocí morphic halo titulek.)}

_{(Titulek přenesu vedle.)}

_{(A pak ho zrotuji o 45° pomocí „morphic halo“ prvku vlevo dole.)}

Morphic halo je podle mého názoru geniální koncept, který vám umožňuje měnit prvky grafického rozhraní, zkoumat je a hrát si s nimi. Pokud vám něco nevyhovuje, prostě to vezmete a změníte dle vlastního uvážení. Díky tomu, že Smalltalk je postavený okolo konceptu image dává celý koncept smysl. Prostě si paměťovou mapu uložíte a příště začínáte tam, kde jste naposledy skončili, tedy i s upraveným grafickým rozhraním.

Přesto zde stále existují nevýhody tohoto konceptu a způsobu úprav grafického rozhraní, ke kterým se za chvíli vrátím.

Reflexe grafického rozhraní v Selfu

John Malloney, autor grafického toolkitu Morphic ho původně vytvořil pro programovací jazyk Self. Troufám si tvrdit, že v Selfu dává Morphic o hodně větší smysl, než ve Smalltalku. Proč? Protože Self je prototype-based (čti: na prototypech založený). Co to znamená?

V Selfu neexistují třídy. To má jeden ne zcela zřejmý vedlejší efekt; není v něm přítomný implicitní konstrukční a dekonstrukční mechanismus. Celý systém s tím počítá a je postavený kolem této myšlenky.

Je mi jasné, že všem nebude jasné co to znamená, proto to ještě rozvedu:

Class-based (čti: na třídách založené) jazyky, jako třeba Smalltalk, nebo Java, C++, či C# fungují na principu vytvoření popisu objektu, který chcete dostat. Tomu popisu se říká třída. Z tohoto popisu poté nějakým více, či méně přímým mechanismem vytváříte instanci, tedy samotný objekt, se kterým poté můžete pracovat. Při vytvoření instance objektu je zavolán konstruktor - speciální metoda, která nastaví nějaké hodnoty a například inicializuje reprezentaci objektu v grafickém rozhraní. Při rušení objektu je zavolán destruktor, který provede uklizení po objektu.

_{(Rozdíl mezi třídou a instancí. Zdroj: Difference between instance and Object in Java.)}

Self patří k jazykům, které jsou objektově orientované, oproti spoustě ostatních jde však do extrému - výslovně zde není nic jiného, než objekty. Nejsou zde ani třídy, tedy popisy toho, jaký chcete vyrobit objekt. Když chcete vytvořit nový objekt, vezmete nějaký již existující (například prázdný objekt), ten zkopírujete a pak do něj přidáte, změníte, nebo uberete co v něm chcete mít. Místo dědičnosti je zde delegace, ať již přímá, nebo nepřímá, kde říkáte „když se v objektu něco nenachází, má se to hledat tady a tady“.

Programy v Selfu je možné psát, nebo skládat. To funguje tak, že vezmete nějaký objekt, přidáváte do něj jiné objekty a některé ubíráte a sem tam přidáte trochu kódu a jinde změníte vlastnosti, ať již kódem, nebo pomocí nástrojů grafického rozhraní.

Stejným způsobem můžete vzít samotné prvky grafického rozhraní, třeba tlačítko, pak ho zkopírovat, změnit jeho popisek a akci po kliknutí a pak ho přidat k dalším prvkům. Když jste s výsledkem spokojeni, celý si ho uložíte do vašeho původního objektu, který tvoří celou aplikaci.

Po celou dobu nemusíte (ale můžete) vytvářet popis toho co chcete dělat, můžete to přímo dělat na objektech v paměti pomocí reflexe. Pak tyto objekty učiníte několika kliknutími součástí vaší aplikace, kterou můžete dále distribuovat a serializovat do zdrojového kódu. O to se stará Transporter.

Důvod, proč jsem psal, že Morphic dává větší smysl v Selfu, než ve Smalltalku je nyní doufám jasný. Přestože v Smalltalku můžete vyvolat na libovolné komponentě Morphic halo a tuto komponentu živě zkoumat a upravovat, není zde přítomný princip, jak upravenou komponentu učinit součást vaší aplikace. I když vezmu titulek playgroundu a otočím ho o 180°, příště až otevřu playground, titulek bude opět stejný, jako byl na začátku. Kdybych ho chtěl změnit, musel bych změnit popis objektu - zdrojový kód ve třídě a otočit ho o 180° tam, i když jsem ho změnil přímo na své obrazovce.

V Selfu bych mohl změnit přímo graficky pouze prototyp titulku a tím změnit i všechny příště vytvářené kopie stromu objektů, ze kterých je titulek složený.

Samozřejmě, že pokud by byla v Selfu použita například metoda, která titulek vytváří zdrojovým kódem z popisu, tak by byla situace stejná jako ve Smalltalku, principiálně je ale možné pracovat čistě způsobem úprav přímo konkrétních objektů.

Autoři jazyka vás přímo podporují v myšlence, abyste aplikace a grafické rozhraní tvořili tak, že rozeberete kopii nějakého objektu, který se vám líbí a ze kterého budete vycházet. K tomu slouží i Factory window, které automaticky zkopíruje každý element, který z něj „chytnete“ myší. Ten poté můžete přenést na volnou plochu a začít z něj skládat aplikaci.

Core sampler

Autoři jazyka použili v Selfu poněkud jiný přístup, než je Smalltalkovské Morphic halo. Vytvořili takzvaný Core sampler:

To je aplikace (ehm, objekt), který vám ukazuje z čeho jsou složené objekty na které namíříte křížek v zaměřovači.

_{(Core sampler v Core sampleru. Vidíme, že se skládá z coreSamplerMorph.)}

_{(Core sampler v Core sampleru v Core sampleru. Vidíme, že zatímco první C.S. se skládá jen z coreSamplerMorphu, na vrcholu druhého je labelMorph sedící na proxyMorph a tvořící nápis „coreSamplerMorph“.)}

Core sampler vám umožňuje s morphy pracovat - díky němu můžete upravovat cokoliv na obrazovce, i když je to jinak nedotknutelné. Také můžete zobrazit Outliner pro daný objekt. Outliner plní podobnou funkci jako Inspector v Selfu - v podstatě se jedná o tabulkový pohled na stav objektu, zároveň je to ale také hlavní způsob, jak objekty vytvářet a upravovat, což Smalltalkovský Inspector není (ten slouží k průzkumu objektů, ne k psaní popisů objektů - tříd). Díky outlineru získáváte přístup přímo k objektu, který tvoří samotnou aplikaci, k jeho zdrojovému kódu a properties.

_{(Menu pro otevření outlineru.)}

_{(Outliner zobrazující různé sloty, z nichž některé obsahují odkazy na další objekty, jiné metody [slot prototype].)}

_{(Ukázka změny property myLabel grafickým přetažením reference na outliner objektu stringu 'something else'.)}

_{(Ukázka změny property myLabel posláním zprávy myLabel: 'different thing' objektu, který je reprezentován Outlinerem.)}

Ukázka konstrukce aplikace

Jak jsem psal, aplikace v Selfu je možné skládat. Jak to vypadá ukazuje následující sekvence obrázků:

Pro praktickou aplikaci by samozřejmě bylo nutné přidat ještě další prvky, jako tlačítka, různé gridy a zarovnání, aby aplikace tvořila skutečně okno. V principu je ale možné postupovat stejným principem. Jako zdroj všemožných widgetů slouží „Factory window“ - okno s ukázkami všemožných widgetů, které z něj můžeme přetahovat na plochu:

Jakmile by bylo vše hotovo, bylo by třeba ještě o-anotovat všechny objekty a přiřadit je do společného modulu. Pak by již bylo možné je například uložit na disk a verzovat pomocí gitu, či je distribuovat dalším uživatelům Selfu.

Kritika

Přestože Self nabízí velmi zajímavé možnosti vytváření grafického rozhraní, je nutné také zmínit negativní části.

Specificky jde o jistou nepřehlednost co do anotace objektů, kdy je někdy možné některé objekty špatně o-anotovat, což může mít za následek export pouze části aplikace.

Dále jsou občas problémy s mixováním procedurálního a prototypového stylu programování, kdy může být složité zjistit, kde se vlastně daný morph bere a jestli náhodou není generován procedurálně nějakou metodou, namísto aby byl uložen jeho prototyp v nějaké property. Pokud dochází ke kopírování morphu před jeho zobrazením, může být nesnadné zjistit, z čeho je morph vlastně kopírován.

Tyto problémy je obecně možné řešit lepšími nástroji, nutné je ovšem dodat, že vzhledem k minimální komunitě okolo Selfu (za poslední rok se konference účastnilo cca 10 uživatelů celosvětově) momentálně žádné takové nástroje nevznikají. I přes tyto nevýhody je však programování v Selfu zajímavé, když už pro nic jiného, tak pro svou odlišnost od zbytku světa.

Závěr

V blogu jsem prezentoval několik různých druhů a způsobů reflexe grafického uživatelského rozhraní, ani zdaleka se však nejedná o všechny.

Jestliže vás zaujal Self, časem se pravděpodobně dočkáte seriálu, nebo si můžete přečíst oficiální příručku. V případě, že vás zaujal Smalltalk, můžu doporučit http://pharo.org, resp. knihu Pharo by example, či starší tutorial Squeaku na youtube.

Pokud znáte nějaký jiný způsob reflexe grafického rozhraní, či pokud máte nějaké dotazy, nebo připomínky, nezapomeňte se ozvat v diskuzi.

       

Komentáře

[offtopic]

Vlákno bylo přesunuto do samostatné diskuse.

[Mirda]

ja si myslim, ze ty komentare nahore jsou proste od lidi, kteri taky nechapou o co jde, ale stydi se to priznat.

To ja s tim nemam zadny problem, fakt nechapu co je smyslem toho povidani. Jde o nejaky novy , prevratny zpusob, jak navrhovat, vyrabet GUI?

[Bystroushaak]

To ja s tim nemam zadny problem, fakt nechapu co je smyslem toho povidani. Jde o nejaky novy , prevratny zpusob, jak navrhovat, vyrabet GUI?

Ne. Smyslem je odpovědět na otázku položenou v diskuzi, na kterou vede odkaz z perexu. To že se tak dá dělat GUI je vedlejší efekt kombinace reflexe a prototype-based jazyka. Jinak Self není moderní, tyhle schopnosti má někdy od roku 1990 +- 3 roky.

[Blaazen]

Tak zajímavé to je, ale takové akademické. Možná proto bylo na konferenci deset lidí.

[Bystroushaak]

V konferenci je asi 300 lidí, ale jen cca 10 se aktivně účastní. Dřív to bylo jinak, ale posledních 15 let Self docela upadl, od doby co byly prostředky věnované jemu Sunem přesunuty na Javu (Self dal základ Javovskému JITu).

[V.S.]

Pro vetsi aktivni ucast lidi v konferenci bych doporucil vic gifu tancujicich slapek. Posledne se diky tomu zapojilo par lidi, kteri krome toho za cely rok nic nenapsali.

[Bystroushaak]

Jj. Jen jejich tolerance ke flame je dost minimální.

[kralyk z abclinuxu]

Tak zajímavé to je, ale takové akademické.

+1, vypadá to jako takové GUI pískoviště. Mohlo by to být dobrý na prototypování, pokud by se to dalo nějak vyexportovat do něčeho nativního / nečeho co není jako z jiného světa

[Bystroushaak]

Proč z toho něco exportovat a nepoužívat to rovnou?

[kralyk z abclinuxu]

Uvažuju z pozice tvůrce aplikace, čiliže bych musel přejít na Self při tvorbě aplikace a to nechci, to je na mě příliš odříznuté od světa. Asi nejdál kam bych byl ochoten jít tímhle směrem (tj. Lisp/Scheme/Self/apod.) je Clojure.

[pc2005]

No já nevím, aby se mě pod rukama měnilo GUI, to by mě moc nepotěšilo .

Taky tahle selfmodifikace bude mít velkej overhead. Já si teda jednou nastavím ovládací prvky a pak to nechám, to klidně může být při kompilaci (zvlášť když jsou zdrojáky) a nebo xml s layoutem (a to je luxus IMO).

Dá se vůbec ta selfmodifikace implementovat v proprietárním software?

Ale článek se mi samozřejmě líbil .

[xsubway]

Díky za pěkné shrnutí.-)

[Pavel Křivánek]

Často, když dojde na "halo", tak se mi vybaví, jak jsem v době prvních zkušeností se Squeakem začal zcela instinktivně klikat prostředním tlačítkem myši na vyskakující dialogová okna s celkem nic neříkajícími chybovými hlášeními, abych o nich zjistil více informací, podíval se na call stack a podobně. Pak jsem ale rozladěně zjistil, že se mi žádné halo neukáže, protože nejsem ve Squeaku...

[mirec]

Hmm, čo HTML5 aplikácie (electron)? Nie je to síce úplne to isté, ale úprava správania aplikácie počas behu je väčšinou možná.

[Bystroushaak]

Hmm, čo HTML5 aplikácie (electron)? Nie je to síce úplne to isté, ale úprava správania aplikácie počas behu je väčšinou možná.

Já mám teda zkušenost jen s třemi aplikacemi tohohle druhu (Spotify klient pro linux, Visual studio code a Slack klient), ale nikde tam nemáš přístup k interním komponentám, ani nemůžeš změnit jejich reprezentaci perzistentně. Teoreticky to možné je, ale chybí nástroj, který by ti dovolil se dostat do zdrojáku za běhu (třeba JS konzole).

[mirec]

Ja som pár tých aplikácií skúšal a bežne som sa dostal do web inspectora s možnosťou meniť komponenty. JS konzola tam bola tiež. Perzistencia tam samozrejme chýba, ale ak hovoríme o reflexii nie je to až tak vzdialené od selfu.

[Bystroushaak]

Jak ses tam dostal?

[mirec]

Vždy zabralo ctrl + shift + I, ale neskúšal som to na väčších komerčných aplikáciách ako spotify, môžu to mať zablokované.

[Bystroushaak]

Jop, je to zablokované. Já jsem původně přemýšlel, že do článku přidám i to GUI z C# / .netu, protože tam taky reflexe fungovala a dalo se dostat k internímu XML reprezentujícímu vzhled aplikace. Ale už je to mnoho let, co jsem s tím dělal, tak jsem se na to vykašlal.

Jinak jazyky jako Self jsou zajímavé tím, že reflexe funguje až „na dno“. V alternativním interpretru Klein můžeš teoreticky změnit a přistupovat úplně k čemukoliv, včetně interpretru samotného, takže třeba portování na novou platformu probíhá tak, že se přepíše pár primitiv a pak se nechá interpret překonvertovat na jiný machine code.

[mirec]

Teoreticky má v8 asi podobné možnosti keďže debugger je napísaný v javascripte. Nenašiel som však žiadne verejné API ktorým by sa dalo hrabať až na obsah jednotlivých uzáverov.

[Kate]

Talhle by možná mohlo fungovat i QML, kde je GUI tvořeno JSONem s logikou v JS. Ale jestli jde napsat aplikace ve které jde GUI měnit za běhu jsem nezkoušela.

[Ruža Becelin]

Tohle je na clanek!

Lisp/Smalltalk sel zatim dost kolem me, ale tohle me navnadilo...

Diky

[Bystroushaak]

Tohle je na clanek!

Jo, já vím. Původně jsem nad tím uvažoval, ale vadí mi ten proces kolem článků, kdy musíš HTML poslat někam do háje, pak to někdo upraví a publikuje tak za týden / dva rozřezané do několika dílů. Taky obrázky jsou tam vložené jinak a nemám možnost to potom upravovat. A to všechno, abych za to dostal tisícovku, nebo míň.

[pavlix]

+1

[KS]

Moc hezký článek!

[Grunt]

Doufám, že se nebude jednat jen o věc pro vývojáře a dokáži si představit systém, kde by uvedená funkcionalita byla v každé části grafického rozhraní a každé aplikaci.

Čistě pro zajímavost: Změny v kódu se ukládají/by se měly ukládat do běžící instance či do systémového exáče? Když bude chyba v kódu tak se aplikace rovnou vrátí do posledního funkčního stavu nebo u se rovnou začne načítat debuger? Nápad zajímavý, občas dostat nějakou aplikaci s malou změnou do systému (stažení zdrojáků a všech potřebných závislostí, kompilace, instalace) je pomalu delší vlastní změna, ale zas tak úplně růžově bych to neviděl. Libovolné IDE je poměrně náročné na volné místo, paměť nehledě na to že častokrát jsem rád že můžu balík smazat a znovu rozbalit z taru…

[xkucf03]

Vypadá to zajímavě a určitě je fajn se podívat, jak to funguje jinde (než s čím člověk běžně pracuje), takže dík za článek.

Ale k čemu je to dobré? Dokáži si představit, že bych si chtěl třeba upravit aplikaci tak, abych mohl nějaké akce vyvolat z příkazové řádky (v aplikaci by to „stisklo“ tlačítko) nebo bych si doplnil obsluhu nějakých událostí (např. přijde e-mail → rozbliká se mi LEDka), i když to aplikace/framework původně neumožňovala.

Jenže pak se na to podívám z pohledu API a nedává mi to smysl. Buď budeme to uspořádání/strukturu GUI komponent považovat za veřejné rozhraní, a pak to zásadně omezuje autory aplikace v jejím vnitřním přepisováním a refaktoringu (něco změní a všem uživatelům rozbijí to, co si na aplikaci napojili) nebo to za veřejné API nepovažujeme, a pak je to dobré leda na jednorázové hacky, u kterých jsme smířeni s tím, že v příští verzi nejspíš přestanou fungovat.

Nebo je to jen k tomu, aby se jiný programátor mohl inspirovat v existující aplikaci a něco si z ní vykopírovat? Nebude z toho pak mnohem větší bloatware než když se pracuje s normálním kódem?

A jak je to s aktualizacemi? Vydám opravu a pokud máme domluvené veřejné API, tak se na novou verzi můžou ostatní v pohodě napojit. Ale jak se napojí na nový prototyp nebo image?

Pak by již bylo možné je například uložit na disk a verzovat pomocí gitu, či je distribuovat dalším uživatelům Selfu.

Na disku to pak vypadá jak? Je to čitelný text nebo se verzují bloby? Je to lepší než třeba GUI naklikané nějakým návrhářem typu Netbeans, Qt Creator nebo Glade?

A co slučování dvou verzí (merge)? Dělat tohle s textovým zdrojákem je někdy dost opruz, ale naštěstí té informace bývá málo a je v celkem čistém tvaru (ručně psaný kód). Ale slučovat dva obrazy nebo prototypy? Jde to? Svým způsobem to může být snazší, protože nástroj může rozumět obsahu (nejsou to pro něj jen řádky, kterým nerozumí), ale té informace tam bude asi víc, než kdyby to psal ručně člověk. Existuje nějaký třícestný diff/merge pracující s objekty?

P.S. trochu mi to připomíná web – např. ve Firefoxu můžu označit kus stránky, kliknout pravým tlačítkem a dát „Zobrazit zdrojový kód výběru“ – výsledek si vykopíruji do své stránky/aplikace a takto si ji složím z kousků webu, které jsem viděl jinde. Ještě by to mohlo automaticky vykopírovat obrázky, styly, skripty… současný Firefox vykopíruje jen HTML. Ale vedlo by to ke kvalitnějším programům nebo efektivnější práci?

[Fluttershy, yay!]

Ale k čemu je to dobré?

Používal jsi někdy (trochu seriózně) Emacs včetně Elispu?

[Bystroushaak]

Ale k čemu je to dobré? Dokáži si představit, že bych si chtěl třeba upravit aplikaci tak, abych mohl nějaké akce vyvolat z příkazové řádky (v aplikaci by to „stisklo“ tlačítko) nebo bych si doplnil obsluhu nějakých událostí (např. přijde e-mail → rozbliká se mi LEDka), i když to aplikace/framework původně neumožňovala.

Jenže pak se na to podívám z pohledu API a nedává mi to smysl. Buď budeme to uspořádání/strukturu GUI komponent považovat za veřejné rozhraní, a pak to zásadně omezuje autory aplikace v jejím vnitřním přepisováním a refaktoringu (něco změní a všem uživatelům rozbijí to, co si na aplikaci napojili) nebo to za veřejné API nepovažujeme, a pak je to dobré leda na jednorázové hacky, u kterých jsme smířeni s tím, že v příští verzi nejspíš přestanou fungovat.

Definuj „to“, popisoval jsem víc konkrétních věcí.

Třeba v Selfu nejde jen o úpravy, jde i o možnost zkoumat. Aplikace pro tebe není binární blob, ale kolekce objektů. Ten rozdíl je asi jako mezi 3D hrami, kde je všechno složené z textůr a voxelovými hrami, kde je všechno složené z malých kostiček. Rozdíl je, že pod texturu se nedostaneš, ale kostičky můžeš rozebírat a skládat různě.

Co se týče toho API, tak žádné nepotřebuješ, protože se prostě dostaneš až přímo dovnitř do objektu, nad kterým bys v jiných jazycích musel stavět to API. Samotný objekt držící data je API.

A jak je to s aktualizacemi? Vydám opravu a pokud máme domluvené veřejné API, tak se na novou verzi můžou ostatní v pohodě napojit. Ale jak se napojí na nový prototyp nebo image?

Zde to bude pravda dělat problémy, ale asi podobné, jako kdyby autoři změnili API. Prostě to budeš muset s novou verzí upravit, nebo zůstat u staré. Neříkám, že je to dokonalé, jen je imho (minimálně pro mě) lepší takovou možnost mít, než ne.

Na disku to pak vypadá jak? Je to čitelný text nebo se verzují bloby? Je to lepší než třeba GUI naklikané nějakým návrhářem typu Netbeans, Qt Creator nebo Glade?

Je to trochu špatně čitelný text. Asi takhle (můj http klient pro Self). Problém je, že to není serializované jako kdybys psal zdroják jako člověk, ale jako jednotlivé části pro každý slot (property). Tzn že když má objekt 10 slotů, tak je tam prostě 10x kód, který říká „na tohle místo dej tenhle evaluovaný zdroják jako metodu / data“. Nevím, proč je to takhle pojaté, když by šlo i přímo definovat objekt vcelku a zdroják by pak byl čitelnější, ale asi to bylo takhle jednodušší na implementaci.

A co slučování dvou verzí (merge)? Dělat tohle s textovým zdrojákem je někdy dost opruz, ale naštěstí té informace bývá málo a je v celkem čistém tvaru (ručně psaný kód). Ale slučovat dva obrazy nebo prototypy? Jde to? Svým způsobem to může být snazší, protože nástroj může rozumět obsahu (nejsou to pro něj jen řádky, kterým nerozumí), ale té informace tam bude asi víc, než kdyby to psal ručně člověk. Existuje nějaký třícestný diff/merge pracující s objekty?

Jde to dělat na úrovni zdrojáku, principielně i na úrovni objektů (smalltalk to tak tuším řeší), v Selfu to ale nikdo neimplementoval. Ta komunita kolem něj je docela minimální a hodně akademická.

P.S. trochu mi to připomíná web – např. ve Firefoxu můžu označit kus stránky, kliknout pravým tlačítkem a dát „Zobrazit zdrojový kód výběru“ – výsledek si vykopíruji do své stránky/aplikace a takto si ji složím z kousků webu, které jsem viděl jinde. Ještě by to mohlo automaticky vykopírovat obrázky, styly, skripty… současný Firefox vykopíruje jen HTML. Ale vedlo by to ke kvalitnějším programům nebo efektivnější práci?

Je to trochu podobné, ale spíš než tímhle v tom, že můžeš prostě pustit JS konzoli a pracovat s DOMem a HTML a JS kódem z té konzole. Což je takový ekvivalent debuggeru, kdežto Self je celé prostředí, ne jen ekvivalent debuggeru.

BTW: Javascript byl přímo inspirovaný Selfem. Jen se to moc nepovedlo, protože jeho objektový model je nedotažená zprasenina, kde je úplně brutálně vidět, že autor převzal jen půlku toho modelu.

Časem chci o Selfu rozepsat seriál, kde toho vysvětlím víc. Bude to ale trvat relativně dlouho (minimálně měsíce, možná roky).

[Josef Kufner]

Tady je důležité si uvědomit, že obecné API pro inspekci objektů sice umožňuje prozkoumat aplikaci a dělat všelijaké zajímavé věci, ale není to stabilní API proti kterému by se daly vyvíjet nějaké nástroje. Tento problém neustále řeší například Adblock – weby se pozvolna mění a Adblock musí držet krok, aby fungoval. Nebo třeba youtube-dl a podobné nástroje, kterým se používaná služba mění pod rukama.

Na druhou stranu takové API umožňuje snadno vyrobit automatické testy GUI aplikací, kde jednotlivé čudlíky se opatří trochou metadat. Automatický tester to pak může proklikat bez člověka a současně si hlídat code coverage a zkoušet různé cesty, dokud není proklikané vše. Ono vůbec už jen to, že tester ví, kde je jaký čudlík dost pomůže (viděl jsem pro takové testy používat OCR).

Dalším pěkným nástrojem je stařičká makrokamera z Windows 3.11. Uživatel si nahrál kam kliká a co píše, pak to spustil a ono to klikalo samo. Dokonce to trefovalo správé čudlíky i když se okno posunulo či zvětšilo. Nezkoumal jsem detaily, ale nějaká taková reflexe už tam byla.

[Bystroushaak]

Jop. Není to prostě úplně jednoduché a také neříkám, že je to všespásné. Na druhou stranu mi to přijde opravdu hodně zajímavé a myslím, že si celý ten koncept zaslouží větší rozšíření.

[xkucf03]

Definuj „to“, popisoval jsem víc konkrétních věcí.

Ta reflexe GUI, možnost vstoupit do programu, zkoumat jeho objekty, upravovat je…

Aplikace pro tebe není binární blob, ale kolekce objektů.

Svobodný software pro mne není blob. Zrovna jak jsem psal včera o tom Glade, tak jsem si ho schválně pustil a chtěl v něm naklikat nějaký hello world formulář, ale nevěděl jsem, jak na to (tedy aby to fungovalo správně, např. že textové pole se roztahuje při roztahování okna, tlačítko vpravo zůstává pořád u pravého okraje okna atd.), ale podíval jsem se do nastavení Glade a zjistil, že tento formulář se chová přesně tak, jak chci. Sice v tu chvíli nemůžu kliknout myší a zkoumat běžící program – musím na to zdlouhavěji, opsat kus textu z formuláře, grepnout zdrojáky, zjistit, kde se používá a otevřít si ten soubor – ale jde to a není to nějaká zásadní překážka.

Nicméně souhlasím, že by bylo fajn mít možnost pustit program třeba v nějakém ladícím režimu a pak mít možnost zkoumat prvky jeho GUI.

Zde to bude pravda dělat problémy, ale asi podobné, jako kdyby autoři změnili API. Prostě to budeš muset s novou verzí upravit, nebo zůstat u staré. Neříkám, že je to dokonalé, jen je imho (minimálně pro mě) lepší takovou možnost mít, než ne.

Ano, je fajn tu možnost mít, ale přemýšlel jsem nad praktickým využitím. To hledání inspirace a opisování z jiných programů je jedna věc, to se hodí.

Pak by se mi líbilo mít možnost ovlivnit chování jiných programů, např. si tam jednoduše dopsat nějakou funkci nebo si program naparametrizovat. Např. mi nevyhovuje pořadí tlačítek, chci nějaké vyhodit a jiné přidat… a program to sám o sobě nepodporuje → udělám to přes reflexi nějakým skriptem, kterým si vždy patchnu program při jeho spuštění. To by bylo zajímavé, jenže nepříjemné na tom je, že v příští verzi programu by to dost možná přestalo fungovat.

Z hlediska skládání programů a interakce mezi nimi je jednoznačně lepší mít jasně deklarované veřejné API, kde se drží zpětná kompatibilita, a pak interní kód, kde má autor programu volnou ruku a může si tam řádit jak chce, aniž by měl výčitky, že někomu něco rozbije.

[Bystroushaak]

Z hlediska skládání programů a interakce mezi nimi je jednoznačně lepší mít jasně deklarované veřejné API, kde se drží zpětná kompatibilita, a pak interní kód, kde má autor programu volnou ruku a může si tam řádit jak chce, aniž by měl výčitky, že někomu něco rozbije.

Lepší asi jo, ale v případě desktopových aplikací ho nemáš skoro nikdy a i u webů je to spíš výjimka, než pravidlo.

[xkucf03]

U desktopových aplikací mám často buď D-Bus nebo nějaké CLI rozhraní, přes které jde program ovládat. V případě KDE je tam taky jednotný framework pro klávesové zkratky nebo pro oznamování (mj. umožňuje scénář: v aplikaci vznikne událost → spustí se příkaz/skript).

V případě webů je to v první řadě otázka nikoli technologie, ale zda na tom má provozovatel zájem – pokud ten zájem je, tak i s poměrně primitivními technologiemi můžeš udělat dobře použitelné veřejné API.

[Bystroushaak]

V případě webů je to v první řadě otázka nikoli technologie, ale zda na tom má provozovatel zájem – pokud ten zájem je, tak i s poměrně primitivními technologiemi můžeš udělat dobře použitelné veřejné API.

To ano. A většina webů zájem nemá (třeba abclinuxu).

[xkucf03]

O AbcLinuxu bych tohle netvrdil – jde o to, že tady ustrnul jakýkoli rozvoj redakčního systémů, takže ani nikdo nepřidává žádné API. Oproti tomu u jiných webů se redakční systémy vyvíjejí a přidávají různé nesmyslné funkce, zatímco na otevřenost a API se kašle – tam se skutečně dá říct, že na tom zájem není (resp. je dokonce zájem, aby to tam nebylo).

A zrovna Ábíčko má veřejné i zdrojáky systému, takže tam klidně tu funkci můžeš doprogramovat a máš šanci, že to přijmou a nasadí.

[pavlix]

Stalo se s ábíčkem něco pozitivního od doby, co to Luboš pustil?

[xkucf03]

Svým způsobem je pozitivní, že to tu funguje pořád stejně Taky se to mohlo zhoršit (ano, článků je málo, ale to se odvíjí spíš od aktivity/pasivity autorů…).

[pavlix]

Mně na tom osobně už nijak zvlášť nezáleží.

[xkucf03]

V jakém smyslu? Chodíš jinam? Kašleš na tuhle komunitu obecně?

[pavlix]

Nepovažuju za smysluplné jakkoli spoléhat na portál, který patří někomu, kdo není součástí komunity. Komunita taková je tu ze setrvačnosti, kdyby se ten portál takto nově založil, všichni ti lidé sem nepřijdou jen kvůli redakčnímu systému, který se navíc dá ze dne na den spustit jinde, pokud jsem to dobře pochopil.

[Heron]

Nepovažuju za smysluplné jakkoli spoléhat na portál, který patří někomu, kdo není součástí komunity.

+1

[Ivorne]

Díky za zajímavý článek. Taky teď navrhuji jednoduchou knihovnu pro sestavování grafických rozhraní a ukazuje se, že její softwarová struktura by mohla s trochou snahy umožnit celkem zajímavou introspekci (potažmo reflexi), takže zvažuji, kam až to v tomto směru lze dotáhnout a kam až to má cenu dotáhnout. Vpodstatě by se jednalo o podobnou reflexi, jako popisuješ u smalltalku - zobrazení struktury gui a možnost změny atributů objektů, případně vložení či vygenerování nových objektů.

Projevuje se zde i stejný problém, který zmiňuješ u Smalltalku - jak provést persistentní změny (změny, které se projeví i po opětovném otevření okna). To chci řešit tak, že bude možné v programu provést uložení a následné načtení změn, které uživatel provede. Tam je nutná účast programátora používajícího knihovnu, aby definoval kdy a kam (či odkud) se má gui (nebo diff gui od defaultu) ukládat (či načítat).

U výrazně reflexivního gui je jistým problémem možnost, že uživatel zprasí gui tak, že to nebude vůbec použitelné. Největším problémem je, když malá uživatelská změna udělá velkou paseku ve výsledném gui. Proto je potřeba navrhovat knihovnu pro gui tak, aby co nejméně stavů gui bylo nevalidní (očividně nežádoucí). Taky je asi vhodné nabídnout uživateli možnost resetovat nějaké celky gui do defaultního stavu. To bych u své knihovny udělal jako součást systému, který se stará o ukládání a načítání změn gui. To mě přivádí k tomu, že ten systém by mohl umožňovat i vytváření profilů, které může uživatel načítat a modifikovat a tak.

Problémy, které zmiňuješ u Selfu podle mě do značné míry vychází z toho, že nemá žádnou statickou typovou kontrolu. Programátor pak má mnohem větší problém vědět (a mít záruku, že to tak zůstane) odkud objekt pochází (nebo spíš potřebuje vědět odkud pochází) a co se s ním dá dělat. To samozřejmě vychází z tebou popisovaného prototype-based programování. Podle mě by mohlo být zajímavé pokusit se prozkoumat možnosti, jak zavést aspoň minimální statickou typovou kontrolu se současným zachováním prototype-based programování.

Mimochodem celkem zajímavý přístup reflexe uživatelského rozhraní je u internetových stránek. Webové prohlížeče a nějaké doplňky umožňují editovat html stránek a vytvářet pravidla. Není to příliš sofistikovaný systém, ale je to asi jediný přistup, který se adaptoval na jakési praktické využití.