spir writes:
On 02/23/2014 06:06 AM, Andrew Barnert wrote:
All you're arguing here is that PyGtk is badly designed, or that Gtk is not a good match for Python, so you have to write wrappers. There's no reason the wrapper has to be fluent instead of declarative.
That's what I was about to argue. I don't understand why the python wrapper does not let you construct widgets in one go,
*Because* it's a *wrapper*, which leverages the gobject-introspection FFI. (gobject-introspection is an export-oriented FFI, rather than an import-oriented FFI like ctypes.)
with all their "equipment", since it's trivial and standard style in python (except, certainly, for adding sub-widgets to containers, as the sub-widgets exist and need to defnied by themselves).
I don't think you need to except subwidgets. They could be defined recursively by including calls to their constructors in the "description" of the parent. It might be tricky to find a pleasant way to express placement in containers with flexible placement disciplines, but for single-child, column, row, and grid widgets I don't see a problem at all. Now, that would be nice for initialization, but the GTK+ v3 API is very dynamic and insanely complicated. I think it would take a huge amount of work to do this at all well, and I suspect that your program would benefit only from beautification of initialization -- everything else would still look the same. (Of course many programs don't need a dynamic UI; I suppose that would be a benefit.) In any case, I don't find a "chained" API for something like GTK any more attractive than the repetition of object being mutated. They're both quite ugly, an accurate reflection of the underlying library which tried to be a better Xt, but ended up equally messy, compounded by being a lot bigger (and more poorly documented).