Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libui: a portable GUI library for C

github.com

Post reply on HN
Print view View original

51–60 of 164 posts

Re: Libui: a portable GUI library for C

#51

Post by mlaretallack »

_o_ wrote: post #50
saagarjha wrote: post #36

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…

I am quite oposite, I want example code using as much aspects of library as possible - sort of "a picture is worth a thousand words". Documentation is nice to have, but I personally consider a well written code a documentation, and it doesnt get outdated ;) Have you checked this: https://github.com/andlabs/libui/blob/master/examples/contro... ?

The first thing I looked for (and found) was the examples directory.

Give me an example over documentation any day.

This is usually how I work. I only look for the documentation when it does not work.

Re: Libui: a portable GUI library for C

#53

Post by geofft »

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…

> I am attempting to orient people into the "open-contribution" community, where we share the opinion that free software is NOT free to produce.

I agree with this position. I am also working on my own open-source projects, as well as other projects that I know have conscientious maintainers and a high-quality community. Why should I contribute my time to this project?

To be a little blunt: if this project has not thought about things like ownership of pointers and concurrency safety, it is not a project I think other people should use. My time is limited, and I use it on improving projects that I think are worth improving.

> 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.

As an open-source maintainer, this doesn't describe me at all. I care more about things that improve the world than things that amuse me. (I also work on a few things that amuse me, but they're relatively clear about that status, and f they're not, I welcome someone calling me out on it.) All the long-term projects I work on are motivated by wanting that project to be a healthy project available as a compelling option for as many people as possible.

I had the rather delightful experience of starting a new job recently and finding that the next team over had just decided to start using a project I've been maintaining for a few years. If I had not spent time writing both code and documentation that welcomed unknown future users, this would never have happened. (And I still have not written nearly enough documentation for it!)

If my motivation were just filling my own needs, I probably wouldn't publish software at all. If it were that plus bolstering my personal brand, it would go on my blog or as CC-BY-NC-ND or something. My entire motivation for releasing software under a free license is for other people to use it.

Re: Libui: a portable GUI library for C

#54

Post by geofft »

noobermin wrote: post #18
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…

>Does it take ownership of options, a struct with a single size_t. This is a bit extreme. My first thoughts (honestly) is yes, what is the size of. Following their advice to follow their examples, I looked at examples and it literally just zeros a uiInitOptions on the stack and sends it in. Thus I think it's something I wouldn't really need to care about usually. As for whether I need to worry about saving 8 bytes on…

"Usually?" What are the unusual circumstances? Will I need to care about it at an inconvenient time two years later?

I mean, yes, I can probably guess some things and end up with something that works with the current version of the library, but why would I choose this library to build on top of if I'm just guessing?

The code cannot possibly answer the question of what changes the developers may make to the project in releases they consider backwards-compatible. My question is entirely about the API, not about the code itself.

Re: Libui: a portable GUI library for C

#55

Post by fithisux »

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

I had my eye on yue, but it does not seem that a Golang port exists. Persoanally I would like a guide (hints) to port it to Golang or other language.

Re: Libui: a portable GUI library for C

#57

Post by kleiba »

noobermin wrote: post #18
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…

>Does it take ownership of options, a struct with a single size_t. This is a bit extreme. My first thoughts (honestly) is yes, what is the size of. Following their advice to follow their examples, I looked at examples and it literally just zeros a uiInitOptions on the stack and sends it in. Thus I think it's something I wouldn't really need to care about usually. As for whether I need to worry about saving 8 bytes on…

...not to mention that this is obviously a work in progress. We're looking at a project's github page, not a product release page. I would think that like with a lot of coding projects, you start with an initial idea and see where it takes you, rather than with a full specification that you then follow. Given the limited resources of a single programmer, writing an extended documentation early on and then keeping it maintained with every chance to the architecture would be a huge burden, time and effort-wise. That's not to say it cannot be done, but I understand if you want to spend your time on coding first, if it's a pet project. There's nothing that prevents documentation to be added in the future.

Re: Libui: a portable GUI library for C

#58

Post by kleiba »

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

But let's be honest: how many people write up a really good documentation for their github project? I mean, something that actually adds substantial value on top of what the source code, code comments and examples programs can provide? And is not outdated, i.e., actually always in sync with the code portion of the project? I'm sure the answer is > 0, but I would be very astonished if the percentage would be a high double-digit number.

Let's just stay realistic: this guy is not selling a product, he's coding up something out of his own interest and is showing it to the world on github. I'm sure his interest in coding this up is much greater than his interest in writing documentation, so why should he focus on the latter? "So that anybody else can use his stuff" comes to mind as a first answer, and that's fair enough. But maybe that hasn't been his foremost interest.

One aspect that I see here is that with all the different language bindings, we're not talking about a documentation that would be trivial to write. I could imagine that an effort like that requires a lot of subtle changes to the API as more functionality is added which makes keeping the documentation up-to-date a tedious and quite hard thing to do -- so something that isn't a lot of fun. And isn't fun the main reason hobby projects get started on github in the first place?

I see your point that the current state of the project makes it very hard to use for you. Fair enough. But maybe it can become interesting again in the future when more documentation has been added -- perhaps even though the help of others. After all, it's an open source project.

Re: Libui: a portable GUI library for C

#59

Post by saagarjha »

dman wrote: post #45
saagarjha wrote: post #40

Earlier quoted context omitted.

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

What about the effect of harsh comments on the creators morale?

Yes, this is a thing, which is why I called it out for being harsh. I think that it could have been a bit nicer.

Re: Libui: a portable GUI library for C

#60

Post by laumars »

_o_ wrote: post #50
saagarjha wrote: post #36

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…

I am quite oposite, I want example code using as much aspects of library as possible - sort of "a picture is worth a thousand words". Documentation is nice to have, but I personally consider a well written code a documentation, and it doesnt get outdated ;) Have you checked this: https://github.com/andlabs/libui/blob/master/examples/contro... ?

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 Microsoft for that one!)

So the arguement of example code Vs documentation isn't a mutually exclusive one.

Post reply on HN