Transitioning To wxAUI

Global Overview
The workflow of an audio editor like Audacity is largely dependent on the task the user is performing. Audacity could benefit a great deal from having a more customizable user interface. Recent versions of wxWidgets have added a flexible GUI framework for this, wxAUI. wxAUI is now a mature set of features that is integrated into wxWidgets, having spent some years as an optional extra add-on library. It was not available when Audacity was originally written. wxAUI is themeable. Specific configurations of controls can be saved. A natural way to achieve flexibility and customizability of user interface in Audacity would be to now switch to using wxAUI.

To use wxAUI the main difference to normal wxWidgets programs is that you need a framemanager (wxAuiManager). This 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 add 'panes' to it. A pane is a wxWindow or a derived class. This is a similar concept to sizers, which are widely used in Audacity. Each Pane can have many attributes. These are defined in a wxAuiPaneInfo Object.

All this is a very encouraging for the prospect of transitioning to wxAUI. wxAUI is easy to use. Its documentation is excellent. Because it's a clean design concept Audacity could benefit from using wxAUI to clean up its code. As well as reducing the code that lives in Audacity source tree this should reduce future maintenance and development work on toolbar and frame management. Audacity would readily benefit from any future enhancements made to wxAUI. Enhancements are likely since wxWidgets is actively developed.

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. It adapts very well to the native look and feel of the platforms. Compared to the user-drawn toolbars of Audacity this would be much more familiar to the end-user.

However, the docking of panels is not native. It's actually not as nice as what Audacity already has.

Accessibility
Great care has been taken to make Audacity accessible. Compatibility of wxAUI with accessibility features in Audacity is vital and was thoroughly tested for this report. wxAUI uses normal wxWindows for showing the pane's content. Testing showed that all accessibility features controlled by the wxWindows work without any major changes. Most of these work without any change at all.

Screen reader functionality will actually benefit from the use of wxAUI. Control-panels can be named, and these names are read by screen readers.

Flexibility
When making a transition to a new framework, one expects more flexibility than you previously had. In this area there are significant problems with wxAUI.


 * There is no simple way to create multiple-row panes. When dragging a smaller 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 behaviour. As a result you end up having stretched toolbars.  To avoid this you must overwrite these functions.  There is no really easy way to get rid of the stretching behaviour. One idea tried was to create docks on the left and right side of multi-row toolbars.  Unfortunately the design of wxAUI doesn't support interaction between two wxAuiManager and this doesn't work. A pane can only be moved in one wxAuiManager and not between two.


 * The meter toolbar in Audacity is resizable. In wxAUI there is a resizable attribute for panes, but it is not resizable as used in the meter bar of Audacity. wxAUI resizability makes the whole pane resizable, and in the case of toolbars the whole docking area of the toolbars, not only the toolbar itself.  The result - with toolbars you get some strange behavior with the resizable attribute.  You can not always drag toolbars to a floatable position.  The resizable pane always fills the whole left width of the docking area.  It is technically possible to catch mouse-events and implement the resizing of toolbars on its own, but doing this largely undermines the reasons for using a toolkit rather than custom code.


 * Audacity has automatic toolbar packing. Automatic packing is not supported at all in wxAUI since common user-interfaces are not doing it.  If you resize a window to a smaller width than the toolbars, they are cut off. A workaround could be a on-resize event, which resizes the toolbar if the window gets too small.

Saving of positions is very easy. You call one function to save the current configuration of panes. You can load this configuration at any time. This would make it easy to have standard sets of panes and layouts and user-defined layouts that users could easily switch between.

Adding new panes is easy. And a wxAuiManager could not only hold toolbars but even other frames too. All kinds of frames could easily be added when having a wxAuiManager in the background, such as information panels about wave files or help frames.

Pros

 * Well documented
 * Easy to integrate
 * Fits well into the native look and feel, with minor impairments (docking)
 * Accessibility features are not affected and can even benefit from wxAUI
 * Saving of pane-configurations is easy
 * Adding of new panes, even other frames than toolbars, is easy
 * Cleans up Audacity's code
 * Actively developed

Cons

 * No easy way to implement multiple-row toolbars
 * Resizing incompatible with how resizing is done in the Meter Toolbar. Event-driven resizing possible
 * No automatic packing. Event-driven layout changing possible

Conclusion
Although there are many pros of using wxAUI, it looks as if they do not count more than the cons. Almost all features available from wxAUI are already in the Audacity code, such as floating and dockable windows and saving of pane-configurations.

The one really new 'feature' Audacity would get is the native looking floating windows, but even here the docking-sequence isn't native or as good as Audacity's. And since the layout of Audacity's toolbars is generic enough to be understandable for most users, the end-user benefit from wxAUI isn't sufficient to merit the work involved in transitioning.

wxAui certainly could help to clean up Audacity's code-base, but the fact that there are three large features which have to be implemented by Audacity decreases that advantage a lot. Audacity would still be carrying its own 'extra toolbar features' code.


 * Resizing of the meter-bar is an essential feature of Audacity and could not be omitted
 * Maybe there is no way at all to get multiple-rows to work with wxAUI, which will make the user-interface much less good-looking.
 * In my opinion packing of toolbars isn't that important, but it is a nice feature already in Audacity. With a transition to wxAUI either you have to re-implement it or lose it.

You'd have to take care of these features whenever wxAUI is changed, which could mean constant interactions with development of wxAUI.

So maybe it's better to write feature requests for wxAUI or to implement these features within wxAUI before making a transition to it. At this time it does not seems to be a good choice to make the transition, since you will get plenty of work to do for a small gain in visual appearance, and with a lot of things to take care of in the future.