41–50 of 91 posts
This is included in the Odin vendor libraries, it's fantastic for Raylib debug menus
https://github.com/raysan5/raygui
But I found it pretty straightforward (and satisfying) to just build my own gui functions/widgets with raylib (inspired by raygui).
https://github.com/dsego/strobe-tuner/blob/main/app/gui.odin
anyone working on bindings to other languages? (go, python, ruby, etc)
Earlier quoted context omitted.
Not very smart. I would go further and say that even full unicode support could be avoided and a software can still be massively useful. It is sad that the world is so hung up on unicode and things like accessibility that we all have to submit to the tyranny of browser layers!
> sad that the world is so hung up on unicode It is sad that the world is hung up on enabling 2/3rds of the world population to read and write text! If only the entire world catered to America. Nobody should ever speak anything other than English, honestly.
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
Is there any game engine out there with good accessibility support for their UI?
The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.
No. As much as I would like it to be the case, that is most certainly a poor criteria to evaluate a UI library. Dear ImGui [0] is without a doubt the most prevalent immediate mode UI library. It does not have native accessibility features, but that hasn't stopped companies such as Intel, Meta, IKEA and Google from shipping products built upon it. It's also used in a ton of games. Calling Dear ImGui a toy project at t…
I judge software harshly that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps). I definitely choose technologies to use based on whether they can be accessible with a little extra effort on my part. I'm not necessarily good at it, it's a complicated topic, but when I get bug reports about an accessibility issue I tend to drop everything else and try to fix it.
I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Immediate-mode in pure C is a nice constraint. how does it handle text rendering, do you bring your own atlas or is there something built in? Thats usually the part that balloons the dependency footprint.
The demo uses a simple prebuilt fixed-size font atlas texture and renders the entire UI (including character quads) via batched glDrawElements calls (one draw call per clip-rect). But the way how text rendering is delegated to the user is quite flexible, microui basically calls these three user-provided functions: int r_get_text_height(void) int r_get_text_width(const char* text, int len); void r_draw_text(const char…
Earlier quoted context omitted.
"Accessibility" is an open-ended set of functionality, not a checkbox; it is never "complete", there is always room for improvement. Colorblind support (which ones)? High-Contrast mode? Adjustable text size? Screenreader integration? Localization? IME support? Keyboard navigation? Keyboard remapping? Functional entirely without a keyboard? Touch support? Pen support? Dyslexia-aiding typefaces? The list goes on and on…
This is one of the reasons why web technology is so popular and persistent. You get almost all of that for free as long as you use semantic HTML.
Immediate-mode in pure C is a nice constraint. how does it handle text rendering, do you bring your own atlas or is there something built in? Thats usually the part that balloons the dependency footprint.
The demo uses a simple prebuilt fixed-size font atlas texture and renders the entire UI (including character quads) via batched glDrawElements calls (one draw call per clip-rect). But the way how text rendering is delegated to the user is quite flexible, microui basically calls these three user-provided functions: int r_get_text_height(void) int r_get_text_width(const char* text, int len); void r_draw_text(const char…