python 2.2 - <3.0
Author: Fabrizio Pollastri
This release adds widget toolkit version information to testing printout and changes the program version propagation from file to file, fixing a wrong version in testing printout. The development directory structure is also changed to have a better decupling among program releases and debian package releases.
This release fixes wxWidgets ListCtrl not updating header on connected variable change. It was a bug of the wxWidget driver (avcwx.py): missed the column name (header) setting call.
This release fixes wxWidgets TreeCtrl not updating on connected variable change. It was a bug of the wxWidget driver (avcwx.py): the tree items were not deleted before rewriting. Since the tree is completely rewritten at each update, the expanded/collapsed status of each tree item is lost.
This release adds the support for the java Swing widget toolkit.
The supported widgets are: button, check box, combo box, label, progress bar,
radio box, slider, spinner, table, text area, text field, toggle button,
Among some internal changes, the real to abstract widget mapping substituted the eval of widget string names with a dictionary of abstract widget classes keyed by real widget classes. To improve module safety, the check for executed avc_init in avc_connect was added.
Now, the setup utility can install for both python and jython.
This release makes some cleanup of backup files in "examples" dir and restore the file "manual.pdf.readme" in "doc" dir.
This release expands the number of supported widgets introducing the support for the progress bar widget and for two advanced widgets: the list view and the tree view.
The advanced widgets can display data structures much more complex than normal widgets. The list view widget can display a 2D table of data, the tree view widget can display a hierarchical tree of data. The developing effort was focused to the mapping of the complex data structure of these widgets to some kind of python data as simple as possible and valid for the same type of widget accross all the supported widget toolkits. The result is a python list of lists to represent list view data and a python dictionary where the keys are the paths of each corresponding value inside the tree (see "listtreeview/ctrl" example).
This release adds PDF documentation sources (ODT file and images).
This release comes with a big code rewrite and a step up in internal complexity for the introduction of multiple matching namespaces and dynamic connections. A small change in user api is also introduced.
Multiple matching namespaces
Now, each python object (class instance) in the application program has its own matching namespace. This means that AVC can search for matching names in the attributes of a given object, from the application side, and in the widget names of a given widget tree or subtree, from the GUI side. Each name space is independent from the others, this allows different connections belonging to different objects to have the same matching name.
For example, AVC can create and manage all the widget-variable connections required by an application that needs to instantiate a number of object from a class that creates its own GUI or a part of a GUI and interacts with it by connecting some of its attributes to some widgets of its GUI (see "countdown" example).
Widget-variable connections can be created at any run time, in this way, AVC can connect widgets that are created later than application start up time. When the application deletes a widget that belongs to a connection, AVC automatically removes it from the connection and if the connection has no more widgets, the connection is also removed (see "countdown" example).
Small changes in user api
Now, AVC detects automatically the widget toolkit imported in the applcation, so the same import statement is used for AVC import avc or from avc import *, this behaviour is incompatible with older AVC releases.
A new method ("avc_connect") is introduced to cope with multiple namespaces and dynamic connections. As usual, any application using AVC first has to call "avc_init" at init time, then, if other connections are required, all subsequent AVC calls must be done to "avc_connect".
Uniform separation between application logic and GUI
AVC allows to structure the application with program logic separated from GUI statements for all supported toolkits. For example, program logic can be put in one class and GUI management in another class (see "counter" example). Older releases allowed this separation for GTK+ and Tk toolkits only.