Libui: a portable GUI library for C • Hacker News Board

Re: Libui: a portable GUI library for C

#31

Post by kodablah » Sun, May 20, 2018, 3:01 AM UTC

dman wrote: post #16

fernly wrote: post #3

I might be interested, esp. since it claims Python bindings, but documentation appears to be nil. Seriously, nonexistent. A GUI lib surely has an API complex enough to require _some_ kind of reference docs, at least. But the contents of the doc folder[1] are just a joke, most of the files contain single lines, and the .md files are fragments with many "TODO" notes. So OK maybe I can get some insight reading the code.…

I find it a bit sad that this is the top comment. I have witnessed free software/OSS have tremendous amount of positive effect on the world, however as the years go by I can't help feeling that we have trained a generation of users to act in an entitled manner towards software that is free and often the labor of love of some fellow developer trying to get better at their craft.

I view it a bit differently. I can't help feeling that we have trained a generation of devs to act in an entitled manner towards documentation that is easy and formerly seen as requisite as the code itself. Personally, I find documenting my projects a labor of love because it's where I can distill all of my hard work in a presentable format.

Re: Libui: a portable GUI library for C

#32

Post by saagarjha » Sun, May 20, 2018, 3:02 AM UTC

c-smile wrote: post #26

Interesting, never saw such way of std::vector/std::map allocations: g->children = new std::vector ; g->indexof = new std::map ; At least needless level of indirection ... https://github.com/andlabs/libui/blob/master/windows/grid.cp...

Probably because it’s easy to create memory leaks this way…

Re: Libui: a portable GUI library for C

#33

Post by behringer » Sun, May 20, 2018, 3:04 AM UTC

dman wrote: post #16

fernly wrote: post #3

I might be interested, esp. since it claims Python bindings, but documentation appears to be nil. Seriously, nonexistent. A GUI lib surely has an API complex enough to require _some_ kind of reference docs, at least. But the contents of the doc folder[1] are just a joke, most of the files contain single lines, and the .md files are fragments with many "TODO" notes. So OK maybe I can get some insight reading the code.…

I find it a bit sad that this is the top comment. I have witnessed free software/OSS have tremendous amount of positive effect on the world, however as the years go by I can't help feeling that we have trained a generation of users to act in an entitled manner towards software that is free and often the labor of love of some fellow developer trying to get better at their craft.

I've been programming for a long time, but if it's undocumented I don't use it, period. It takes too much time, gets too buggy, and I can just write it myself and understand it completely (and document it as I go).

Re: Libui: a portable GUI library for C

#34

Post by behringer » Sun, May 20, 2018, 3:05 AM UTC

discussedbefore wrote: post #19

Another option (C++ LGPL w/ Lua,JS bindings): https://github.com/yue/yue Other projects building on andlabs/ui and https://github.com/parro-it/libui-node : https://github.com/mimecorg/vuido - vue https://github.com/kusti8/proton-native - react

This is great, and they're fully documented. Thanks.

Re: Libui: a portable GUI library for C

#35

Post by matheusmoreira » Sun, May 20, 2018, 3:14 AM UTC

rendaw wrote: post #27

vortico wrote: post #15

Earlier quoted context omitted.

Great! 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 pro…

There are times when people report an issue to an open source project and the response is "You should fix it yourself". Open source contribution happens when the contributor has invested themself in the project and wants to maintain the relationship. Perhaps the requester is evaluating multiple packages and wants to inform the project why they're going with another one instead. Maybe they got to the point in their ev…

>implies that the requester's time is less valuable than the project maintainer's

It is. In large projects, there are relatively few maintainers responsible for evaluating the requests, reports and code from lots of people. They're scarce resources.

https://www.youtube.com/watch?v=fMeH7wqOwXA https://www.slideshare.net/linaroorg/maintainer

Re: Libui: a portable GUI library for C

#36

Post by saagarjha » Sun, May 20, 2018, 3:22 AM UTC

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 absurd to think that I should just pick up a random project and be obligated to make it better, and that I should be called out for giving advice on how I think a project can be improved. This isn't to say that I've never submitted an unsolicited pull request to a project to get it improved–on the contrary, this is something I do very often–but I do this because I feel that the project has something of value and can be improved. I shouldn't be forced to make a contribution to a project if I just don't think it's doing everything right. (This comment isn't mean to be aimed at this project in particular, by the way, it's just a general response to all the people in this thread.)

Re: Libui: a portable GUI library for C

#37

Post by Hello71 » Sun, May 20, 2018, 3:23 AM UTC

geofft wrote: post #14

vortico wrote: post #10

Earlier quoted context omitted.

The entire API is 1100 lines. 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 document…

I 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 th…

For my sibling comments: http://www.catb.org/esr/writings/unix-koans/prodigy.html

Re: Libui: a portable GUI library for C

#38

Post by saagarjha » Sun, May 20, 2018, 3:25 AM UTC

vortico wrote: post #29

cyphar wrote: post #25

Earlier quoted context omitted.

While 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…

I agree that it's a somewhat hostile way to invite people to a project, but 1) I highly doubt that dropping a cheerful invite will have any convincing power other than someone replying "yeah, I should do that" and then promptly forgetting it, and 2) some scolding was needed. :) Your second point is a good one, but the developers are in a better position to write actual features and fix bugs than anyone else, and sinc…

> some scolding was needed

Was it, really? I think the parent comments did a good job at pointing out a potential, actionable, flaw in this project. That doesn't mean that they should be "scolded" for pointing it out or that they themselves need to fix it.

Re: Libui: a portable GUI library for C

#39

Post by weberc2 » Sun, May 20, 2018, 3:26 AM UTC

vortico wrote: post #15

geofft wrote: post #14

Earlier quoted context omitted.

I 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 th…

Great! 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 pro…

Some people just want to use a library. Not everyone wants to build a library. When evaluating a candidate library, it’s perfectly reasonable to look at things like documentation completeness. “Don’t discuss weaknesses; fix them” isn’t helpful or constructive. There is no moral commandment to pretend all open source libraries are without flaws.

Re: Libui: a portable GUI library for C

#40

Post by saagarjha » Sun, May 20, 2018, 3:29 AM UTC

dman wrote: post #16

fernly wrote: post #3

I might be interested, esp. since it claims Python bindings, but documentation appears to be nil. Seriously, nonexistent. A GUI lib surely has an API complex enough to require _some_ kind of reference docs, at least. But the contents of the doc folder[1] are just a joke, most of the files contain single lines, and the .md files are fragments with many "TODO" notes. So OK maybe I can get some insight reading the code.…

I find it a bit sad that this is the top comment. I have witnessed free software/OSS have tremendous amount of positive effect on the world, however as the years go by I can't help feeling that we have trained a generation of users to act in an entitled manner towards software that is free and often the labor of love of some fellow developer trying to get better at their craft.

> I have witnessed free software/OSS have tremendous amount of positive effect on the world, however as the years go by I can't help feeling that we have trained a generation of users to act in an entitled manner towards software that is free and often the labor of love of some fellow developer trying to get better at their craft

The only issue I see with the parent comment is that it's a bit harsh. But it's good advice to someone "trying to get better at their craft": writing software, especially one intended to be used by others, without documentation, is generally poor practice. It's not entitled at all, as far as I can see: it's not saying "I should have documentation for this project I use for free"–as far as I'm aware, they're not even using it at all. They're just evaluating whether as an interesting project they might want to take a look at later.