Microui+fenster=Small GUI | Hacker News Reader

Microui+fenster=Small GUI

bernsteinbear.com

231 pointssurprisetalk36 comments

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.

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.

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

Oh, that is fantastic!

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!

Thank you.

You probably want to use simd-optimized pixman[1] for rendering rectangles and glyphs. There is also luigi[2] which draws without opengl and written in C.

[1] https://github.com/freedesktop/pixman [2] https://github.com/nakst/luigi

the pixman link isn't working

https://gitlab.freedesktop.org/pixman/pixman

Upstream is https://gitlab.freedesktop.org/pixman/pixman

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!

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

Oh I knew him from ludum dare

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.

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

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.

Yes, it seems to be possible to use it in Emacs like any other Scheme [0].

Not sure how these facilities compare to Slime + Common Lisp.

[0]: https://ccrma.stanford.edu/software/snd/snd/s7.html#repl

This just seems like a regular REPL instead of REPL-driven (with a condition system, restarts, etc.)

> 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)?

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.

Or PocketPy Or fe

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)

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

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?

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

    #include "fenster.h"
    #include "microui.h"

(see main.c and Makefile)

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

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

Welcome to package management in c++

crying.gif

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

Or, can I already?

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.

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

I like it! Bravo!

I wonder if they could add Wayland…

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

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.

Reply on news.ycombinator.com