Nuklear 1.0 - revoluční GUI knihovna

Micha Mettke po téměř roce a půl vývoje vydal verzi 1.0 revoluční "neknihovny" Nuklear pro precizní tvorbu GUI, a to extrémně jednoduše. Na 15000 řádcích jediného hlavičkového souboru v ANSI C pod MIT naleznete garantovaně multiplatformní Immediate-Mode GUI. Je libo plně funkční a multiplatformní GUI file browser na cca 800 řádcích C? A nebo raději pěkný node editor na cca 600 řádcích?

20.4.2016 07:47 | dumblob | Zajímavý software

Komentáře

[gsnak]

Kus kodu z dema pre xlib vyzera takto:

        XClearWindow(xw.dpy, xw.win);
        nk_xlib_render(xw.win, nk_rgb(30,30,30));
        XFlush(xw.dpy);

Teda ja neviem ale mne to portabilne moc nepride, ved tam ma 4 implementacie (alegro, sdl, x11, glfw) a kazda ma iny kod dema, napr. SDL vyzera ten isty kod takto:

 {float bg[4];
        nk_color_fv(bg, background);
        SDL_GetWindowSize(win, &win_width, &win_height);
        glViewport(0, 0, win_width, win_height);
        glClear(GL_COLOR_BUFFER_BIT);
        glClearColor(bg[0], bg[1], bg[2], bg[3]);
        nk_sdl_render(NK_ANTI_ALIASING_ON, MAX_VERTEX_MEMORY, MAX_ELEMENT_MEMORY);
        SDL_GL_SwapWindow(win);}

Dalej, demo kalkulacka - prvych 300 riadkov kodu su same opengl prikazy, potom nasleduju nk_* prikazy sem tam prelozene riadkom gl prikazov, a konci to mixom gl a nk prikazov. Neviem ale ja si malu chutnu GUI kniznicu predstavujem inak.

[Adam]

To je to, čeho jsem si taky všiml. Ale zase na druhou stranu mi to nedá, abych se v tom nepohrabal. Z popisu na stránkách jsem pochopil, že portabilitu nejspíš chápou jako možnost využít tuhle knihovnu v různých frameworcích při použití různých render backendů. Čili jedna ze základních vlastností je, vůbec neřešit grafiku, ale naopak se přizpůsobit tomu, co programátor/program požaduje.

[MadCatX]

Asi tak. Jde o to, že pokud si chce někdo napsat program s GUI a použít třeba jen X11, nemusí při použití Nuklearu ručně řešit, jak nakreslit zakulacené obdélníky, barevné gradienty a podobně. Moc use-cases to asi mít nebude, ale zrovna mně by se to před pár lety na jednu blbůstku celkem šiklo;)

[mirec]

Práve na nejaké embedded / minimalistické zariadenia si to viem celkom predstaviť.

[Rezza]

Opravdu me neprijde extremne jednoducha knihovna, kde pro jednoduchou kalkulacku na par radku v cemkoliv nekdo resi shadery. Naopak krasna ukazka na QML by to byla :).

[dumblob]

Ty ukazky ukazuji reseni, ktera jsou rychla a zaroven ukazuji co nejvice moznosti nastaveni Nuklear apod. Ten kod by sel o dost zjednodusit a abstrahovat.

Ale diky za postreh, protoze chybi demo s kreslenim na canvas RGB pixelu, ktery by demonstroval built-in kreslici schopnosti Nuklear. Ano, Nuklear ma implementovane vsechny potrebne vykreslovaci funkce, takze neni potrebny vlastne vubec zadny backend. Bez backendu bude vsak vystupem pouze buffer RGB pixelu.

[Ivan2]

Vsechno v jednom souboru? To mi pripomina OTL http://otl.sourceforge.net/. 32K radek v jednom headeru a z toho 5K radek jsou definice prepocesoru.

Dokud to nezacne segfaultovat anebo tam clovek nepotrebuje pridat mutex tak je to moc uzitecna knihovna. Jakmile ale narazite na problemy tak radsi rychle od toho.

[dumblob]

Viz. komentar #24 ohledne uprav a debugovani.

Co se mutexu tyce, tak je Nuklear pripraveny pro paralelni prostredi a pridavani mutexu primo do Nuklear by vubec nemelo byt potreba.

[karelI]

Me spis pripada, ze to ma skoro 20 000 radku. Nicmene na 15 by to snadno dostal kdyby odstranil duplicity...

