This project appears to be quite early stage (many missing APIs, no stable Windows support, poor documentation, etc) but very promising. If it had integration with a GUI designer and was feature complete, I'd start using it on projects.
I've explored the options for Python GUI toolkits quite extensively. They're a real challenge to get running conveniently (by conveniently, I mean a simple PIP install away with no external C/C++ library dependencies) on OS X with native looks, and that is a nice advantage of this one IMHO.
Yes, the project is very early stage - I've been tinkering for 6 months in my spare time (and it's not like I had a whole lot of that to start with). Getting cross platform on 4 platforms has, as you might expect, taken a bit of effort.
I started down this path because the existing options didn't satisfy me. When my initial couple of weeks of tinkering proved that it was possible to get widgets without binary dependencies, that gave me the momentum to get to the point that I've publicly announced. There's plenty left to do, but I've got high hopes.
"No external C/C++ library dependencies" is simply impossible. Given that the host OS is not implemented in Python, some kind of bridge to its native libraries is necessary for a GUI library. Such libraries can be either compiled during the pip installation, or required as an external dependency installed using the package manager of the OS, Either way it's never going to be hassle free due to all the different OSes and package managers.
>"No external C/C++ library dependencies" is simply impossible. Given that the host OS is not implemented in Python, some kind of bridge to its native libraries is necessary for a GUI library.
Not true. Python provides facilities for dealing with dynamic link libraries from native Python code. These can be used to interface with the OS directly, without necessitating writing a C/C++ wrapper.
OK then it's a terminological confusion, because I would say that gives you a dependency on said "dynamic link libraries". Whether you need to write a C/C++ wrapper only determines if the dependency is in runtime or also compile time.
On Windows or Mac this may be true, but with Linux the GTK or Qt libraries are not part of the OS, but are used in desktop environments which may or may not be installed, and there are different version etc. so things are more messy and it's definitely a dependency which has to be fulfilled (at least at runtime).
From the conversations I had with the creator of Toga at PyCon AU 2014 and before its release, this is understood, and the current dev was towards 'it works on ubuntu', and more will come. The system is extensible so down the track the issue will be more "which do i pick" not "i can't find a way to render" ... since nothing stops this using some kind of text mode terminal UI rendering library, or a raw frame buffer one, its very awesome.
I've explored the options for Python GUI toolkits quite extensively. They're a real challenge to get running conveniently (by conveniently, I mean a simple PIP install away with no external C/C++ library dependencies) on OS X with native looks, and that is a nice advantage of this one IMHO.