From Apache OpenOffice Wiki
Revision as of 21:59, 29 January 2013 by Pescetti (Talk | contribs)

Jump to: navigation, search

The sidebar (working title) is a new feature likely to be in the 4.0 release. It combines ideas and code from both the Symphony sidebar and the OpenOffice Impress task pane.

The UX part of the work is described on another page. This page focuses on the API design and implementation.

Help in whatever form (writing code, designing the UI, testing) is welcome.


  • Designed API (new services and interfaces) and configuration for declaration of sidebar decks and panels and notification of context changes.
  • Initial implementation as test of the design. Most of the changes can be found in sfx2/source/sidebar and svx/source/sidebar.
  • You can find the SidebarWorkbench extension here. Note that these work only with the recent changes in branch sidebar. A developer build is available for Windows here.

Past activities:

  • Created a new sidebar that at this moment can display panels that are provided
    • by a new extension (see above),
    • by already existing extensions using the XUIElementProvider interface family,
    • by Impress (but there are still severe painting problems).
  • The sidebar menu already works. It is almost identical to its Symphony counterpart with one additional entry for docking or undocking the sidebar.
  • Individual panels can be collapsed or expanded.
  • The older and unfinished sidebar support that was done when OpenOffice was developed by Oracle is still active as a reference.



Work in progress. Comments are welcome.

Schematic overview of sidebar components. Location of elements do not reflect UX design.
Name of the feature and name of the control including all its components (icon bar, content panels).
Also known as task pane(l) or tool pane(l)
tab bar
Similar to a vertical tool bar. Clicking on buttons switches between sidebar decks.
Contains one or more content panels. Only one deck is visible at any one time.
content panel
Displays information about the document and/or provides the means for document modification.
Each content panel focuses on one topic like font, table or shape properties.
There may be more than one content panel in a deck.
Examples are the task panels of the Impress task pane or the property views of the Symphony sidebar.
title bar
Displays the title for the current sidebar deck.
Can contain a closer button.
content panel title
Displays the title for one content panel. Optional when there is only one content panel.
configuration menu button
Opens a popup menu that allows switching between decks and also allows the activation and deactivation (tab is not shown) of decks.

Implementation design

The sidebar consists of two major components:

  • The buttons in the vertical tab bar on the right switch manually between sidebar decks.
  • The content area contains a two-tier hierarchy of deck and content panels. There is exactly one deck visible at any one time. It contains one or more content panels. A content panel can be displayed expanded or collapsed.

The set of visible deck and content panels changes when a context change is broadcast. Context changes occur for example when in Writer the cursor is moved from text into a table or when in Impress text editing of a shape is activated.

Decks and context panels are specified via configuration and UNO interfaces and thus can be implemented not only in the AOO core code but also by extensions.

Context change notification

Context changes are broadcast via the new ui::ContextSwitchEventMultiplexer singleton (which is based on the equally new ui::EventMultiplexer service).

Context change broadcasts have to be manually inserted into application code.

Notifications about context changes are restricted to single views by using the XController as selector: an XController object is passed to ui::EventMultiplexer::addEventListener() and ui::EventMultiplexer::broadcastEvent() methods.

The sidebars (there is one per document window) listen for context change notifications and rearrange the set of visible decks and panels according to the configuration entries for each deck and panel.

There will be a predefined standard set of contexts but extensions can provide decks and panels for new contexts and can also notify context changes for them.

Content panels

Decks and content panels are specified via the configuration. The new Sidebar.xcs defines schemas for decks and content panels that contain:

  • UI title
  • Application and context names for which a deck or a content panel is to be visible.
  • Simple layout information. Two different schemas will be supported
    1. Use all the available space (distributed equally when more than one panel reuests this)
    2. Vertical stack. The default for content panels migrated from Symphony. Requres content panels to support a new interface ui::XVerticalStackLayoutElement with the method getHeightForWidth()

For the actual creation of panel objects (decks do not need per-object implementation) the existing ui::UIElementFactoryManager and the configuration entries in the <application>WindowState configuration files are used.