[dumblob]

Pokud by neslucoval samotny kod Nuklear s podpurnymi stb hlavickami (stb_texedit, stb_truetype, stb_rectpack), tak by vysledna hlavicka byla o dost mensi.

[unicode]

Podle me to v tom jednom souboru do budoucna stejne neudrzi.

[dumblob]

Nejsou planovane velke zmeny. Jedina zmena, ktera by mohla nastat by bylo pridani nejakych "extremne vysoceurovnovych shaderu", ale to by stejne zrejme bylo resene jako dalsi samostatny header a mozna i samostatny projekt.

[dumblob]

Mimochodem, asi nejlepsi zkusenosti (velice dlouhodobe dlouhodobe a extremne seriozni - napr. letecky prumysl) se single-header pristupem maji tvurci SQLite3. Doporucuji precist par historickych blogpostu a mailu v listu pro uklidneni, ze se vlastne jedna o velice dobry koncept.

[petr_p]

Kdybyste odkázal na nějaký z nich, věřil bych vám více. Takhle spíše budu věřit distributorům, kteří se bundlování vyhýbají jak čert kříži. Co mám zkušenosti s SQLite, tak jediné, k čemu jim je to dobré, je, že pak bezostyšně rozbíjejí sémantiku funkcí, což jsem zažil už mnohokrát při aktualizaci SQLite v rámci stabilní major verze.

[dumblob]

Asi nejznámější diskuze o distribuci SQLite v jednom souboru je vevlákně maling listu o blogovém příšpěvku sqlite’s anal gamation včetně snad všech argumentů obou stran, které jsem kdy slyšel. Pro účely SQLite a Nuklear tedy vyplývá, že toto rozhodnutí je pro uživatele a samotný projekt výhodné.

Jinak specifickým typem distributora SW (ať jako balíčkář pro distribuce a Windows, tak jako účastník na vývoji různých programů různých velikostí a nasazení) jsem již několik let a bundlování je z mé zkušenosti velká úleva v případě menších či malých programů (např. SQLite nebo Nuklear).

[dumblob]

Abych předešel nedorozumění, tak k serióznímu použití SQLite i na kritických místech bych rád dodal, že distribuce SQLite v jediném souboru samozřejmě není hlavní důvod úspěchu. Hlavní důvod je vysoce nadprůměrně vysoká kvalita kódu a drsné testování mnoha způsoby testování.

[Tomáš Bžatek]

No nevypada to vubec spatne!

[kralyk z abclinuxu]

To Diablo-like demo je hezké, ale divil bych se, kdyby tím neporušoval nějakej copyright...

[Jardík]

Takže OpenGL ... kdysi jsem koukal na jednu, bylo to ale v C++, taky immediate mode, a bylo to kupodivu rychlé ...

[dumblob]

Vykreslovat muzes cimkoliv, takze zadne OpenGL neni potreba. Klidne si tim kresli UI primo do PNG souboru.

[BFU]

Obavam se, ze pokud se ten header naincluduje do vice souboru, dojde k duplikaci symbolu v binarce.

[Josef Kufner]

A včem se to tedy odlišuje od všeho ostatního?

[dumblob]

Viz. Features (zejmena: immediate mode UI, single header, tiny, extremely portable thanks to C89 and fully rendering-agnostic architecture, no hidden state).

[Odin1918]

Implementaci cpat do hlavickoveho souboru? 15000 radek v jednom souboru? Tak se dneska pise software, ktery je oznacen za revolucni? Ja uz jsem mimo it asi opravdu uz dlouho, ten pokrok je opravdu znat.

[Adam]

Nedokážu posoudit výhody vs. nevýhody, ale v poděkování autor píše:

... and Sean Barret for his amazing single header libraries which restored my faith in libraries and brought me to create some of my own.

Bližší info od nejspíše zmíněného Sean Barreta zde.

[kralyk z abclinuxu]

Ten člověk zřejmě v životě neslyšel o statickém linkování. Jinak by si ušetřil spoustu práce...

[unicode]

Staticke linkovani v linuxu je nekdy ale pekny zazitek, hlavne pokud nekdo zapomnel na "-fPIC".

[pavlix]

Já v tom žádný velký zážitek nevidím, dynamické linkování mi přijde dobrodružnější.

[kralyk z abclinuxu]

Staticke linkovani v linuxu je nekdy ale pekny zazitek, hlavne pokud nekdo zapomnel na "-fPIC".

