Difference between revisions of "Sidebar"

Revision as of 16:02, 25 January 2013

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.

Status

• 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.
• Migration of first Symphony panel is progressing well. Simple theming is already in place.
• Theme is represented as XPropertySet. See screenshot below for a Java extension that a) displays the current context in a sidebar panel and that b) provides a dialog for visualizing the different property values and allows simple switching between theme presets.

Current screenshots:

Controls in sidebar pane are themable. Click one of the preset buttons in the Java theme dialog to see one of the proposed themes applied to a working panel:

Migration of Symphony text properties panel (work in progress). With original Symphony icons (far left) and OpenOffice icons (all other) and with different colors for panel titles and panel backgrounds:

, , ,

Simple panels, provided by a Java extension. Menu for switching between decks and for hiding or showing decks:

, ,

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.

Resources

• UX
  • UX design exploration
  • Pane Header UI Design
  • UX Design propoals
• Symphony
  • Assessment of the migrating the Symphony sidebar.
  • Older proposal to use the Symphony sidebar.
• AOO
  • Overview of an existing but unfinished attempt of implementing tool panels.
  • Introduction to writing tool panels.
  • Description of the drawing framework, that is used by the Impress tool panel.

Glossary

Work in progress. Comments are welcome.

Schematic overview of sidebar components. Location of elements do not reflect UX design.

sidebar

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.

deck

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.

Implemenation 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.
• Icons for normal and high-contrast mode.
• 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.

Sidebar

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

• EventMultiplexer
  • New service/singleton ui::ContextChangeEventMultiplexer
  • New interface ui::XContextChangeEventMultiplexer
  • New interface ui::XContextChangeEventListener
  • New struct ui::ContextChangeEventObject
  • Implementation of ContextChangeEventMultiplexer
• Add context change notification for Writer, Calc, Impress, Draw, Base

Decks and content panels

• Configuration (all done)
  • New configuration Schema org/openoffice/Office/UI/Sidebar.xcs
    • New template for decks
    • New template for content panels
• Implement manager for decks and panels (done)
• Example code for testing and as tutorial (work in progress)
• Migration of Symphony decks and content panels for Writer, Calc, Base (started)
• Migration of AOO decks and content panels for Impress

Sidebar

• Tab bar (done)
• Tabs (done)
  • Icons and high contrast icons, read from configuration (done)
  • Test with internal and external (extension) code (done)
• Title bars for decks and content panels (done)
• Outer layouting of content panels (done)
  • Distribution of vertical space between panels
  • Collaps and expand panels (done)
• Management of context changes (done)
  • Read specification of decks and content panels from configuration (done)
  • 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 (done)

How to help

The migration of the Symphony panels to OpenOffice is a lot of work. Here is how you can help.

Introduction

The content in the sidebar is organized into decks, panels and tabs. There is always exactly one deck visible. It can contain one or more panels. Tabs are allow manual switching between decks. In general the current deck and its panels is defined by the current context. A context consists of an identifier for the application and one identifier for the actual context like text editing, cursor in table, image editing and so on.

Both UNO API and configuration represent a context with two strings:

UNO 

com/sun/star/ui/ContextChangeEventObject

registry 

org/openoffice/Office/UI/Sidebar.xcs / Context

For the C++ implementation there is a enum wrapper that allows switch() statements:

   sfx2/sidebar/EnumContext.hxx

Notification of context changes

Notification of context changes is done via one single event multiplexer that is used by all documents and views:

service

com/sun/star/ui/ContextChangeEventMultiplexer.idl

interface

com/sun/star/ui/XContextChangeEventMultiplexer.idl

There is a C++ convenience wrapper in svx:

   svx/inc/sidebar/ContextChangeEventMultiplexer.hxx

that has a single static method:

   static void NotifyContextChange (
       const cssu::Reference<css::frame::XController>& rxController,
       const ::sfx2::sidebar::EnumContext::Context eContext);

It hides the messy instantiation of the UNO singleton and conversion of the parameters. The rxController is used for two things:

1. Determine the application and fill in the right string/identifier in the resulting context change event.
2. Allow listeners to be notified only for context changes of a single view

The eContext argument is defined in

   sfx2/sidebar/EnumContext.hxx

Task

• Add calls to ContextChangeEventMultiplexer::NotifyContextChange() whenever a relevant context change occurs so that the sidebar can display the appropriate deck and panels.
• Add missing contexts to EnumContext.hxx and Sidebar.xcs and provide a word or two of explanation.

Tips

Look for Update calls for SID_SVX_PROPERTY_CONTEXT

   in sfx2/source/control/dispatch.cxx, SfxDispatcher::Update_Impl()
   and sfx2/source/control/bindings.cxx, IMPL_LINK(SfxBindings, NextJob_Impl...)

and for calls to

   sfx2/source/view/viewfrm.cxx, SfxViewFrame::GetPropertyContextId()

Examples

Notification of start of text editing in Draw/Impress:

   sd/source/ui/func/futext.cxx, FuText::DoExecute()

