5 ms·
The entire API is 1100 lines. https://github.com/andlabs/libui/blob/master/ui.h https://github.com/andlabs/libui/blob/master/ui.h You don't need a separate docu
by vortico 8y ago
The entire API is 1100 lines. https://github.com/andlabs/libui/blob/master/ui.h https://github.com/andlabs/libui/blob/master/ui.h You don't need a separate documentation for that. In fact, most functions have sufficient docstrings if their names don't fully describe their function.
Your hostility toward an MIT licensed project is what is ruining the open-contribution model of developing software. In 2005, it was "Hey, this looks great, want me to write up a documentation?" Now it's "Not up to my standards, it's a joke." Absolutely disgusting behavior that is becoming gradually more common.
- stochastic_monk 8y agoWith that many digits, uiPi should definitely have an L suffix.
- andlabs 8y agoExcept that would make uiPi a long double, whereas every drawing API in libui just takes a double. Now as to whether the drawing APIs should use long double instead of double, I don't know; I will say that both cairo and Quartz/Core Graphics use double, so... (And on Windows, Direct2D takes floats, so at least on that platform, it's probably not going to make a difference at all...)
- geofft 8y agoI got to the first function in the API: _UI_EXTERN const char *uiInit(uiInitOptions *options); uiInitOptions is a struct that contains a single size_t Size. What's it the size of? Can I pass a NULL pointer? Does this function take ownership of the pointer, and if so, does it need to be allocated with malloc? If not, when can I free it - can I use a pointer onto my stack? Why does it take a non-const pointer - does the size (of whatever) change? What's the string that's returned? What's the lifetime of the string that's returned? Can another thread call uiInit, or does that break everything horribly? Or does it only break horribly if you don't copy the returned string first? You don't need documentation, sure. But it's a good way to get users of the library that make wild assumptions so that you can no longer make reasonable upgrades to the library without breaking them, and that makes nobody (neither the library author, who wants people to use it, nor the users themselves, nor end users) happy.
- vortico 8y agoGreat! If you can answer those questions, send a pull request to add it to the docstring. You've spent some time thinking of those questions, so you'd write a very complete docstring. Complaining will not solve the issue. Sending a PR will solve it. This is what I was saying above. I am attempting to orient people into the "open-contribution" community, where we share the opinion that free software is NOT free to produce. Someone must do the things you are suggesting at some point if they are to exist, and who better than yourself? With regards to your last paragraph, a common misconception is that a "payment" of open-source software is number of users. That would be true for proprietary software where payment = number of users * price, but for open-source software the developers couldn't care less (except maybe superficially, but this mental reward is insignificant for the long-term motivation for a project). They want to make a library that solves their own problems and is stable. They allow people to help improve the library in exchange for releasing it for their unrestricted use. Otherwise, there is little motivation to release it. When I find a new library that solves a problem in an interesting way, I learn using whatever is available (existing documentation, headers, source, and examples) and write down the difficult parts. The price I pay for using the software is to send my notes back to the developers in a polished, organized form that is consistent with their existing documentation. Then, no one needs to repeat what I've done in the future.
- cyphar 8y agoWhile I agree with the general thrust of what you're saying (people should contribute far more to the free software they use rather than be angry with maintainers for not solving every issue under the sun -- and having more users is no substitute for having a few passionate external contributors), this is a fairly hostile way of trying to on-board people to a project. Not to mention that the developers that wrote the project in the first place are in a much better position to write documentation than anyone else (in the past I've had to review documentation from external contributors and I'm pretty sure it would've been phenomenally faster if I'd just written it in the first place -- it isn't their fault, it's just that I know the code and its history much better than them because I've maintained it).
- matheusmoreira 8y agoTrue. People seem to have expectations of open source projects now. They act like customers even if the programmer isn't a professional who is getting paid to work on it. I work on several personal projects whenever I have free time and feel like programming. I keep them on private repositories because I don't think they are ready for publication. I'm not sure if they're ever gonna be ready.
- behringer 8y agoI see where you're coming from, but it's not a completed project if it's not documented. If it's only 1100 lines it shouldn't be hard to document it. If it's only 1100 lines and it's undocumented, it would probably be easier for me to continue using my own.