No tomu člověku se jedná hlavně o windows, zřejmě.

[dumblob]

Ano, jedna se o multiplatformni reseni. A o nicem lepsim z pohledu maximalni multiplatformnosti nez single-header jsem jeste neslysel.

[kralyk z abclinuxu]

Jaký to má výhody oproti staticky nalinkované knihovně? Vidím akorát nevýhody, např. to těžce neškáluje.

[dumblob]

Hlavní výhoda je naprostá nezávislost na kompilátoru, což pro knihovnu, která není určena pouze pro tři nejrozšířenější kompilátory (GCC, LLVM a MSVC) naprosto klíčová vlastnost.

Se škálováním nevidím sebemenší problém (je triviální zařídit, aby ve výsledné binárce nedocházelo k duplikaci a Nuklear samozřejmě nic neduplikuje).

Ale mohl jsem výtky špatně pochopit. Pokud jsem je však pochopil správně, tak bych uvítal, aby si všichni nejprve před psaním neopodstatněných výtek přečetli alespoň Readme, protože tyhle maličkosti jsou tam samozřejmě popsané. Ábíčko nám opravdu hodně kleslo

[pavlix]

Hlavní výhoda je naprostá nezávislost na kompilátoru, což pro knihovnu, která není určena pouze pro tři nejrozšířenější kompilátory (GCC, LLVM a MSVC) naprosto klíčová vlastnost.

RLY? Ostatní kompilátory neumějí kombinovat více céčkovských souborů?

[dumblob]

Neřešíme co kompilátory umí a neumí. Řešíme naprostou nezávislost nuklear.h na kompilátoru. Tedy pokud nechci pro každý pidi kompilátor na světě (a že jich jsou stovky v produkčním nasazení) psát multiplatformní Makefile nebo návod jak daný kompilátor donutit staticky přilinkovat nuklear.h, pak je tohle jediné mně známé řešení.

[pavlix]

K tomu nemám slov. A to jsi před chvílí kritizoval kvalitu komentářů.

[dumblob]

Rád bych zvýšil kvalitu, ale nevím jak jinak vysvětlit rozdíl mezi garantováním plné funkcionality Nuklear pod všemi používanými kompilátory (díky využití základní standardizované vlastnosti jazyka C89 - tedy includování hlaviček) a mezi podporováním vybraného omezeného množství kompilátorů, protože standard C89 nic neříká o standardním rozhraní pro donucení kompilátoru kompilovat tuto konkrétní knihovnu staticky.

Poraď tedy prosím jak jinak mám tuto problematiku vysvětlovat.

[Adam]

Tak jsem si to v rychlosti prošel. Pochopil jsem to takto (body píšu s otazníkem, protože si nejsem zcela jist, že to tak je, nebo že to tak je za všech okolností):

• základem je vykreslovací smyčka, která se spouští každých x ms?
• smyčka obsahuje řadu funkcí, kterými se pro každý frame znovu sestavuje celé GUI (buď přímo nebo z cache)?
• u složitějších GUI s řadou stavů to znamená mít rozvětvené if/else a přidat do GUI to, co je dle stavu potřeba?
• nutnost překreslení nebo vytažení z cache si řídí knihovna sama (pamatuje si stav proměnných z minulého framu)?
• vstupy myši a klávesnice si řídím sám a posílám je do kontextu ve formě stisknutých kláves, tlačítek a pozice myši (může se stát, že mezi jedním a druhým framem dojde ke zpoždění během kterého bylo několikrát stisknuto tlačítko a GUI to nepozná)?
• polohu prvků a jejich velikost je možné nastavit dynamicky (pomocí funkcí pro rozvržení - layout).
• prvky mají svojí hierarchii, která řídí viditelnost (které prvky jsou nad kterými), (nutnost překreslení), zachytávání událostí ze vstupu?
• výsledkem volání knihovny je buffer pixel, který si mohu vykreslit kam chci a jak chci?
• pokud v prvku (například textové pole) uživatel stiskne klávesu a tím dojde ke změně (přidání znaku), výsledkem je změna řetězce obohaceného o nový znak, který se zobrazí až při dalším framu?
• vzhled prvků lze měnit (vzhled prvků lze načíst z externího zdroje)?

[dumblob]

základem je vykreslovací smyčka, která se spouští každých x ms?

