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.
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.
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.
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...)
I don't know, but I do know I'm in the middle of making sure any non-static symbol name in libui either has a prefix of ui[capital letter] or uipriv[capital letter] to at least ameliorate this madness.
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).
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 turn that documentation into HTML, because I have not found a documentation tool that operates how I want it to.
Also (for the benefit of the rest of HN) s/as/but/ — I had problems on Windows, and someone is proposing a solution I just need to merge in once the mega-PR that added it and a bunch of other things are split into more manageable chunks that won't merge conflict as easily with what I am independently doing to stabilize the build.
No, the data grid has problems on Windows, as that code is being contributed by someone else. I already have it on macOS and Linux, and have for years now... Hopefully soon the Windows code will be merged in and we can keep going.
libui only wraps around GTK+ on Unix systems. On Windows, it uses the native Windows API directly.
GLib is a utility library; it provides things like container types, filesystem access, networking utilities, threads, object-oriented programming with events and properties, and other similar functions in a platform-independent manner. GTK+ uses GLib. You can use GLib on its own as well. It won't solve the problem of GTK+ being clunky on Windows, though.
It needs to be written because when I put that note down the API wasn't stable. Now that it's mostly stable I can start writing the documentation, which should be very detailed. There's already bits of it in the docs/ folder, for a taste.
That's planned, yes. (I have to do it anyway, because in most cases it's the print dialog that gives you the printer device cntext...) This is also why it's uiDrawContext, not uiAreaDrawContext.
Benjamin Otte recently added uxtheme.dll support to the CSS engine and I've already seen a few screenshots of the win32 theme using it to okay effect. I wrote a patch to add OS X cursor support to GDK last year and it was taken, not to mention work by Christian Hergert and others to improve the relatively new GDK/Quartz backend. So I'm pretty sure Windows and OS X are supported platforms :)
I haven't implemented that, and I'm not sure how I would add support for implementing that in a portable way without creating a complete networking abstraction interface either... In the meantime, you could do your socket work on a thread and use uiQueueMain() to send updates to the main thread.