Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
feliphil at gmx.net
Thu Jun 14 20:43:10 CEST 2012
> object mainwindow=GTK2.Window(GTK2.WindowToplevel);
> (400,300)->signal_connect("destroy",window_destroy); GTK2.HbuttonBox
> btns=GTK2.HbuttonBox()->set_layout(GTK2.BUTTONBOX_SPREAD); foreach
> (labels,string lbl) btns->add(buttons[lbl]=button(lbl,mode_change));
> If you're a complete non-programmer, then of course that's an opaque
> block of text.
Thanks for that hideously appalling example of a ridiculously low-level
If you're an occasional Python scripting dilettant, this looks like a
heap of syntax garbage of exactly that kind that has made me avoid all
C-derived languages at university (I'm a mechanical engineer) and that
makes me avoid GUI programming with Python so far.
If a domain specialist needs an application with a GUI, (s)he
typically only wants to have to tell the framework three things:
1. What the domain model looks like (classes, attributes) and what it
does in terms of behaviour (domain logic, methods). In my use-cases this
would be typically done with SQLalchemy.
2. What the GUI shows of the domain model and how it does it - define
menus with entries, layout forms/dialog boxes with fields etc. This
should be done without having to permanently look up all the specific
details of the API of the GUI framework.
3. What attribute/method of the domain model a GUI element is
"connected to" (sorry for the quotes again). This should be possible in
an interactive way, so that you can test whether GUI and code work
together as required while defining the connections.
Anything else should be done by the framework without the necessity to
write a single line of code for the "straight forward" use cases:
- creating, retrieving, updating, deleting instances of domain model
- setting values of attributes instances of domain model classes
- calling methods of instances of domain model classes
More information about the Python-list