Ano, to je jedna z variant. Lepsi reseni je vsak cekat na podnet, ktery muze potencialne zmenit zobrazovany obsah (napr. klavesnicovy/mysovy/joystick/... vstup nebo zmena zobrazovanych dat v real-time grafu, ...) a mit nejaky minimalni cas, po ktery se tyto pozadavky sbiraji a az pote se spusti rendering.

smyčka obsahuje řadu funkcí, kterými se pro každý frame znovu sestavuje celé GUI (buď přímo nebo z cache)?

Ano. Kesovani je v Nuklear naprosto minimalni, protoze dle testu je sestaveni prumerne komplexnich GUI vyrazne rychlejsi nez by bylo udrzovani cache. Predpoklada se vsak, ze kesovani probiha na strane renderovaciho kodu, ktery si muze docela jednoduse diffovat

u složitějších GUI s řadou stavů to znamená mít rozvětvené if/else a přidat do GUI to, co je dle stavu potřeba?

Ano. Samozrejme lze pouzit mnoho z vyssich abstrakci - a to ani nemluvim o modernich vyssich programovacich jazycich (skrze bindings). Oproti beznym "retained mode" UIs vsak neni nutne napsat tolik kodu a tak hodne ho abstrahovat a strukturovat.

nutnost překreslení nebo vytažení z cache si řídí knihovna sama (pamatuje si stav proměnných z minulého framu)?

Ano, od toho je struktura nk_context (pro OOP orientované lidi se jedná o Cčkovou variantu instance třídy s metodami).

vstupy myši a klávesnice si řídím sám a posílám je do kontextu ve formě stisknutých kláves, tlačítek a pozice myši (může se stát, že mezi jedním a druhým framem dojde ke zpoždění během kterého bylo několikrát stisknuto tlačítko a GUI to nepozná)?

Pokud se využívá tvrdý interval čekání (spánek procesu) a až poté se jednorázově vyčte aktuální stav vstupů, tak ano. Ale tohle dnes téměř žádná I/O knihovna nedělá (ani xlib) a všechny vstupy se bufferují a poté si je samozřejmě jeden po druhém zpracuješ z bufferu. Kromě toho je doporučené na tyhle vstupy čekat (viz. odpověď na první otázku) a nikoliv používat pevný interval čekání.

polohu prvků a jejich velikost je možné nastavit dynamicky (pomocí funkcí pro rozvržení - layout).

Ano. A s pomocí např. Cassowary algoritmu lze být zcela DPI agnostický (mimochodem Cassowary se používá v Apple SW již několik let a to velice úspěšně).

prvky mají svojí hierarchii, která řídí viditelnost (které prvky jsou nad kterými), (nutnost překreslení), zachytávání událostí ze vstupu?

Nejsem si jistý, zdali chápu dobře otázku. Programátorsky prvky nemají žádnou hierarchii, ale samozřejmě Nuklear poskytuje "widget" kontejnery (např. pro dynamické změny šířky a výšky), které do sebe pohlcují další prvky (ať již běžné či znovu kontejnery). Viditelnost je řízena pořadím kreslení prvků (co je vykresleno později překrývá předchozí). Interně se používá naprosto všude clipping, takže ve skutečnosti se při finálním renderingu nic nepřekrývá a nejedná se tedy o malířův algoritmus.

výsledkem volání knihovny je buffer pixel, který si mohu vykreslit kam chci a jak chci?

Ne. Výsledkem je správně uspořádaný seznam "high level shader-like instrukcí" (queue of commands - viz. nk_command_*; přehled všech command types je v enumeraci nk_command_type). Nuklear nabízí ještě možnost interně automaticky převést tyto instrukce do low-level podoby vertex bufferu, ale myslím, že to v žádném demu není použité. Vertex buffer se hodí např. pro embedded použití.

pokud v prvku (například textové pole) uživatel stiskne klávesu a tím dojde ke změně (přidání znaku), výsledkem je změna řetězce obohaceného o nový znak, který se zobrazí až při dalším framu?

Ano.

vzhled prvků lze měnit (vzhled prvků lze načíst z externího zdroje)?

Ano. Lze přeskinovat každý widget jakoukoliv bitmapou. Ale není to nutné - kromě bitmapového skinu lze velice detailně nastavit barvu všech možných geometrických součástí widgetů a výsledky jsou vidět v Readme.

[Adam]

Díky za skvělou odpověď.