Notification of Draw/Impress having been started:

   sd/source/ui/view/ViewShellBase.cxx, ViewShellBase::Activate()

Migration of property pages

The Symphony property pages represent much functionality that in AOO can be found in toolbars. That may explain the extensive use of ToolBox controls in the panels.

Task

• Migrate the panels listed in http://wiki.openoffice.org/wiki/AOO_Symphony_UX_Migration/Merge_Analysis_-_Task_Pane or come up with a better list.
• Locate the panel implementation in the Symphony code branch. Typical places are:
  • svx/source/propertypanel/
  • sw/source/ui/propertypanel/
  • sc/source/ui/propertypanel/
  • sd/source/ui/propertypanel/
• Use ::sfx2::sidebar::SidebarPanelBase and ::sfx2::sidebar::ControllerItem::ItemUpdateReceiverInterface

as base classes. These take care registering at the ContextChangeEventMultiplexer and item controllers.

• Replace member declarations of controls with scoped_ptrs, so that the controls can be created by a factory and can have a different, derived class.

Replace

 ToolBox maToolBoxIncDec;

with

 ::boost::scoped_ptr<ToolBox> mpToolBoxIncDec;

Then, in the constructor replace

  maToolBoxIncDec (this, SVX_RES(TB_INCREASE_DECREASE)),

with

  mpToolBoxIncDec(sfx2::sidebar::ControlFactory::CreateToolBox(this, SVX_RES(TB_INCREASE_DECREASE))),

• Handle context changes:

Replace

   virtual void Init(PropertyContextType nContextId);

with

   virtual void HandleContextChange (
       const ::sfx2::sidebar::EnumContext aContext);

In the implementation replace

   void SvxTextPropertyPage::Init(PropertyContextType nContextId)
   {
       meContextType = nContextId;
       if(  nContextId == PROPERTY_CONTEXT_SC_CELL ||  nContextId == PROPERTY_CONTEXT_SC_PIVOT ) //modified::add s

with

   void TextPropertyPanel::HandleContextChange (
       const ::sfx2::sidebar::EnumContext aContext)
   {
       if (maContext == aContext)
       {
           // Nothing to do.
           return;
       }
       maContext = aContext;
       switch (maContext.GetCombinedContext())
       {
           case CombinedEnumContext(Application_Calc, Context_Cell):
           case CombinedEnumContext(Application_Calc, Context_Pivot):

The first lines (above the switch() statement) could be moved into the base class.

• Make a similar replacement wherever meContextType is used in if() statements.
• Replace the use of SfxPropertyPageController with ::sfx2::sidebar::ControllerItem. Controller items connect items (basically the model of toolbar buttons) and state change listeners (the panel that you are migrating).

In the header replace

  SfxPropertyPageController maFontNameControl;

with

  ::sfx2::sidebar::ControllerItem maFontNameControl;

In the constructor replace

   maFontNameControl (SID_ATTR_CHAR_FONT, this, GetBindings())

with

   maFontNameControl (SID_ATTR_CHAR_FONT, *pBindings, *this)

Also transform

   void SvxTextPropertyPage::StateChangedImpl(USHORT nSID, SfxItemState eState, const SfxPoolItem* pState)

into

   virtual void NotifyItemUpdate(
       const sal_uInt16 nSId,
       const SfxItemState eState,
       const SfxPoolItem* pState);

to be informed of state changes.

• Replace icons

Where possible we should use the standard AOO icons (although in same places we should thing about replacing the AOO icons with Symphony icons). Find the uno command name and do a replacement like:

   maToolBoxIncDec.SetItemImage(TBI_INCREASE, Application::GetSettings().GetStyleSettings().GetHighContrastMode()? maImgIncreaseHigh : maImgIncrease);
   maToolBoxIncDec.SetItemImage(TBI_DECREASE, Application::GetSettings().GetStyleSettings().GetHighContrastMode()? maImgDecreaseHigh : maImgDecrease);

with

   mpToolBoxIncDec->SetItemImage(TBI_INCREASE, GetIcon(A2S(".uno:Grow")));
   mpToolBoxIncDec->SetItemImage(TBI_DECREASE, GetIcon(A2S(".uno:Shrink")));

The GetIcon() method takes care (hopefully) of the high contrast mode.

• One source file may contain more than one class definition. It is good practice to separate these into their own files. And it makes it easier for others to work on other panels in the same source file.
• Use namespaces instead of the Svx class prefixes, ie use svx::sidebar namespace (or sw::sidebar, etc) and get rid of the Svx class prefixes.

Tips

Do the Draw/Impress panels last, these are more complicated than the others due to their use of an Impress specific framework.

Examples

See svx/source/sidebar/text/TextPropertyPanel.cxx in the sidebar branch for the first migrated panel.

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: Mac: Windows:

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

Linux: Mac: Windows:

Examples of toolbars in other applications:

Linux (file explorer): Mac (Garageband): Windows (File Explorer):

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.