Live data from Hacker News

Libui: a portable GUI library for C

github.com

71–80 of 164 posts

Re: Libui: a portable GUI library for C

#71
Lately I was thinking about the Right Thing [0] of Native Crosspostform UI - write a spare frontend for every platform and write the backend in something portable. It could be a nice idea to come up with a document that would describe every platform APIs for:

- accessibility

- localization

- text rendering

- input methods

- widget toolkit

- event loop

- HIG

The document should also contain example code for something basic for every platform. All this information could be then used to create the Right Thing Toolkit.

Probably it should aim for the future. So only include APIs that most probably would not be deprecated in 5 years. The platforms that I'm thinking about: Android, Freedesktop/Unix-like, iOS, macOS and Windows.

I was wondering what is current situation with Windows. Is UWP the future or will it be soon replaced by yet another API? Is side-loading currently as effortless as running of Win32 apps? Or maybe Win32 is good enough, because they will always support it?

[0] as opposed to the Worse is Better, because that's current situation and it's not all that hard, use SDL or whatever and draw everything yourself.

Re: Libui: a portable GUI library for C

#73
post #60

Earlier quoted context omitted.

Firstly, good documentation will include example code anyway. That's part of the course of documenting. Secondly, exams code can get outdated just as much as human documentation. I've lost count of the number of times I've gone to compile example code only to find it doesn't work because of API changes or such like. I've also had example code crash my whole machine because it effectively created a fork bomb (thanks M…

In an attempt to mitigate this, you could include the examples in your testing suite, at least to see that it still compiles properly. This is sort of standardised in the flow of Go, with godoc and the testing framework. Both uses examples from the same test files, producing standalone docs and testing them(at a minimum compiling them) .

This also happens in the Rust documentation generator. The code snippets in any piece of Rust documentation are compiled and run, and the assertions found in it will be reported if they fail. They're sort-of automatically part of the test suite.

Re: Libui: a portable GUI library for C

#74
post #71

Lately I was thinking about the Right Thing [0] of Native Crosspostform UI - write a spare frontend for every platform and write the backend in something portable. It could be a nice idea to come up with a document that would describe every platform APIs for: - accessibility - localization - text rendering - input methods - widget toolkit - event loop - HIG The document should also contain example code for something…

I would love to see a boost library that does all of this :-)

Re: Libui: a portable GUI library for C

#77

A lot of the comments have mentioned the lack of documentation this project has, and then they've received replies of the form "you should submit a pull request, the author doesn't owe you anything". Here's my take on it: I don't owe the author anything either. But if I'm considering which project to use, I'd probably choose the one with documentation, since it signals better goals and higher code quality. It's absur…

Then don't use the project. Good lord... the sense of entitlement is over whelming!

"I shouldn't be forced to make a contribution to a project" OMG.

Anyways, the whole argument doesn't matter and is totally irrelevant. Serious teams/engineers will analyze the code, consider using it, and then assign developers to help out with documentation if it provides sufficient value proposition. And thus the cycle of OS improvement continues.

Yes, documentation would be nice, but code quality is 100x more important. 100 times out of 100 i'll pick the project with better code quality over better documentation.

BTW, clear, understandable code and APIs is an example of good code quality. And of course, well written unit/integration tests usually provide sufficient example code.

Re: Libui: a portable GUI library for C

#78

A lot of the comments have mentioned the lack of documentation this project has, and then they've received replies of the form "you should submit a pull request, the author doesn't owe you anything". Here's my take on it: I don't owe the author anything either. But if I'm considering which project to use, I'd probably choose the one with documentation, since it signals better goals and higher code quality. It's absur…

Then don't use the project. Good lord... the sense of entitlement is over whelming! "I shouldn't be forced to make a contribution to a project" OMG. Anyways, the whole argument doesn't matter and is totally irrelevant. Serious teams/engineers will analyze the code, consider using it, and then assign developers to help out with documentation if it provides sufficient value proposition. And thus the cycle of OS improve…

Documentation is part of code quality.

Re: Libui: a portable GUI library for C

#79

Earlier quoted context omitted.

Then don't use the project. Good lord... the sense of entitlement is over whelming! "I shouldn't be forced to make a contribution to a project" OMG. Anyways, the whole argument doesn't matter and is totally irrelevant. Serious teams/engineers will analyze the code, consider using it, and then assign developers to help out with documentation if it provides sufficient value proposition. And thus the cycle of OS improve…

Documentation is part of code quality.

That's rarely been my experience. In fact, documentation usually exists because code quality is poor and it needs to be explained.
Post reply on HN