Ještě bych se vrátil k bodu s hierarchií. Jde mi o to, jestli se bude muset ručně hlídat pořadí vykreslování a tím pádem překryv jednotlivých prvků, nebo se dá určit z-index. Napadá mě třeba vykreslení kontextového menu, nebo jiných vyskakovacích prvků.

Případně jestli se bude muset ručně hlídat komu poslat vstupy (klávesnice, myš), tak aby interagovali jen s vybranými prvky nebo mi v tomto knihovna nějak pomůže. Například řídí, které prvky mají fokus a vstupy propustí jen do nich. Což může být ale i více prvků - většinou právě nějaký kontejner a jeho prvek. Napadá mě třeba: kolečkem lze rolovat až na konec textového pole a v případě, že je již dosažen konec, tak se začne při tom stejném vstupu kolečka, rolovat stránka (ne že bych zrovna tuhle vlastnost GUI měl rád :).

[dumblob]

Díky za skvělou odpověď.

Ještě bych se vrátil k bodu s hierarchií. Jde mi o to, jestli se bude muset ručně hlídat pořadí vykreslování a tím pádem překryv jednotlivých prvků, nebo se dá určit z-index. Napadá mě třeba vykreslení kontextového menu, nebo jiných vyskakovacích prvků.

Z-index momentálně určit nelze, ale toto je vyřešeno abstrakcí "skupin", které jsou nezávislé na pořadí volání widget funkcí. Tyto skupiny mají poté rúzné vlastnosti a pořadí, ve kterém jsou vykresleny a díky nezávislosti na pořadí volání widget funkcí lze docílit libovolného překrytí. Přijde mi to výrazně flexibilnější než z-index.

Případně jestli se bude muset ručně hlídat komu poslat vstupy (klávesnice, myš), tak aby interagovali jen s vybranými prvky nebo mi v tomto knihovna nějak pomůže. Například řídí, které prvky mají fokus a vstupy propustí jen do nich. Což může být ale i více prvků - většinou právě nějaký kontejner a jeho prvek. Napadá mě třeba: kolečkem lze rolovat až na konec textového pole a v případě, že je již dosažen konec, tak se začne při tom stejném vstupu kolečka, rolovat stránka (ne že bych zrovna tuhle vlastnost GUI měl rád :).

Nuklear v kontextu udržuje informaci o stavu widgetů (viz. enumerace nk_widget_states, zejména pak stav NK_WIDGET_STATE_ACTIVE, což je "focus") a programátor se o to nemusí starat. Modelový příklad je tedy bezproblémově realizovatelný (nekontroloval jsem však nyní, zdali zrovna textový widget má funkci/metodu pro jednoduchou detekci viditelného kurzoru úplně na konci a nebo zdali si tuto informaci musí programátor vyčíst z interních struktur kontextu). Každopádně co se např. přepínání focusu mezi widgety týče, doporučím Keyboard Navigation / Gamepad.

[Jiří J.]

Pořád čekám, až někdo udělá skutečně jednoduchou knihovnu na použití.

Kdykoli jsem se o GUI pokoušel (Xlib, Gtk, Qt, z C/C++ nebo pythonu), přišlo mi, že píšu vlastní operační systém. Vlastně ne, linux kernel kód vypadá přehledněji, než ta spousta maker, vlastních datových typů a já nevím čeho ještě. Když se pak človek rozhoduje, zda udělat jednoduché CLI rozhraní, nebo jednoduché GUI rozhraní, tak je CLI jasná volba, protože pro tvorbu GUI bych si musel vybrat zbytek dovolené.

Přitom nepotřebuji úplně generické API, nepotřebuji přistupovat k registrům GPU, chci prostě jen něco jako Zenity pro C/python. A zatím jsem všude musel nastavovat šířku okraje okna, eventy/masky, šťourat se v dokumentaci a číst po dlouhých nocích API reference, protože v těch vlastnostech každého objektu, aby se čert vyznal, ...

Hele já se fakt raději vrátím k readline.

[dumblob]

C: http://ftp.gnome.org/pub/gnome/sources/zenity/ (Zenity samotné je totiž napsané v C) Python: https://pypi.python.org/pypi/python-zenity/0.1.2

Jinak těmto triviálním "udělátkům" bych si určitě nedovolil říkat GUI knihovny, nýbrž bych se držel standardního označení dialogové nástroje a možná přidal ještě přívlastky "velice omezené a zjednodušené".