Proxies are complex and featureful beasts; this section discusses some additional details on them.
GTK+ treats most of the information in the interface as strings - its API usually takes data as strings, and it returns strings. However, this is a bit of a problem when dealing with an associated model, since the model may very well use integer, float or any other types internally.
For numeric types, Proxies have special support. On startup, the Proxy will look at the attached model and try and detect what attributes are numeric, by looking at their current values. Of course, if there is no value in the model, or it is a string, it will be assumed to be a string; however, if it is a number (float or integer) it will be remembered, and the Proxy will convert it from the GTK's internal string to a numeric type before sending it to the model. Note that this conversion is rather dumb and if invalid characters are used, exceptions will be raised (that's about it, though; the mainloop allows the application to go on running); use a validated Entry10 to avoid this problem.
For other types, you must convert from strings using getter and setter
methods. If dealing with numeric types, you can also manually convert in
set_*() method and avoid any risks.
To avoid needing to provide accessors to deal with simple format
conversions, Proxies provide a way to set Python format strings that
will be applied to the attribute value when it is being applied to the
widget. The syntax is:
format string) - the name is a string with the name of the
attribute. You can pass a list of strings, optionally, to apply the same
format string to multiple attributes.
Note that this does not apply to the data that is set to the model from the interface; it will be send without any conversion. Think of it as a simple, one-way filter for data sent from the model to the interface.
The proxy can present something of a hazard for complex applications if its "instant-apply" model is not understood completely. Instant-apply means that, at any time, the UI and the model have the same state. If you pop up a dialog with a Proxy, and you alter the model, even before clicking "OK" the value in the model will have changed.
This may cause two classes of problems. The first is undoing the changes performed upon the model during manipulation of the Proxy (think "cancel button" if you are having a hard time imagining why). Solutions:
The second problem is using the model in another part of the application simultaneously (think "I am editing a price at the same time she is selling the product"). This problem can be aggravated when using multiple proxies attached to the same model. Solutions:
commit()method which copied state automatically from the "ghost" to the real model.
(Yes, this part needs more research. I'll be looking into it.)
When starting up a Proxy, the model attributes to be attached to the Proxy are analyzed and the initial state of the Proxy interface is set. The process by which this is performed is rather involved, and for the sake of completeness (debugging these things can be a bit tiresome), is listed here:
None, the following defaults are used for each widget: