In my opinion, things such as Qt, WxWidgets, etc., which are implemented in C++ are from the time that C++ was supposed to be the breakthrough language. So these toolkits only targeted C++ in the same way that SWT was mostly thought for Java (although it may have been written in C or C++, I don't know).

This library seems to be implemented in C so that higher level languages can make use of it. C is much simpler to interface than C++. For instance, you mention WxWidgets, but that thing is so god-damn complex that there's still no stable WxPython for pyhton 3..

I really hope that this libui stays as just a simple simple thin wrapper so that we can build complex things no top of it in each language. For instance, python guys may create a declarative framework on top of this while lisp/haskell guys may create a Functional Reactive "thing" on top of it. As long as libui stays simple enough, everyone can extended it in ways that make sense for their own languages..

The library has a C interface, but the underlying implementation varies: Objective-C for Mac OS X, C++ for Windows, and C for Linux.

Actually SWT was one of the most pleasant experiences I've had coding GUI stuff. I always found it such a shame that it's only possible to use within the Java ecosystem. I really wanted an interface to the SWT binary libraries from other languages, I looked into it but it seemed intractable to port. If this library takes a similar approach it's probably doing something right.

SWT itself is written in Java. The native libraries are super-thin JNI wrappers for the underlying OS APIs.

I did a project last year where I wanted to use SWT, but I wanted to write the program in Python, and use CPython rather than Jython so I could have access to C extension modules like lxml. So I hacked up a solution using the Avian lightweight JVM and the pyjnius JNI-based Python/JVM bridge from the Kivy project. I should release that sometime.

The main difference is the License which is much more liberal in this case. Also binding C++ code requires wrapping the code trough a C interface which is really a pain; especially when considering the the underlying OS APIs have a C root.

I guess it's the proverbial "Simpsons did it" in which case, I don't care and I like to see people tinkering with ideas rather than just settling.