Difference between revisions of "Sidebar"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Added "CreateColorPopupControl" section.)
(→‎Decks and content panels)
Line 238: Line 238:
 
**text (W,I,C/cell selected,C/(text (editing cell text)) (started) [http://issues.apache.org/ooo/show_bug.cgi?id=121798 121798] (Already assigned to zhengfan)
 
**text (W,I,C/cell selected,C/(text (editing cell text)) (started) [http://issues.apache.org/ooo/show_bug.cgi?id=121798 121798] (Already assigned to zhengfan)
 
*:svx/source/propertypanel/textpropertypage.cxx
 
*:svx/source/propertypanel/textpropertypage.cxx
−
**wrap (W) [http://issues.apache.org/ooo/show_bug.cgi?id=121799 121799]
+
**wrap (W) [http://issues.apache.org/ooo/show_bug.cgi?id=121799 121799] (assigned to orw)
 
*:sw/source/ui/propertypanel/wrappropertypage.cxx
 
*:sw/source/ui/propertypanel/wrappropertypage.cxx
 
* Migration of AOO decks and content panels (see [[AOO_UX_Design_Exploration_-_Task_Pane_Content_-_Information_Design#Task_Pane_Content_-_Proposal_for_discussion|proposal]])
 
* Migration of AOO decks and content panels (see [[AOO_UX_Design_Exploration_-_Task_Pane_Content_-_Information_Design#Task_Pane_Content_-_Proposal_for_discussion|proposal]])

Revision as of 07:49, 18 March 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

  • Impress panels are migrated.
  • Deck title bar has closer that hides deck but leaves TabBar visible.
  • Panel title bar supports button that opens detail dialog with more options.
  • Deck shows vertical scroll bar when not all panel fit into deck.
  • Developer builds are available, see below

Current screenshots:

27. Feb. 2013: Based sidebar colors on system colors provided by the SystemSettings class. The "Colors" panel (will not be in the release) shows all colors exported by SystemSettings. Screenshots are, from left to right, from Windows, Ubuntu and Mac. Sidebar-2013-02-27-windows.png, Sidebar-2013-02-27-linux.png, Sidebar-2013-02-27-mac.png.

19. Feb. 2013: Impress panels have been migrated (left). The closer in the deck title bar hides the deck but leaves the tab bar visible (right). The three master page panels are now first class citizens in the sidebar world. That makes it possible to reorder them or show/hide them independently.

Sidebar-2013-02-19-a.png, Sidebar-2013-02-19-c.png.

18. Jan. 2013: 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:

Sidebar-2013-01-18-a.png, Sidebar-2013-01-18-b.png, Sidebar-2013-01-18-c.png, Sidebar-2013-01-18-d.png

15. Jan. 2013: 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:

Sidebar-2013-01-15.png

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.
  • 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 [1] and [2].
  • 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.

Resources

Developer Builds

Current version is 0.7 from Februray, 22nd, 2013 for

All builds are archives, to avoid accidental installation. On Windows there seems to be trouble with the name of the top level directory ("Apache_OpenOffice_3.5.0 ..."). Possible fixes: - Copy the content of that directory to some other place and run from there - Rename to something shorter/simpler.


Changed since version 0.6:

  • Closer of deck title bar closes the deck but leaves the tab bar visible.
  • The Impress panels are now available:
    • Layouts
    • Master pages (all, recent, used)
    • Custom animation
    • Slide transition
    • Table
  • A special activation of the sidebar is not necessary anymore. It works now out of the box.

SidebarWorkbench

There is a Java extension for development and debugging of the sidebar. It can be downloaded here. Note that it writes a log file to /tmp/sidebar.log. On Windows without cygwin this may not work. Do not use the developer builds for important documents: there may be dragons (aka severe bugs).

On Windows and Linux you can use it to

  1. add some dummy decks and panels to the sidebar.
  2. monitor the current context. It is displayed in a panel in the Properties deck.
  3. modify the look of the sidebar with an external Java dialog called "Theme Dialog".

The "Theme Dialog" has three sections:

Presets
Ten buttons let you choose between the nine themes proposed on this UX page. A tenth button activates a theme that is similar to the original Symphony sidebar.
Options
More fine grained options for changing the panel title bar background (normal, dark), the panel background (normal, white), use of Symphony icons, use of system colors (not yet fully implemented), use of the high contrast mode color scheme. The later does not activate the high contrast mode. It is just a quick way to activate the color scheme.
Properties
A list of all the properties in the sidebar theme XPropertySet that are evaluated for the look of the sidebar. Editing is not (yet) possible.

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
  • Context matcher: decks and panels are displayed only for matching contexts
  • Icons for normal and high-contrast mode.
  • Oder index. Smaller is up, larger is down.
  • Service/implementation name of the implementation.

Legacy addons are find in the application specific WindowState configuration files and instaniated via the existing ui::UIElementFactoryManager infrastructure is 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

Decks and content panels

  • Configuration (all done)
  • 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(W), Calc(C), Impress(I) (see proposal)
    sc/source/ui/propertypanel/alignmentpropertypage.cxx
    svx/source/propertypanel/AreaPropertyPanel.cxx
    Basic adaption to AOO and new sidebar API done
    FillStyle change works for all fill modes
    When on FillStyle Color the button to the right is adapted to correctly show the fill color (also done for thext color controls, btw).
    When on FillStyle Color the color popup does not yet work (common popup problem)
    TransparencyType change works completely (added slots for this, re-implemented)
    When TransparencyType is on a TransparencyGradient the popup on the transparency button to the right does not yet work (common popup problem)
    The upper-right control triggers the area dialog (as intended)
    sc/source/ui/propertypanel/appearpropertypage.cxx
    svx/source/propertypanel/GraphicPropertyPanel.cxx
    Basic adaption to AOO and new sidebar API done
    This panel is pretty straightforwanrd and uses no special controls, works completely AFAIK
    svx/source/propertypanel/LinePropertyPanel.cxx
    Basic adaption to AOO and new sidebar API done
    The Width and Style popups do not yet work (common popup problem), visualization is adapted when selection different lines
    Correct line color is shown
    The line transparency is working now (slot added, implemented)
    The line start/end arrow style can be set, but gets not yet updated when changing selected object (currently looking into this, added slots SID_ATTR_LINE_START/SID_ATTR_LINE_END in svx, maybe still wrong adapted in other apps)
    CornerStyle and CapsStyle completely working, size of the panel adapted in ressources, too
    sc/source/ui/propertypanel/numformatpropertypage.cxx
    • page (W) 121793 (assigned to orw)
    sw/source/ui/propertypanel/pagepropertypage.cxx
    svx/source/propertypanel/paragraphpropertypage.cxx
    • position and size (I,C/chart and media,W/graphic,C/(text, line, shape and graphic),W/(text, line, shape)) 121795
    svx/source/propertypanel/TransformationPropertyPanel.cxx
    Basic adaption to AOO and new sidebar API done
    Values can be set in principle, but get not yet updated, also due to slots. Currently working on addin the needed slots
    For future double precision I'm also adding a new slot (SID_ATTR_TRANSFORM_MATRIX) which will allow direct access to the ObjectTransformationMatrix, thus all geometry values for the selection will be available in double precision (including mirroring). The implementation needs to be adapted to make use of this. The slot is implemented in svx, a AffineMatrixItem is created and prepared.
    The mirrorings do not yet work, slots for it (SID_ATTR_TRANSFORM_MIRROR_HORIZONTAL, SID_ATTR_TRANSFORM_MIRROR_VERTICAL), are prepared. These may be removed again later when using the AffineTransformation directly
    sd/source/ui/propertypanel/pagelayoutpage.cxx
    sd/source/ui/propertypanel/tabledesignpage.cxx
    • text (W,I,C/cell selected,C/(text (editing cell text)) (started) 121798 (Already assigned to zhengfan)
    svx/source/propertypanel/textpropertypage.cxx
    • wrap (W) 121799 (assigned to orw)
    sw/source/ui/propertypanel/wrappropertypage.cxx
  • Migration of AOO decks and content panels (see proposal)
    • Style List
    • Clipart
    • Navigator
    • Functions
    • Data Pilot
  • Migration of Impress panels (see proposal) (done)
    • Slide Templates/Master Slides
    • Custom Animation/Animation Effects
    • Slide Transition

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

like this 

 void DoSomething (const EnumContext& rContext)
 { 
 switch (rContext.GetCombinedContext())
 {
 case CombinedEnumContext(Application_Calc, Context_Cell):
 ...

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()

Creation of a panel factory

Panels are created by factories via the ui::XUIElementFactory interface and its 

 createUIElement(
 const ::rtl::OUString& rsResourceURL,
 const ::cssu::Sequence<css::beans::PropertyValue>& rArguments)

method.

Task

Implement the ui::XUIElementFactory interface.

The sidebar calles the createUIElement() method with the these arguments:

ParentWindow
a awt::XWindow object that is to be used as parent window for any new windows created by the panel. Both size and location of this parent window are modified by the panel layouter of the current deck. A panel that wants to layout its controls manually has to listen for size changes of the parent window.
Frame
the frame::XFrame object of the view for which the sidebar displays decks and panels.
SfxBindings
a pointer to an SfxBindings object (wrapped in a sal_uInt64) that can be used to create controls. This hack is intended as a temporary solution. It is desirable to replace it with a UNO based solution.

The panel factory is expected to create and return a ui::XUIElement object for a given URL. Create a new panel like this: 

 if (sURL.equals("my/panel"))
 {
 Control* pPanelControl = new PanelControl(pParentWindow, xFrame, pBindings);
 return sfx2::sidebar::SidebarPanelBase::Create(
 rsResourceURL,
 xFrame,
 pPanel);
 }

Examples

See svx/source/sidebar/PanelFactory.cxx


Creation of a panel control

The content of a panel is typically painted by an instantiation of the vcl::Control class. The XUIElement interface gives access to the XWindow component of the control via the XUIElement::getWindow() method.

Task

Implement the XUIElement interface and add it to a panel factory.

Choose a panel factory in the module where the new panel class will be located. Add support for the panel class to the XUIElementFactory::createUIElement() method.

You can use the sfx2::sidebar::SidebarPanelBase class for taking care of the boiler plate code. Despite its name (which should be change) SidebarPanelBase is not a base class for the new panel class. Due to the design of the XUIElement interface (with its XUIElement::getRealInterface() and XUIElement::getWindow() methods) the XUIElement interface can be implemented independently from the actual panel control. SidebarPanelBase implements the XUIElement::getRealInterface() to return itself. It implements the XUIElement::getWindow() to return the awt::XWindow interface of the panel control. XUIElement::createAccessible() is not yet implemented. The SidebarPanelBase provides additional functionality:

  • Forwarding of context change events: It registers at the ContextChangeEventMultiplexer and forwards all relevant events to the panel control if it implements the ContextChangeReceiverInterface interface (which is a local class of SidebarPanelBase). It uses a

dynamic_cast<> to check if the interface is supported. If it is SidebarPanelBase converts the event data to an EnumContext object and calls ContextChangeReceiverInterface::HandleContextChange().

  • A simple implementation of the ui::XVerticalStackLayoutElement interface that returns the current height of the control (mpControl->GetSizePixel().Height()).

For the implementation or migration of the actual panel control see the following section.

Example

See svx/source/sidebar/PanelFactory.cxx for the use of the SidebarPanelBase class. See svx/source/sidebar/text/TextPropertyPanel.cxx for the implementation of the HandleContextChange method.

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 of 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 type:

Replace 

 ToolBox maToolBoxIncDec;

with 

 ::boost::scoped_ptr<Window> mpToolBoxIncDecBackground;
 ::boost::scoped_ptr<ToolBox> mpToolBoxIncDec;

The mpToolBoxIncDecBackground object is the background/border of the tool box control while mpToolBoxIncDec is the actual tool box object. Then, in the constructor replace 

 maToolBoxIncDec (this, SVX_RES(TB_INCREASE_DECREASE)),

with 

 mpToolBoxIncDecBackground(ControlFactory::CreateToolBoxBackground(this)),
 mpToolBoxIncDec(ControlFactory::CreateToolBox(
 mpToolBoxIncDecBackground.get(),
 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.


Migration of popup controls

Some Symphony panels have non-trivial popup (or drop down) controls that contain more than a list of strings. These are often implemented via this pattern (taken from svx/source/propertypanel/areapropertypage.hxx). Variables: 

   SfxPopupPanelWin* mpTrGrFloatWin;
   class SvxAreaTrGrPage;
   SvxAreaTrGrPage* mpTrGrPage;

Functions: 

   DECL_LINK( ClickTrGrHdl_Impl, ToolBox* );
   SvxAreaTrGrPage* GetTrGrPage();
   SfxPopupPanelWin* GetTrGrFloatWin();

The ClickTrGrHdl link is called when the popup is requested to be displayed. The GetTrGrPage() and GetTrGrFloatWin() functions contain identical code for constructing the popup windows and return either the inner or outer window. The code in all three methods is very similar for many different popups.

The new Popup class (header can be found in svx/inc/svx/sidebar) factors out the repeating code. It is a wrapper around the two classes PopupContainer and PopupControl. PopupContainer is the outer window that provides the actual drop-down functionality. Different popups use it as is. PopupControl is a base class for the inner windows that provide the actual popup content. Its parent is a PopupContainer object. For a new popup you have to derive from this class. It only provides painting the background and border.

The above variable and method declarations can be replaced by: Variables: 

   AreaTransparencyGradientPopup maTrGrPopup;

Functions: 

   DECL_LINK( ClickTrGrHdl_Impl, ToolBox* );
   PopupControl* CreateTransparencyGradientControl (PopupContainer* pParent);

One variable (maTrGrPopup, the Popup wrapper) instead of two. The ClickTrGrHdl is still there but its implementation is basically just a forward to maTrGrPopup.Show(). The new CreateTransparencyGradientControl() method is a factory method that returns a new instance of a class derived from PopupControl (in this example that class is AreaTransparencyGradientControl).

The maTrGrPopup member is initialized in the constructor of AreaPopupPanel like this: 

   maTrGrPopup(this, ::boost::bind(&AreaPropertyPanel::CreateTransparencyGradientControl, this, _1)),

by which it is informed of how to create the inner PopupControl window.

For details please see the real life examples 

   AreaPropertyPanel uses maTrGrPopup of type AreaTransparencyGradientPopup with control AreaTransparencyGradientControl
   AreaPropertyPanel uses maColorPopup of type ColorPopup with control ColorControl

Note that ColorPopup and Color Control can be found in svx/source/sidebar/tools because they are use by different panels. 

   LinePropertyPanel uses maLineStylePopup of type LineStylePopup with control LineStyleControl
   LinePropertyPanel uses maLineWidthPopup of type LineWidthPopup with control LineWidthControl
   LinePropertyPanel uses maColorPopup of type ColorPopup with control ColorControl

Note that the factory methods CreateColorPopupControl() in AreaPropertyPanel and LinePropertyPanel differ slightly.

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):

screenshot-sidebar-symphony.png


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.

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Sidebar&oldid=217124"
Personal tools