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.
Neato! It's nice to find zserge around. He built upon the idea of my static site generator Zas [0] to create his own zs [1][2] a few years ago. I think he's still using it :)
> That's not a GUI. It's something a GUI might be implemented in.
A GUI library is indeed not a GUI, but a library with which one might implement a GUI.
Usually, a GUI library does have things like actual controls implemented, but then most GUI libraries tend to present themselves as something closer to complete than most minimal.
It is unusual but not unreasonable to describe the combination of cross-platform canvas + keyboard/mouse events + audio playback as the “most-minimal GUI library”.
> A GUI library is indeed not a GUI, but a library with which one might implement a GUI.
This definition basically blurs the distinction between a "GUI library" and "graphics library". A GUI library is GTK, QT and others. A graphics library is usually divided into 3D like *GL variants and 2D like SDL or Skia or thousands of others (including this one).
> A graphics library is usually divided into 3D like *GL variants and 2D like SDL
OpenGL (what I assume you are referring to by *GL) is both 2D and 3D; it also, as one might expect of purely a graphics library, doesn't provide control events or audio and considers that something else's problem.
SDL ("Simple DirectMedia Layer") does do things like control events and audio, but does not describe itself as a graphics library, but as "a cross-platform library designed to make it easy to write multi-media software, such as games and emulators."
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.
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.
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 ?
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].
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.
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.
This can be a forward compatibility concern: imagine we run a company, and our product is a GUI app written in C or C++.
If we also believe that the desktop GUI apps are a thing of the past, and in the future everyone wants only web apps, we'd want to pick a C library for the UI which allows building for the web, for the future scenario where we have to port the app to stay relevant.
The scenario might not materialize, but having a contingency plan sure feels nice.
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.
The Web runs C via WebAssembly, but if you're porting a polling loop app you're going to have a bad time. Conversely, if you start with an event driven app then you lose nothing but gain portability.
Yes, because it's trivial to make an event based loop from a polling loop but not visa-versa. The difference is that an event based loop needs to give up control to the OS. A polling loop does not. So if you have a polling OS you just write few lines to emit your own loop event.
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.
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.
That's not surprising as Afrikaans is highly related to Dutch which is in turn highly related to German. In this case it all comes from the Latin fenestra.
Ah - you are conflating Germanic for German. Germanic is not equivalent to German. German (deutsch) is a national language, Germanic is a language family. German belongs to this family, but it is not the root of all Germanic languages. English and German sit in the West Germanic branch, the East Germanic was mostly Gothic (dead) and the North Germanic languages are Swedish/Danish/Norwegian/Icelandic/Faroese and various other non national languages. English is a West Germanic language, but it was massively influenced by Old Norse (North Germanic) and various Frenches (and Latin/Greek in technical terms) as well as probably the native British languages somewhat in grammar (the present continuous tense in English also happens in Welsh, and is not very Germanic.)
So - Window is Germanic. It comes from Old Norse 'vindauga', and the modern Norwegian Bokmal version is 'vindu'[1].
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:
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:
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
It will fill the screen with any of 256 shades of grey, for which r == g == b.
Neato! It's nice to find zserge around. He built upon the idea of my static site generator Zas [0] to create his own zs [1][2] a few years ago. I think he's still using it :)
[0]: https://github.com/darccio/zas
[1]: https://github.com/zserge/zs
[2]: https://zserge.com/posts/new-site-generator2/
That's not a GUI. It's something a GUI might be implemented in.
> That's not a GUI. It's something a GUI might be implemented in.
A GUI library is indeed not a GUI, but a library with which one might implement a GUI.
Usually, a GUI library does have things like actual controls implemented, but then most GUI libraries tend to present themselves as something closer to complete than most minimal.
It is unusual but not unreasonable to describe the combination of cross-platform canvas + keyboard/mouse events + audio playback as the “most-minimal GUI library”.
> A GUI library is indeed not a GUI, but a library with which one might implement a GUI.
This definition basically blurs the distinction between a "GUI library" and "graphics library". A GUI library is GTK, QT and others. A graphics library is usually divided into 3D like *GL variants and 2D like SDL or Skia or thousands of others (including this one).
> A graphics library is usually divided into 3D like *GL variants and 2D like SDL
OpenGL (what I assume you are referring to by *GL) is both 2D and 3D; it also, as one might expect of purely a graphics library, doesn't provide control events or audio and considers that something else's problem.
SDL ("Simple DirectMedia Layer") does do things like control events and audio, but does not describe itself as a graphics library, but as "a cross-platform library designed to make it easy to write multi-media software, such as games and emulators."
It’s not just a graphics library because they provide cross-platform access to input events, timers, as well as audio playback.
So does SDL, but that's still not a GUI lib. I'm honestly not sure what the best term for that is.
In the past we used the term "multimedia library".
Its a graphics primitive library, which can be used to implement a user interface.
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.
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.
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 ?
I don't think this is an alternative to raylib. The whole single header file is 13KB. It is basically a window, rgb buffer, and keyboard+mouse input.
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
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.
A windowing library, not a GUI library.
A graphics primitive library, not a windowing library.
> 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.
Which one are you referring to?
I'm assuming they mean the web.
Oh! Of course
why hell would you use a c library to make a gui on the web when you have HTML ?
This can be a forward compatibility concern: imagine we run a company, and our product is a GUI app written in C or C++.
If we also believe that the desktop GUI apps are a thing of the past, and in the future everyone wants only web apps, we'd want to pick a C library for the UI which allows building for the web, for the future scenario where we have to port the app to stay relevant.
The scenario might not materialize, but having a contingency plan sure feels nice.
Maybe it was a personal goal?
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.
I assume you mean the web? I’m not sure why that’d be relevant to a C library.
The Web runs C via WebAssembly, but if you're porting a polling loop app you're going to have a bad time. Conversely, if you start with an event driven app then you lose nothing but gain portability.
Okay -- this code is pathologically minimal. If you modify it to use events on the web, will your work extend to all the other platforms?
Yes, because it's trivial to make an event based loop from a polling loop but not visa-versa. The difference is that an event based loop needs to give up control to the OS. A polling loop does not. So if you have a polling OS you just write few lines to emit your own loop event.
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.
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.
http://homepages.enterprise.net/murphy/thickline/index.html
pascal not C but you should be able to translate it pretty easy.
You want to define a parallelogram or rectangle, turn it into edge equations, then iterate the spans.
Alternative is bresenham then for each point iterate a span in the minor axis.
I chuckled at, "And, yes, it can run Doom!"
Hahaha, so it makes sense that DOOM can be run anywhere.
> Fenster /ˈfɛnstɐ/ -- a German word for "window".
Same in Afrikaans as well - "venster"[1] means window.
That's not surprising as Afrikaans is highly related to Dutch which is in turn highly related to German. In this case it all comes from the Latin fenestra.
> Latin fenestra.
Hence defenestrate, to throw out the window.
Fenêtre in French.
Funny, English words often come from either German or French. Here where German and French agree, English is different.
https://en.wiktionary.org/wiki/window#Etymology (missing sources as of right now)
Ah - you are conflating Germanic for German. Germanic is not equivalent to German. German (deutsch) is a national language, Germanic is a language family. German belongs to this family, but it is not the root of all Germanic languages. English and German sit in the West Germanic branch, the East Germanic was mostly Gothic (dead) and the North Germanic languages are Swedish/Danish/Norwegian/Icelandic/Faroese and various other non national languages. English is a West Germanic language, but it was massively influenced by Old Norse (North Germanic) and various Frenches (and Latin/Greek in technical terms) as well as probably the native British languages somewhat in grammar (the present continuous tense in English also happens in Welsh, and is not very Germanic.)
So - Window is Germanic. It comes from Old Norse 'vindauga', and the modern Norwegian Bokmal version is 'vindu'[1].
The German word for Window comes from Latin [2].
[1] https://en.wiktionary.org/wiki/vindu
[2] https://en.wiktionary.org/wiki/fenster
yeah, ok, my picture of these things was a bit simplistic, thanks for the correction and the details!
Finestra in Catalan, and Langas in Lithuanian.
Fönster in Swedish.
Okno in Slovak
no single facet of this that I don't love
This is exciting. This is great for data visualization and financial applications!