GSoC 2008 - Transitioning To wxAUI
gives the user a more modern and user-customizable interface with floatable windows. It is also themeable and specific configurations of controls can be saved. Since the workflow of an audio editor like Audacity is largely dependent on the task the user is performing Audacity could benefit a lot from having a customizable user interface. The natural way of achieving this is using the usual framework and since wxAUI is integrated into wxWidgets in its newer versions wxAUI is the natural way. Today Audacity uses its own implemtation of floatable windows and toolbars. This document should discuss the pros and cons of transitioning Audacity to the wxAUI framework and should show problems which may occur while doing it.
The main difference to normal wxWidgets programs is that you need a framemanager (wxAuiMan- ager) which manages all frames and toolbars. Though you can recursively add managed windows in Audacity one global wxAuiManager should do the job. After creating a wxAuiManager you have to add panes to it. This is a similar concept to sizers, which are widely used in Audacity. A pane is simply a wxWindow or a derived class. Though you can recursively add managed windows in Audacity one global wxAuiManager should do the job. Each Pane can have a lot of attributes, which are defined in a special wxAuiPaneInfo Object.
All this is a very perspicuous concept, which is easy to use. Its documentation is well done, as most of the wxWidgets docs.
Look and Feel
A major benefit from using wxAUI is the native look of the floating windows as well as the docked toolbars. wxAUI uses native widgets to show the windows and therefore adapt very well into the native look and feel of the platforms. Compared to the user-drawn toolbars of Audacity this would be much more common to the end-user.
The docking of panels is not native and even not as nice as Audacitys way.
One important thing is the compliance of wxAUI with accessibility features in Audacity. wxAUI uses normal wxWindows for showing the pane's content, so all accessibility features controlled by the wxWindow will work without any major changes. Most of them will even work without any change at all.
Screen reader functionality in fact will benefit from the use of wxAUI, since control-panels can be named, which is read by screen readers.
When transition to a new framework this should give you more flexibility than your old implementation. At this area there are big impairments of wxAUI.
There is no simple way to create multiple-row panes. When ever you drag a smaler pane beneath a multiple-row pane it is expanded to the height of the biggest pane in the row. Even with MaxSize() you can not stop that behavior, so you will end up in having streched toolbars.
There is a resizable attribute for panes, but it is not a resizable as used in the meter bar of Audacity. It makes the whole pane resizable, in case of toolbars the whole docking area of the toolbars, not only the toolbar itself. So with toolbars you get some strange behavior with the resizable attribute, e.g. you can not always drag toolbars to a floatable position. The resizable pane additionally always fills the whole left width of the docking area.