Presenter Screen/Implementation

From Apache OpenOffice Wiki
< Presenter Screen
Revision as of 10:45, 29 October 2007 by Andre (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page describes the implementation of the Presenter Screen.

Location of the code

The presenter screen is realized as extension in the sdext project in /sdext/source/presenter. Supporting code in the sd project can be found in /sd/source/ui/presenter.


The presenter screen is activated when a full screen presentation is started and is deactivated when it ends. The full screen presentation is displayed in its own application window with its own SfxViewShell and XController.

When the presenter screen is started it moves its application window (not the one of the full screen presentation) to the screen not occupied by the slide show and makes its fullscreen (this behaviour is not yet implemented). The menu bar, status bar, the tool bars, and the side panes are hidden. In their place the presenter screen controls are displayed:

  • A second view of the current slide. The primary view is displayed in the full screen presentation.
  • A preview of the next slide.
  • The notes of the current slide.
  • A clock that shows the current time.
  • Navigation controls.

The set of presenter controls and details of their display (e.g. the clock might also show the elapsed time since the beginning of the slide show) is not final and subject to change.

When the slide show ends then the presenter screen controls are removed, the application window is restored to its previous size and location. The menu bar, status bar, the tool bars, and side panes are also restored to their previous state.

Use of the drawing framework

The drawing framework that is used to handle the regular Draw and Impress UI is also used to implement the presenter screen.


When the full screen presentation is started then a new application window is created with, among other things, is own instance of the drawing framework. This is the reason for a little trick to make the start of the full screen presentation known in the drawing framework instance of the original application window: the top level resource private:resource/view/Presentation (sibling to the anchor panes) is created that has no functionality to speak of is created. It is a marker for the running slide show. Its activation, and later its deactivation, is notified like the activation of all other drawing framework resources.

The presenter screen extension registers on start-up of the drawing framework (during creation of loading of a document) a listener that just waits for the marker of the full screen presentation to appear. When that happens the presenter screen is started.


The presenter screen is started by creating an instance of the service. It is implemented by the PresenterView class.

As first thing it stores the current configuration of the drawing framework, so that later, when the full screen presentation ends, the current set of panes and views can be restored. Then all panes and views are deactivated to make room for the presenter controls.

The full screen pane resource private:resource/floater/FullScreenPane is requested. When activated, it hides the menu bar and deactivates the layout manager of the framework. This hides the status bar, the tool bars and all remaining docked or undocked floating windows. Todo: make the application window full screen and, when there is more than one screen, move it to the screen that is not occupied by the full screen presentation.

All this leaves a completely empty window that is now filled with the presenter controls. The new PresenterView object reads the configuration and looks for the Presenter/Layouts/DefaultLayout/Layout node. It contains a set of descriptions for the indiviual presenter screen controls. For each there is the resource URL of a pane and a view, as well as size and location of the pane and an optional title string. The panes of the controls are created with the full screen pane as anchor. They are anchors themselves for the views. The resources are requested to be activated. Position, sizes, and titles are stored in the PresenterPaneContainer. When the panes are eventually activated the PresenterWindowManager looks up locations and sizes and places the panes accordingly.

Finally the PresenterView object instances the PresenterController class and passes over control over the presenter screen.


When the marker of the full screen presentation is deactivated then all the PresenterView has to do is releasing the objects it has created and restore the drawing framework configuation that was saved during startup. This leads to the deactivation of all the presenter controls and their panes, deactivation of the full screen pane (resulting in leaving the full screen mode, moving the application window back to its original location, and showing again the menu bar, status bar, tool bars, and floating windows), and finally the re-activation of the previously visible Impress views.


The panes used by the presenter controls use the service. It is implemented by the PresenterPane in sd. Reasons for it being in sd and not in the extension are

  • A feature in the developer version, but probably not in the final version, is that panes can be moved and resized with the mouse. This requires the mouse to be captured while the left mouse buttons is pressed. There is no API support for this at the moment.
  • The border of the PresenterPane is painted with bitmaps (more on that below). Bitmaps for the canvas can not yet be loaded via the UNO API.
  • Some window properties (currently available or upcoming) can not be accessed via the API.

The visual representation of a presenter pane consists of two parts. The inner content window and the surrounding border. The content window is painted by the view that is associated with the pane. The border is painted by the pane itself with the help of bitmaps.


There is support for themes so that

  1. different panes can have different looks (for example the title bar of titled panes and panes without panes may look differently) and
  2. the look of the complete presenter screen can be replaced by another one (for example a light and a dark theme can be used in light and dark environments).

Themes are defined via the configuration. See Impress.xcs in officecfg/registry/schema/org/openoffice/Office/ for a documentation of the schema and Impress.xcu in sdext/source/presenter for a definition of the default theme.

Themes are implemented as service
in sd/source/ui/presenter/PresenterTheme.cxx. Create the service with the name of the theme, or an empty name for the default theme. Bitmaps and fonts are provided as properties. See PresenterTheme.hxx for more information. Borders are rendered by the PresenterPaneDecoration class in sd/source/ui/presenter/.

Both PresenterTheme and PresenterPaneDecoration are located in the sd project. PresenterTheme loads bitmaps which, at the moment, can not be done from within an extension. However, it should be possible to move the PresenterPaneDecoration class into the extension. It then has to be made known to the PresenterPane objects, maybe via a XPaneBorderRenderer interface.

The use of the configuration to define presenter themes has the advantage that themes can be supplied as very simple extensions that consist only of a couple of XML files, most importantly an Impress.xcu file with the actual theme definition, and, of course, the bitmaps referenced in the theme.

Personal tools