It is the responsibility of the sidebar to display the right set of content panels for the current combination of application (writer, calc, impress, draw, base) and context (eg text-editing, table-is-selected).

The visible set of deck and content panels changes on three occasions:

  1. A context change is notified via the ContextSwitchEventMultiplexer
  2. User clicks on one of the buttons in the sidebar tab bar.
  3. Explicit requests to show a certain deck or panel (used by Impress to show the layout panel when the user opens the page context menu and clicks Slide->Slide Layout)

Implementation Work

Using bugzilla issue 121420.

The list of open and done parts of the sidebar implementation are (to be expanded and color coded):

Content Change Notification

Decks and content panels

  • Configuration
  • Implement manager for decks and panels
  • Example code for testing and as tutorial
  • Migration of Symphony decks and content panels for Writer, Calc, Base
  • Migration of AOO decks and content panels for Impress


  • Tab bar
  • Tabs
    • Icons and high contrast icons, read from configuration
    • Test with internal and external (extension) code
  • Title bars for decks and content panels
  • Outer layouting of content panels
    • Distribution of vertical space between panels
    • Collaps and expand panels
  • Management of context changes
    • Read specification of decks and content panels from configuration
    • Connect to EventMultiplexer and listen for content changes
    • Update visible deck and panels on context change
  • Dockable child window as container of sidebar
  • Configuration menu

Existing implementation

Not all the API design and implementation work has to be started from scratch. There several parts that can be used/reused/adapted.

In main/sd/

The drawing framework is used for the Impress taskpane, all Impress views and the slide show. A tree of URLs (called a configuration) defines the different layers of containers (windows) and views (taskpane panels). SD views only modify a configuration, update and synchronization of the associated view shells is left to the ConfigurationController.

Contextual changes of tool bars are handled in SD in a single place by the ToolBarManager. It receives notifications about context changes by registering as listener at the EventMultiplexer.

Example: When an Impress shape enters text edit mode then sd::View sends an event to the EventMultiplexer. That forwards the event to the ToolBarManager. The ToolBarManager checks its set of rules, finds the one that activates the text edit tool bar and replaces the current context bar with the text edit bar.

Screenshots from the developer snapshots. In all three screenshots mouse is over the third button from the top in the sidebar, button above is selected. Click to enlarge.

Linux: screenshot-linux-sidebar-small.png Mac: screenshot-mac-sidebar-small.png Windows: screenshot-windows-sidebar-small.png

Detail views of regular toolbar buttons. Right "abc" button is selected, mouse is over left "abc" button.

Linux: screenshot-linux-toolbar.png Mac: screenshot-mac-toolbar.png Windows: screenshot-windows-toolbar-detail.png

Examples of toolbars in other applications:

Linux (file explorer): screenshot-linux-explorer-small.png Mac (Garageband): screenshot-mac-GarageBand-small.png Windows (File Explorer): screenshot-windows-Explorer-small.png

For comparison here is a screenshot from Symphony (on Windows):


In main/svtools/ and main/sfx2/

The unfinished implementation of an office wide toolpane with Symphony like functionality can be found in svtools/source/toolpanel/ and sfx2/source/dialog/taskpane/. See Framework/Article/Tool Panels Internals for details.

Existing API (main/offapi/)

XUIElement and XToolPanel from com::sun::star::ui provide an API abstraction of the toolpanel.

It is already possible to provide new tool panels from an extension.

In the symphony branch

The sidebar is implemented in sfx2/source/propertypanel. Base functionality for sidebar and content panes can be found in svx/source/propertypanel.

Find application specific content panels in sw/source/ui/propertypanel, sc/source/ui/propertypanel, sd/source/ui/propertypanel. In these directories the files propertydlg.cxx defines the set of panels that are to be displayed. These lists are hardcoded and can not be modified by extensions.

Painting of control backgrounds is also hardcoded. Look for instance at svx/source/propertypanel/paragraphpropertypage.cxx and search for calls to DrawGradient(). Colors for the background gradients are defined in every file that paints button backgrounds.

Personal tools