91–100 of 103 posts
Earlier quoted context omitted.
Font is one thing. The hard part is text layout which is a very very complicated affair, especially if you want to support different languages and/or writing systems.
Yeah this. Once you get to something more than plain English, it means pulling in HarfBuzz
Earlier quoted context omitted.
This one is 1100 lines of code, nice for embedded project. A nice font renderer is orders of magnitude more code, e.g., harfbuzz 25,000 lines of code with or FreeType with 245,000 lines of code. Many projects do not want that kind of bloat. I'd guess some of these little ones allows using your own bmp font, so render a font you like, and use the rendered glyphs.
>Many projects do not want that kind of bloat. It isn't bloat if it's desired functionality. Not every project is optimized to run in an embedded environment, nor does it need to be.
And if you in particular want it, fork them and merge them.
Earlier quoted context omitted.
> To be honest though, I'm at the point where I'd really prefer an easy and lightweight library to setup a http and/or websocket server, and just make a ui in the browser. Wouldn't that mean that the expiry date of your GUI is like: a few years or so? Since web-stuff seems to change so constantly with breaking changes and revamps every few years being the norm. Whereas a WIN32 app (or Unix or other) from 25 years ago…
nah, compatibility is longer than a few years. it can be practically impossible to deprecate stuff, even. you see a lot of churn in the web ui world because browsers implement new features that new libraries take advantage of. it seems to be stabilizing a bit around react. the developers in the space do tend to reinvent the wheel more. it's not that big of a deal to me though, because it's a pet project, not a profes…
Also because of design language evolution (whether this is “fashion” or “advances in usability research” is a debate I’ll sidestep here); the old stuff still works fine, it just isn’t current style; if all you care about is “UI that works” and not “UI that looks and feels current”, web isn’t a bad target.
> * Written in C89 (ANSI C) Just why. C17 exist. Why is is that some developers stick with C89, whilst in the C++ community, unless you work for some really backwards company, you adopt the latest standard before it's even officially nailed down? C89 needs to die. Stop supporting it.
They are awaiting your pull request. Have at.
> Reviewing changes to src/* and nuklear.h:
> Ensure C89 compatibility
I really like this trend. Also see: * Raylib - A single header file game engine https://www.raylib.com/ * Miniaudio - A single header file audio library https://miniaud.io/ Both (actually, not just three systems) cross-platform. For their design and cross-platform support they make for great bases for Go libraries, unlike most C code out there.
Having a peep at miniaud.io, I am astounded to say the least. It supports almost all of the popular back-ends across platforms. A library as complex as PortAudio in a (largish) header.
I really like this trend. Also see: * Raylib - A single header file game engine https://www.raylib.com/ * Miniaudio - A single header file audio library https://miniaud.io/ Both (actually, not just three systems) cross-platform. For their design and cross-platform support they make for great bases for Go libraries, unlike most C code out there.
I can't say I'm excited about this trend, if it is a trend. Immediate mode GUIs are usually pretty nice from a developer point of view, but many of them are lacking many things like accessibility and text selection. Maybe good for 3D modelers, video editors, etc., but not for more general purpose apps.
For accessibility I think that's sadly a part that people in general don't seem to care a lot. And while some of the big libraries do a lot for you there, it also depends a lot on how it really is used. The trend to Electron and others also isn't really helping there.
To be fair though, I am happy about the trends that this topic is actually something people even are aware of. Five, ten, fifteen years ago this was very different. I remember a time when using HTML over Flash for accessibility reasons was considered a non-argument. Now you see that topic brought up "a lot".
Earlier quoted context omitted.
In the pathological case, the steam overlay needs zero effort to "implement". It works out of the box in most cases when the application is launched via the Steam launcher.
It only works for DirectX, OpenGL, Metal, Vulkan: https://partner.steamgames.com/doc/features/overlay It also uses heuristics to find the right window that can lead to issues. Not a common problem, but one I unfortunately ran into :(
Earlier quoted context omitted.
I can't say I'm excited about this trend, if it is a trend. Immediate mode GUIs are usually pretty nice from a developer point of view, but many of them are lacking many things like accessibility and text selection. Maybe good for 3D modelers, video editors, etc., but not for more general purpose apps.
The trend I was talking about is small, well-designed simple to use, truly cross-platform header only libraries. For accessibility I think that's sadly a part that people in general don't seem to care a lot. And while some of the big libraries do a lot for you there, it also depends a lot on how it really is used. The trend to Electron and others also isn't really helping there. To be fair though, I am happy about th…
As for small and simple libraries... it's great when the subject matter is also small and simple. UI is not, though.
Earlier quoted context omitted.
But it's faster to use a QList than having to do the same in C (repeat for all the non GUI classes that Qt brings in).
Not faster to integrate it into a build system or compile it though.
Anyway usually the consensus is that it's worth to save human time increasing compilation time. Otherwise nobody would use Rust instead of C
Earlier quoted context omitted.
>Many projects do not want that kind of bloat. It isn't bloat if it's desired functionality. Not every project is optimized to run in an embedded environment, nor does it need to be.
Adding 250,000 lines of code to render fonts to an 1100 line functional gui library is bloat no matter how you slice it. If someone want that renderer, it's not that hard to wire it in. And if you in particular want it, fork them and merge them.