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.
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.
The framework is used internally by at least one fortune 50 corp for a large app suite.
wxWidgets can use the platform native controls, but the apps rarely look native because the layouts and behaviors are non-native. Mac/GNOME/Windows all have different ideal metrics for spacings, control placement and labeling (OK/Cancel vs Cancel/"Do Thing") -- being native means getting all of those details correct.
Under the hood, it's 100% native widgets (i.e., on OSX, the code is actually instantiating an NSButton, adding it to an NSView, set as content on an NSWindow; on Ubuntu, it uses Gtk.Button etc), so the look and feel of the widgets themselves are exactly as the platform dictates.
But the devil is in the detail. The reason why many wx apps don't look very well on OS X is because getting all the tiny details like spacing, behavior, layout etc. right for all supported platforms, with (mostly) same code base is hard - and it has nothing to do with the look of individual widgets.
But well, you'll learn that during the journey ;)
It may be that everyone else picked up on Python native quicker than I did, I'm reading this in bed during a lie in so am a bit sleepy!
The short version:
* System native widgets, not themes
* Installable via "pip install" - no third party or binary dependencies
* Not just naïve wrappers around widgets - capture the underlying use case and provide an API wrapper.
* Genuinely Python native. This means exploiting language specific features (like generators and context managers)
May be you are thinking about some other toolkit that's not wxWidgets.
container.constrain(button.TOP == container.TOP + 50)
I dove into the code and found the answer here. button.TOP and container.TOP are both Toga Attributes, which have their equality operators redefined.
Very interesting and clever use of operator overloading.
Python is very good at behaving as you expect it to, despite the fact that you can implement pretty much any magic. This is down to library design more than it is language design.
prob += x*2 + y, "foo"
prob += x*2 + y > 3, "abcd"
On both of these the string is optional.
I'm also conflicted. On one hand, it's about the most compact syntax you can get for something like this - when similar libraries in languages without operator overloading resort to passing strings into functions... On the other hand, it can be utterly incomprehensible if you haven't gone through the documentation.
I see your argument about overloaded operators being dangerous for newcomers, but the syntax isn't completely fabricated.
left_container = toga.OptionContainer()
AttributeError: 'module' object has no attribute 'OptionContainer'
Longer term, I definitely want to support Windows to the same level as other platforms; any assistance on this front would be gratefully accepted.
Edit: In fact, OptionContainer is just 15 days old, so I think you've got an old version: https://github.com/pybee/toga/commit/262efbfc00fae0a96e09666...
Of those tools, the test runner (cricket) is the most mature; the debugger isn't much more than a proof of concept. Those tools are also based in Tkinter at the moment; I started Toga because I've started to hit the limits of Tkinter.
The intention is to port the other PyBee tools to Toga as soon as they get mature enough.
An example application using it, with the GTK backend: https://i.imgur.com/pW2Jl9q.png
and the Qt backend: https://i.imgur.com/z6cC3rM.png
The author (byuu) posts here, he might be able to answer questions.
Well, may be some very platform specific guidelines have to be added by hand, but the actual widgets used are native.
~> apt-cache search toga
toga2 - computer chess engine, calculates chess moves