Difference between revisions of "GSoC 2008 - Transitioning To wxAUI"

From Audacity Wiki
Jump to: navigation, search
(Copy editing and made less 'fence sitting'.)
Line 2: Line 2:
 
|-
 
|-
 
|valign="top"|[[Image:GSoC.png|Summer of Code 2008 logo]]
 
|valign="top"|[[Image:GSoC.png|Summer of Code 2008 logo]]
|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 (Advanced User Interface) is an addition to the wxWidgets GUI framework.  It offers a more modern 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 from Audacity's existing implementation of floatable windows and toolbars to the wxAUI framework.   
 
|}
 
|}
 +
  
  
 
== Global Overview ==
 
== 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.
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.  
 
  
 
[[Image:wxAUI1.png|thumb|wxAUI: docked toolbars]]
 
[[Image:wxAUI1.png|thumb|wxAUI: docked toolbars]]
The main difference to normal wxWidgets programs is that you need a framemanager (wxAuiManager)  
+
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.
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 [http://docs.wxwidgets.org/trunk/overview_aui.html documentation]  
+
All this is a very encouraging for the prospect of transitioning to wxAUI.  wxAUI is easy to use. Its [http://docs.wxwidgets.org/trunk/overview_aui.html documentation]  
is well done, as most of the wxWidgets docs. Because it's a so clean concept the Audacity could benefit from using wxAUI
+
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.
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==
 
[[Image:wxAUI3.png|thumb|wxAUI: docking of floating toolbars]]
 
[[Image:wxAUI3.png|thumb|wxAUI: docking of floating toolbars]]
 +
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.
  
==Look and Feel==
+
However, the docking of panels is not native.  It's actually not as nice as what Audacity already has.
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.
 
  
 
==Accessibility==  
 
==Accessibility==  
One important thing is the compliance of wxAUI with accessibility features in Audacity. wxAUI  
+
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.
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 will actually benefit from the use of wxAUI.  Control-panels can be named, and these names are read by screen readers.
  
Screen reader functionality in fact will benefit from the use of wxAUI, since control-panels can be named,
 
which is read by screen readers.
 
  
 
==Flexibility==
 
==Flexibility==
 
[[Image:wxAUI4.png|thumb|wxAUI: a 'resizable' toolbar]]
 
[[Image:wxAUI4.png|thumb|wxAUI: a 'resizable' toolbar]]
When making a transition to a new framework this should give you more flexibility than your old implementation.  
+
When making a transition to a new framework one expects more flexibility than what you previously had. In this area there are significant problems with wxAUI.  
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
+
* There is no simple way to create multiple-row panes. When 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. 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 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
+
* 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.
configuration at any time. So there could be some standard sets of panes and user sets.
+
 
 +
 
 +
* Audacity has automatic toolbar packing.  Automatically 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.
 +
 
 +
 
 +
[[Image:wxAUI5.png|thumb|wxAUI: how an information panel could look]]
 +
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 added when having a wxAuiManager in the background, such as information panels about wave files or help frames.
  
[[Image:wxAUI5.png|thumb|wxAUI: how an information panel could look like]]
 
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.
 
  
 
== Pros ==
 
== Pros ==
 +
* 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
 +
* Actively developed
  
* 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
 
  
 
== Cons ==
 
== Cons ==
 +
* 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 automatic packing. Event driven re-layouting possible
  
* 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
 
  
 
== Conclusion ==
 
== Conclusion ==
 +
Although there are many pros of using wxAUI it looks as if they do not 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.
 +
 +
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 you get from wxAUI isn't good enough to merit the work involved in transitioning.
  
Although there are many pros of using wxAUI it's not that clear whether they count more than the cons. Almost all features
+
wxAui certainly 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. Audacity would still be carrying its own 'extra toolbar features' code.
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
+
* Resizing of the meter-bar is an essential feature of Audacity and could not be omitted
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
+
* 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 wxAUI, because you have to carry on caring of your own additional features. Resizing of the meter-bar is an essential feature of  
+
* 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 reimplement it or you lose it.
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
+
You'd have to take care of these features whenever wxAUI is changed, which could mean constant interactions with development of wxAUI.
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
+
So maybe it's better to write feature requests for wxAUI or to implement these features actually in 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.
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.
 
  
 
[[Category:Feature Planning]] [[Category:GSoC]]
 
[[Category:Feature Planning]] [[Category:GSoC]]

Revision as of 10:07, 29 August 2008

Summer of Code 2008 logo wxAUI (Advanced User Interface) is an addition to the wxWidgets GUI framework. It offers a more modern 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 from Audacity's existing implementation of floatable windows and toolbars to the wxAUI framework.


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.

wxAUI: docked toolbars

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

wxAUI: docking of floating toolbars

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

wxAUI: a 'resizable' toolbar

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


  • There is no simple way to create multiple-row panes. When 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. 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. Automatically 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.


wxAUI: how an information panel could look

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 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 & 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
  • Actively developed


Cons

  • 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 automatic packing. Event driven re-layouting 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 you get from wxAUI are already in the Audacity code: Floating and dockable windows, saving of pane-configurations etc.

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 you get from wxAUI isn't good enough to merit the work involved in transitioning.

wxAui certainly 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. 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 reimplement it or you 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 actually in 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.