Portál AbcLinuxu, 5. května 2025 14:57
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?
Tiskni
Sdílej:
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.
20.4.2016 13:37
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Práve na nejaké embedded / minimalistické zariadenia si to viem celkom predstaviť.
20.4.2016 10:16
Rezza | skóre: 25
| blog: rezza
| Brno
20.4.2016 17:29
Tomáš Bžatek | skóre: 29
| Brno
No nevypada to vubec spatne!
20.4.2016 22:29
Josef Kufner | skóre: 70
... 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.
21.4.2016 12:08
pavlix | skóre: 54
| blog: pavlix
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ě.
22.4.2016 13:12
pavlix | skóre: 54
| blog: 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ů?
22.4.2016 13:37
pavlix | skóre: 54
| blog: pavlix
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.základem je vykreslovací smyčka, která se spouští každých x ms?
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 diffovatsmyčka obsahuje řadu funkcí, kterými se pro každý frame znovu sestavuje celé GUI (buď přímo nebo z cache)?
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.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, od toho je struktura nk_context (pro OOP orientované lidi se jedná o Cčkovou variantu instance třídy s metodami).nutnost překreslení nebo vytažení z cache si řídí knihovna sama (pamatuje si stav proměnných z minulého framu)?
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í.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á)?
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ě).polohu prvků a jejich velikost je možné nastavit dynamicky (pomocí funkcí pro rozvržení - layout).
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.prvky mají svojí hierarchii, která řídí viditelnost (které prvky jsou nad kterými), (nutnost překreslení), zachytávání událostí ze vstupu?
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í.výsledkem volání knihovny je buffer pixel, který si mohu vykreslit kam chci a jak chci?
Ano.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. 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.vzhled prvků lze měnit (vzhled prvků lze načíst z externího zdroje)?
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.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.