Reflexe grafických rozhraní (diskuse)

[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í.