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.
A bunch of people have commented on this blog post wearing me away from this new design. To their credit, yes, things do get unwieldy fast... but now I'm not sure where I want to take things as far as event handling is concerned. Maybe I'm wrong about callbacks; I don't know...
The idea to make individual changes asynchronous by default looks like it wouldn't be much of an issue :S
Actually OS X is the only system that guarantees application-modal dialog boxes stay always on top; it's the other platforms that I would need to worry about.
Note: since writing that article I have now started, and am now mostly finished with, this rewrite, having only one last ink to work on... dialog boxes. This was always a big disaster ecause every OS has a wildly different model, and now I'm sitting on a Stack Overflow question related to Cocoa thinking if I should just force all dialogs to be application modal but then need a way to make them always on top on all platforms...
If I recall correctly, the point of Singularity wasn't to have a platform base where all programming languages shared the same infrastructure, but rather to have an operating system that ran (almost) entirely in "managed code" (the .net framework's safe-execution system).
All indentation ones except the L35-37 ones are lack of go fmt. I will go fmt once I can double-check exactly what go fmt changes.
L35-37 I'm not sure what problem that has; I just put the very long bitmask on its own line.
The underscores in our_xxx_xxx_xxx I don't think would be much of an issue. They unintentionally match the GTK+ naming conventions. I don't know why I did them, but I don't consider it a world-ending issue worth fixing. Same for _xSysData, but in that case the _ is there in case I accidentally said xSysData somewhere else.
Existing GTK+ bindings require very recent versions of GTK+, which, while they provide some useful things, fail backwards-compatibility tests pretty hard, especially on distributions like Ubuntu. That being said, I do have a project in mind that will use jrick's gotk3 and GTK+ 3.10...
GTK+ on Windows doesn't really have a particularly good reputation among myself and some of the people I know, and I didn't know native GTK+ for Mac was a thing until very recently.
Doing it in another language would probably require rewriting the entirety of LibreOffice, which is a very massive project with code spanning at least a decade, if not more. They recently switched away from a proprietary (in the sense that only they used it) build system to one of the more conventional ones (I forget from what to what), so anything IS possible, but the question is whether it would be worth it. I know LibreOffice has some Java interoperability, but I don't know how much, or whether that could be leveraged.