From Apache OpenOffice Wiki
Revision as of 23:52, 4 December 2012 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.


We are in the early planning stage.

I activated the older and unfinished sidebar support that was done when OpenOffice was developed by Oracle. There are devloper snapshots for Linux (requires glibc >= 2.15: Ubuntu 12.4 or later, Fedora 17 or later...), Mac and Windows. These exist for reference and analysis. There appear to be several bugs, do not use these developer snapshots for editing valuable documents.

Screenshots from the developer snapshots:

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

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




We are still working on this. Likely to change.

Here is a draft:

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)
Icon bar
Similar to a vertical tool bar. Clicking on icons/buttons switches between content panels.
content panel
Displayed int the main window of the sidebar. Examples are the task panels of the Impress task pane or the property views of the Symphony sidebar.

Outline of the implementation work

The sidebar implementation has to address several individual issues:

API for providing content panels

  • Content panels are created by factories.
  • Factories are registered at one factory manager.
  • Factories can be provided by
    • Internal code that is part of the AOO SVN repository.
    • External extensions from the extension repository.

API for internal handling of the sidebar

  • Activation of content panes
  • Detection of visible/active content panels
  • Receiver of context switch notifications
  • Factory for registering content panels and associations between contexts and content panels.

API for aiding in implementing content panels

Optional but important for sidebar adoption by developers.

  • Simple layout manager
  • Notification of important events
like switching to/from high contrast mode
  • Skeletons for content panels and factory registration

Implementation of context switch handling

  • Receiver of context switch notifications as controller that updates the set of active content panels accodring to the new context.
  • Factory and container for providers of content panels
  • Extend Writer, Calc, Impress with context switch notifications.
    • This may follow toolbar switches.
    • Maybe toolbar switching can generate the notifications?

Framework for implementing content panels

  • Base/helper classes for content panels, factories, registration, layouting.

Content panels

  • Reuse code from AOO Impress and Symphony

Implementation of the actual side bar

    • Icon bar as special case of tab bar.
    • Display of one or more content groups
    • Display of one or more content panels inside each content group.
    • Display of scroll bars when sidebar becomes too small for displaying all active content panels.

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.

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.

Here is a schematic of the UI: Toolpaneldeck.png.

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.

Personal tools