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. One idea was to create docks on the laft and right side of multi-row toolbars. But since the design of wxAUI doesn't support interaction between two wxAuiManager, this doesn't work. A pane can only be moved in one wxAuiManager and not between two.
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: Floating and dockable windows, saving of pane-configurations etc. So the only new 'feature' Audacity would get are the native looking floating windows, but even the docking-sequence isn't native. And since the layout of Audacity's toolbars is generic enough to be understandable for most users, the end-user benefit you get from wxAUI isn't that big.
wxAui could help to clean up Audacitys code-base, but the fact that there are three large features which have to be implemented by Audacity decreases that advantage a lot. The code clean-up from wxAUI will be not as big as it could be, if the features were already in wxAUI, because you have to carry on caring of your own additional features. Resizing of the meter-bar is an essential feature of Audacity and could not be omitted, so it have to be reimplemented, when making a transition. Maybe there is no way at all to get multiple-rows work with wxAUI, which will make the user-interface much less well-looking. Packing of toolbars isn't that important, but a nice feature already in Audacity though. So either you have to reimplement it or you will lose it.
You even have to take care of your own features when ever wxAUI is going to be changed, which means constantly taking care of the development of wxAUI.
So maybe it's better to write feature requests for wxAUI or implement these features directly in wxAUI before make a transition to it. At this time it seems to be no good choice to make the transition, since you will get a lot of work to do, and even a lot of things to take care of in the future.