51–60 of 186 posts
You can't build a "ANSI C GUI library", because ANSI C has no graphical capabilities.
You can if you rely on the library's users to provide the non-ANSI functionality (like Nuklear does - you have to provide the graphics and input functionality).
Earlier quoted context omitted.
Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…
> not every next important application will be used by blind people or people with disabilities If this application is important to people in general, it wouldn't stop being important just because you happen to be blind or otherwise disabled. If everyone uses a particular walled-garden service for some daily task, blind people need to use it too, just the same as everyone else.
I was talking about app developers that build applications for jobs that require sight because of the nature of the job. Say a medical diagnostic application or airplane (simulator). You have to develop for the color blind, but for the completely blind, not so much. When selecting an UI toolkit I do not have to put that requirement up top.
Earlier quoted context omitted.
Yes, but why a single header file and not a pair of .c and .h files (personally this is what i do for my small libs)? With a single header file you'd need the user to put it in a specially designated "this is the implementation" .c file anyway. I can see it for C++ which supports placing code in a header as a language, but C requires jumping over awkward preprocessor hoops that can be avoided by using a .c file.
With .h only files, when you need to include needed functionality, you modify only your own source file. But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools. Think about the whole zoo: Visual Studio, XCode, Code::Blocks, make, NMake, etc.
Earlier quoted context omitted.
Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…
Thanks for your feedback. I do try to control the tone of my comments on this subject, because I get emotional about it, but I know a vitriolic comment isn't helpful. Still, I find it hard to moderate the scope of my advice. Several years ago, a blind acquaintance of mine briefly lost his job because some developer didn't pay enough attention to accessibility in an application that he was required to use. His employe…
I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file?
I would also like an explanation. The author(s) of Musl (libc alternative) mention on this page that it can potentially invoke undefined behavior: https://wiki.musl-libc.org/alternatives.html However, having used a few of these "single-header" libraries my main concern is navigating a 9000 sloc header file as opposed to a neatly re-factored version... An explanation of how undefined behaviour is possible would be wel…
Fun rant by the owner of the company Sean Barrett works for: http://web.archive.org/web/20160309163927/http://robertoconc... (and while we're on the subject, additional UB links: https://news.ycombinator.com/item?id=14170585)
As for how you navigate these files, you use a text editor that understands that you're working with code and not just a list of chars. Example post about this from last time Nuklear was discussed: https://news.ycombinator.com/item?id=11532001
Personally, for Visual Studio I use DPack (http://www.usysware.com/dpack/CodeBrowser.aspx); in Xcode, I use its methods dropdown (Ctrl+6); in VSCode, I use its methods dropdown (Ctrl+2); and in Emacs I use a thing I wrote ages ago that grabs the imenu names list and presents it in an ido menu in the minibuffer. And there are other options for other editors. The key thing is just to unshackle yourself from PgUp/PgDn/Find/mouse wheel.
Earlier quoted context omitted.
> not every next important application will be used by blind people or people with disabilities If this application is important to people in general, it wouldn't stop being important just because you happen to be blind or otherwise disabled. If everyone uses a particular walled-garden service for some daily task, blind people need to use it too, just the same as everyone else.
If you develop for an audience where you do not know every of your end users, i.e for the generic public, i would argue you can never say it will not be used by blind people (and hence have to develop for it). I was talking about app developers that build applications for jobs that require sight because of the nature of the job. Say a medical diagnostic application or airplane (simulator). You have to develop for the…
Earlier quoted context omitted.
Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…
Additional advice: "don't use this toolkit if you ever want to sell your product to government".
Earlier quoted context omitted.
Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files. The convenience of only having to include a single header is nice for quick weekend p…
Some advantages of header-only vs .h/.c pair: - you can build simple tools contained in a single .c file, and you dont't need a build system for this (e.g. just call "cc tool.c -o tool" instead of mucking around with Makefiles or cmake) - the library can be configured with macros before including the implementation (e.g. provide your own malloc, assert, etc...), with the implementation in a .c file, these config macr…
For #3: the #1 applies here too (although beware for static stuff conflicts) but in practice C code compiles fast enough for this to not be a problem
I can see #2 being an advantage, but TBH i think the case where you both need a custom malloc, assert, etc and not need a build tool where you can pass the configuration macros is kinda rare.
Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640
Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…
Earlier quoted context omitted.
Additional advice: "don't use this toolkit if you ever want to sell your product to government".
TBH this looks mainly oriented towards games where usually the only UI accessibility you have to be concerned about is for people with color blindness.