Widget selection for fields

[Joel B. Mohler]

(the form of this message is likely a better blog post, than mailing
list post)

A major part of PyQtBindings is the creation of forms from python
classes. I say 'classes' rather than 'objects' quite intentionally.
SqlAlchemy relies on this dichotomy of the column attributes in
classes which behave as python descriptors/properties. This is useful
because the values held in attributes of the object are transparently
simple python objects of type str, bool, int and so-forth, but the
attributes of the class are sqlalchemy Column objects with the
metadata associated with them. I've followed this lead with the
UserAttr class and PyQtModels.py has much code to abstract away the
differences between a UserAttr and a Column object and provide a
unified appearance in binding to form widgets.

A simple example is shown at
https://bitbucket.org/jbmohler/pyqtbindings/src/fd0ff1489a19/Examples/BoundInputsDemo/BoundInputsDemo.py
Note that it is fundamental to the nature of PyQtBindings to specify
the class in the call "self.mapClass(SomeClass)" and that is why I use
the word 'class' as I do rather than 'object'.

So, there is a change coming if I can get it in a form that I like
which I'd like to reflect on as much for myself as for my dear
readers. This is the introduction of an abstraction layer which I
call a 'yoke'. This binds a qt widget that knows nothing about the
binding architecture of PyQtBindings to the PyQtBindings object
model. This widget is expected to use qt properties and signals/slots
like any well-mannered qt widget and the yoke will assign the
properties from the object and monitor the signals to update the
object in the data model.

This behaves largely as a replacement for QDataWidgetMapper. Now, I
dearly want to like QDataWidgetMapper, but it's hard. The first thing
that turned me off was the double-escape semantics chronicled at
http://bugreports.qt.nokia.com/browse/QTBUG-1944 . Next, I discovered
that that bug is even worse if you have edits in a QGroupBox in that
escape sets focus to the QGroupBox and the QGroupBox sets focus back
to the edit meaning that the escape key does nothing visible! I
considered fixing that, but the closure of QTBUG-1944 leads me to
believe that it's by design.

Another more fundamental issue in QDataWidgetMapper is that it has a
rather strict 1-to-1 correspondence between widgets and model
columns. That's not satisfactory for some of the things I'd like to
do. For instance, I'd like a unified address widget that spits out
multiple attributes -- street, city, state, zip. I can't figure out
how to do that gracefully with QDataWidgetMapper.

So, I introduce the notion of a yoke that does some of the tracking
work in a QDataWidgetMapper. Another feature of yokes is a an
abstraction layer about which widget type to display. If you don't
like the PBDateEdit, you can feel free to write your own widget, write
a simple yoke, and tell the application globally to use your yoke when
a binding of type 'date' is desired. Similarly, you could replace all
'int' type edits and other things as well. Of course, the
pyqtbindings native widgets are going to rock the world and no one
would ever want to replace them (well, maybe not!).

Comments and criticisms are all welcome. Of course, it behooves me to
put up the code and I aim to do so in a reply to this message later
today ... although I'm not too sure it'll be ready for commit that
soon.

Joel