25 comments

[ 5.3 ms ] story [ 39.6 ms ] thread
I chuckled at, "And, yes, it can run Doom!"
Hahaha, so it makes sense that DOOM can be run anywhere.
This is exciting. This is great for data visualization and financial applications!
Looks neat! I’m using C in a little side project and it would benefit from a simple GUI, let’s see what I can do with this. Also, just a recommendation but there isn’t even a single screenshot and I’d say that’s pretty important in a GUI library.
there are always tons of imgui-like libs.
Could be cool, but if it is supposed to be a single header file it should say that instead of 'minimal'.

Also if it's just about getting a single window up with a pixel buffer it should say that.

Top priority should be getting screenshots on the github landing page.

The problem is that the title says "cross-platform GUI", so some people would expect, you know, a GUI - windows, menus, text, buttons, sliders, scrollbars, input fields, etc...

This is more like a cross platform canvas on which you can draw.

Raylib was my goto for that, but an alternative can't hurt, I guess ?

There's an accompanying blog post at https://zserge.com/posts/fenster/

This author has some pretty cool stuff, like a tiny alternative to Firebase https://zserge.com/posts/pennybase/

There is at least two bugs in the blog post, here:

Next simple task would be to fill the complete framebuffer with a solid colour:

    memset(f->buf, rgb, f->width*f->height*sizeoof(uint32_t));
The first is the obvious typo around `sizeof`, which I didn't even see at first (edit: this).

The second is that code will only work for 8-bit colors, i.e. only the 8 (technically CHAR_BIT, "a byte") least-significant bits of `rgb` will be used. This is a quirk of the `memset()` standard C function, which has the prototype:

    void *memset(void s[.n], int c, size_t n);
but then the man page [1] says:

The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c.

[1]: https://man7.org/linux/man-pages/man3/memset.3.html

> API is designed to be a polling loop

IMO this is a mistake. The most popular platform in the world does not allow using a polling loop. You can hack things to simulate it but eventually you'll run into where this will break for you. Better to start with something more forward compatible.

The most popular platform in the world does not allow using a polling loop

I don't know what that means, but just because something else doesn't use a polling loop doesn't mean it's a mistake or the wrong fit.

Something like this so simple there is likely to be a lot that gets done inside the main loop, not the least of which is drawing into the buffer which is most of the point.

I assume you mean the web? I’m not sure why that’d be relevant to a C library.
why hell would you use a c library to make a gui on the web when you have HTML ?
Does it really not support this though? I imagine this could be made to work in a WebWorker for example, where you can run the busy loop, and actively let it ingest new messages each iteration.
Good thing this isn't a library designed for the web then! What's your point here? SDL (this project seems to be a subset of it, in terms of functionality) also uses a polling loop, and it's one of the most popular libraries of this sort around.
That's not a GUI. It's something a GUI might be implemented in.
A windowing library, not a GUI library.
40 years ago, I cut my teeth on graphics programming in x86 assembly language and Turbo Pascal. Little graphical plots are just a really fun way to learn a language and programming concepts.

This is exactly what I want to practice some Zig programming.

> Fenster /ˈfɛnstɐ/ -- a German word for "window".

Same in Afrikaans as well - "venster"[1] means window.

no single facet of this that I don't love
not connected to this, but i wish i would find a c code example on how to draw a line with a width, without antialias while only setting each pixel once. this seems to be a real hard problem.
This can be more accurately described as a hack: there are subtle bugs (e.g. CLOCK_REALTIME is not monotonic) and corner cases that are not taken into account that I can't find any strong reasons to recommend this. One would be better served by something like SDL or raylib or if minimalism is a strict requirement, RGFW [1].

[1] https://github.com/ColleagueRiley/RGFW/blob/main/RGFW.h

Where's the GUI part? This seems like a more limited SDL. There is literally zero GUI code in there, unless you count manually drawing individual pixels a GUI. The shape drawing example (NOT part of the library) shows code using the library to draw basic shapes pixel-by-pixel. That is the very thing a GUI library is supposed to do for you.