Microui+fenster=Small GUI

227 pointsposted 6 days ago
by surprisetalk

36 Comments

mark_l_watson

5 days ago

Very cool project. I followed some link’s to Max’s personal web site: a renaissance man!

Many decades ago when I worked on a C++ team we hired very smart but not C++ guru employees. I wrote a portable graphics library so team members could write X11 apps without learning details that domain experts really didn’t need to learn. With my company’s permission, I rewrote that code on my own time and added support for Mac, and Windows. That code became the two editions of my Portable GUIs with C++ books for McGraw-Hill.

Sorry to rant so much off topic, but mostly being retired now I have been thinking of getting back into C++ (I usually use Lisp languages and Python now). I think this very cool project will be the start of a few very fun days of playing with C++ again.

tomcam

5 days ago

I loved your books. Very clearly written with complete, usable examples. Models of their kind. I remember very well going into Barnes & Noble and sitting there with the books for a couple of hours before buying them, because it was on my own nickel and books have never been cheap.

mark_l_watson

5 days ago

Thank you!

BTW, all of the eBooks I have written in the last ten years can be read for free (click on book, then ‘Free to Read Online). I try to keep them updated.

https://leanpub.com/u/markwatson

tomcam

5 days ago

Oh, that is fantastic!

npsimons

4 days ago

Holy crap! It's the "Loving Common Lisp" author! Haven't had a chance to finish it yet, but it's awesome and I really appreciate the updates!

jll29

5 days ago

Such boilerfree graphics is important, for example for educational purpose where you don't want to be distracted by having to explain what an "allocator" or a "handle" are.

Also, to keep the core drawing code short so that it can be fully listed on a blog post or in a print magazine.

What I liked is is a self-sufficient set of files that compile immediately without any dependency issues (even on the Mac). There should be more work like that:

- making it even easier to use

- making it simpler and simpler

- making it faster

- making the library footprint smaller

Thanks!

rwbt

6 days ago

It uses Microui lib written by rxi. Checkout other single header only C libs written by rxi[0]. They're really elegant C in my view. [0] - https://github.com/rxi

zamadatix

6 days ago

This is great, particular the fenster side which is truly about as "If you remember Borland BGI or drawing things in QBASIC or INT 10h- you know what I mean" as I've ever seen for cross platform C.

Microui seems very cool as well but not in a "the comments section is very often longer than this code" sense. Still, I'll definitely be poking around with this a bit more for the novelty.

zem

6 days ago

love it :) next step, some tiny scripting language bindings? s7 would fit in well e.g. https://ccrma.stanford.edu/software/snd/snd/s7.html

HexDecOctBin

6 days ago

Does s7 allows for REPL-driven programming? That's the only thing missing from the Lua VM that can't be implemented as a library. An embedded Lisp that supports a true REPL would be a god-send.

npsimons

5 days ago

> An embedded Lisp that supports a true REPL would be a god-send.

I might be misunderstanding your requirements; "embedded" can mean so many things these days. But what do you think of ECL (https://ecl.common-lisp.dev/main.html)?

HexDecOctBin

5 days ago

I am thinking more like Lua where you can create thousands of lua_State, and run them all independently with none of them messing up the global state of the application. Something which is self-contained, portable, runs in a VM, doesn't use global state, whose execution can be controlled from the outside with hooks, etc.

I don't know if ECL is disciplined enough to actually constraint itself in all these ways to be a good embedded citizen.

Esras

5 days ago

Cool project! Graphics programming is _hard_ and anything to make it easier is welcome.

Maybe a dumb question, but why not Dear ImGui (https://github.com/ocornut/imgui). "It's way too big and complex" is a completely reasonable answer, but I found it fantastic for debug menus, and there are a few applications that have used it as their _main_ GUI (Ship of Harkinian as an example).

(Edit for fixing the name of the project)

tekknolagi

5 days ago

I originally wanted to port dear imgui to fenster but that looked difficult and microui already had a very straightforward little bytecode to implement

movedx

5 days ago

Here's something I struggle with: where do I install the C libraries too and then how do you include them? I always want to try these really cool libs, but then I remember that although I know C well enough to try them, I've not solved the ecosystem and dependency management side of developing in C.

Any suggested reading?

tekknolagi

5 days ago

Bundle them into your project. Commit them into your source control

    #include "fenster.h"
    #include "microui.h"
(see main.c and Makefile)

movedx

5 days ago

So you mean just literally put the .h and .c files at '.'?

tekknolagi

4 days ago

Yes; they're small enough that it's reasonable

qmmmur

5 days ago

Welcome to package management in c++

throwaway47765

5 days ago

This sounds awesome. I can't wait to use it with Lua, like lua-fenster.

Or, can I already?

a1o

5 days ago

This is great for some things, is there something small like fenster but written in C?

Or is it just the header there? I see there is both a Cpp and a Go file there too, so I am a bit unsure which does what.

tekknolagi

5 days ago

Fenster is written in C and has an optional C++ wrapper (it's all in the file)

icar

5 days ago

I wonder if they could add Wayland…

tekknolagi

5 days ago

Probably yes, but it wouldn't be upstreamable into fenster. A Wayland impl would at least double the size. I'm vaguely looking into it anyway. Feel free to file an issue

Lerc

5 days ago

API compatibility with fenster would surely be the way to go here. It seems like it has the capacity to grant access to a huge number of platforms, but I'd hate to see it turn into a behemoth of ifdefs for the one codebase to do it all.

Independent implementation of the API would mean you could just release stuff and say "runs on anything that implements the fenster API" and then watch as a RISC OS version turns up somewhere down the track.