Live data from Hacker News

Libui: a portable GUI library for C

github.com

151–160 of 164 posts

Re: Libui: a portable GUI library for C

#151
post #99

For those interested, it seems to use classical grids to align elements, and it is the only way to do it, since there is no mention on coordinates (if I read it thoroughly enough). void uiGridInsertAt(uiGrid *g, uiControl *c, uiControl *existing, uiAt at, int xspan, int yspan, int hexpand, uiAlign halign, int vexpand, uiAlign valign); The overall feeling is that it’s a [small] subset of GTK. I think they try to fill…

I think the point of this library is more to offer a native wrapping UI toolkit, including windows and Darwin, not necessarily a GTK subset, though you probably meant that in terms of a subset of components rather than implementation. This library has no renderer of its own and instead delegates that away.

Also the design of uiGrid was directly based on that of GtkGrid.

Re: Libui: a portable GUI library for C

#152
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…

With that many digits, uiPi should definitely have an L suffix.

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

Re: Libui: a portable GUI library for C

#153
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) .

(Hint: I am trying to make libui's in-code documentation match the Go style, which no existing C-based documentation tool seems to do...)

Re: Libui: a portable GUI library for C

#154
post #114

Github badly needs a prototype/alpha/beta/rc/production tag, like Sourceforge and Pypi have. It should be set to prototype by default.

It does this for "Releases", but not for entire projects. And if someone starts browsing files, then you'd have to worry about what that status is at the commit for the file you are reading; this will vary based on how the projects organize their git branches, tags, and releases.

Re: Libui: a portable GUI library for C

#155
post #49

I have arrived at this library yesterday while trying to do a cross platform drag and drop app. I decided to go with x/screen package instead. The documentation and lack of examples threw me off. If I have to read the source in details to understand the app, I am better off writing the code x 3 with native tools. The library is supposed to save time not steal from it. It is wonderdul idea and I really like the name.…

Not only does libui not yet do drag-and-drop, but drag-and-drop is sufficiently complex enough that simple libraries are probably not going to have this out of the box. That being said, I do plan on adding drag-and-drop later.

Re: Libui: a portable GUI library for C

#156

Judging from the comments here, it appears I have completely failed at properly getting across just how early this thing is in development. I've since updated my README with a status report. As for documentation, that is an active WIP. I have recently pinned down a documentation style I like, and applied it to the newest APIs; all that's left to do really is to spread it to the older APIs as well, and write a tool to…

Oh, and one other thing I forgot to mention about documentation: the nature of this project requires me to balance what I can get behaving identically across platforms, what I can guarantee about behavior across platforms that must differ, and what I am forced to leave as "implementation-defined" with no further specification. If this was a non-native project like GTK+ and Qt, I would be the one making these decisions, but in this case I am not, so I must take a lot of factors into consideration when writing documentation. If you read through the docs I did have on package ui, you'll find a lot of TODOs about behavior.

Re: Libui: a portable GUI library for C

#157

Earlier quoted context omitted.

Decisions are made by those who show up. I agree with your point about reading the signals of which projects are probably the best. But with great power comes great responsibility. It's entirely possible YOU are the person who makes this project great, just by the Butterfly Effect of getting the documentation good enough that the next person who comes along will be willing to choose this and push a little harder, and…

> But if you show up, you get to make decisions. That's not true with documentation. the decision has already been made. if you show up later and write the docs then you're just hoping you interpreted the decision correctly and aren't misleading people.

Plus, you are interpreting whether or not a decision was even made. Maybe it was an implementation detail that leaked out, or maybe the decision is still left as a TODO in the backlog somewhere.

If there wasn't an intentional design decision, then who knows if the behavior you try to document lasts beyond the current version, who knows how quickly that documentation is out of date. (Likely if a project doesn't care about documentation before you arrive, they might not likely care about stale documentation either.)

Re: Libui: a portable GUI library for C

#158

Earlier quoted context omitted.

Ironically this library is small, easy to compile, written in C++ with a C interface, and unbelievably slow. Try out the test.exe and watch everything slow to a crawl. It is worse than Atom about the speed of the slowest modern program I've ever seen - the ethereum wallet.

I assume you are using the Windows version. The slowness is a bug that I have to fix; there are several issues about it, and a few ideas of how to fix it. You can comment out some code in container.cpp if you want to have it go fast but also be ugly (the code has to do with transparency of standard controls on tabbed backgrounds).

Oops, if it wasn't container.cpp it was parent.cpp; I forget which file right now

Re: Libui: a portable GUI library for C

#159

Earlier quoted context omitted.

Except it doesn't run native controls, at least so far as I'm aware.

> Except it doesn't run native controls, at least so far as I'm aware. Can you tell the difference? https://3.bp.blogspot.com/-O1Naap_IGVQ/VGJsRBEfQjI/AAAAAAAAA...

Not really a great example, as much as I love VLC.

Re: Libui: a portable GUI library for C

#160

Earlier quoted context omitted.

I find if you maintain an open source project as if your users were customers, things tend to go pretty smooth.

Smooth for whom? Not the one beholden to a bunch of non-paying "customers" I'd wager.

What is the bad thing you posit would happen when a bunch of non-paying "customers" are treated in a professional manner?
Post reply on HN