- They have a common signal emission API for change in content
- They offer a common API for setting and reading their value.
- They offer validation, and coercion
- They contain a few general improvements over the plain PyGTK widgets
Simply it means you can make any data widget (eg Entry, CheckButton, Combo etc), you can connect its signal "content-changed", you can read the data with widget.read(), and set the value with widget.update().
If you have read any of the previous blogs about adapting Zope.schema fields to widgets, and you are alert, you will notice that this is amazingly useful. It means that we can define an interface for a general InputWidget type, something like:
"""Read the value in the widget"""
"""Set the value of the widget"""
"""Set a callback to get called when the widget value is changed by the user"""
Once we have done this we can essentially forget about what widget we are using, and what type of field it is representing. A dream come true for the "program for an interface" paradigm.
At the same time, these widgets do have some downsides:
- They are bound to an arbitrary concept of a "model" and an attribute within that model
- They insist on having a data-type set
Let's look at a basic example:
from kiwi.ui.widgets.entry import ProxyEntry
e = ProxyEntry()
# Fake those things that Kiwi requires
# Test reading and writing
e.update('I am the starting value')
assert e.read() == 'I am the starting value'
Now imagine you had a lot of these, and that they were all automatically adapted from a zope schema (as discussed before). These widgets could all be readable using something like:
Amazing! One might be a CheckButton, returning a boolean value. One might be a Date chooser returning a datetime, one might be an entry returning a str or a unicode. Complete automatic UI generation that things like Django would be jealous of!