GSoC 2008 - Transitioning To wxAUI
|wxAUI (Advanced User Interface) is an addition to the wxWidgets GUI framework, which gives the user a more modern and user-customizable interface with floatable windows. This document forms part of the work for the GSoC 2008 GridSizer Project. It discusses the pros and cons of transitioning Audacity from its own implementation of floatable windows and toolbars to the wxAUI framework, and identifies problems which may occur while doing it.|
wxAUI is 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.
The main difference to normal wxWidgets programs is that you need a framemanager (wxAuiManager) 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. Because it's a so clean concept the Audacity could benefit from using wxAUI to clean up its code a lot. You even have not to take care of updates of the toolbar behaviour anymore, because wxAUI is part of wxWidgets and therefore vitally 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 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 making a 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 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, so you will end up in having streched toolbars. You have to overwrite these functions to avoid this, so there is no really easy way to get rid of the stretching behaviour.
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. It is technically possible to catch mouse-events and implement the resizing of toolbars on its own.
Automatically packing is not supported at all, since all common user-interfaces are not doing it. So 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 sets is very easy. You have to call one function to save the current configuration of panes and can load this configuration at any time. So there could be some standard sets of panes and user sets.
Adding new panes is very easy as well. And a wxAuiManager could not only hold toolbars but even other frames. So all kinds of frames could easily added when having a wxAuiManager in the background, such as information panels about wave files or help frames.
- well documented
- easy to integrate
- fits well into the native look & feel, with minor impairments (docking)
- accessibility features are not affected but 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
- vitally developed
- no easy way to implement multiple-row toolbars
- resizing in a complete different manner than resizing is done at the meter-bar. Event-driven resizing possible
- no automatically packing. Event driven re-layouting possible
Although there are many pros of using wxAUI it's not that clear whether they count more than the cons. Almost all features you get from wxAUI are already in the Audacity code, even more. The layout of Audacity's toolbars is not native but generic enough to be understandable for most users. But the fact that there are three large features which have to be implemented by Audacity is an important fact. So the code clean-up from wxAUI is not as big as the features were in wxAUI already. Maybe there is no way at all to get multiple-rows work with wxAUI. You even have to take care of your own features when ever wxAUI is going to be changed. So maybe it's better to write feature requests for wxAUI or implement these features directly in wxAUI before make a transition to it.