The Free and Open Productivity Suite
Released: Apache OpenOffice 4.1.15

Meeting Minutes

Bi-Weekly Meeting common User Interface (CUI)


November 20th, 2003


10am, MEST


Palo Alto, eham02


+ Oliver Specht (OS)
+ Christian Jansen (CJ)
+ Matthias M�ller-Prove (MMP)
+ Hans-Peter Burow (PB)
- Daniel Rentz (DR)
+ Frank Sch�nheit (FS)
+ Gunnar Timm (GT)
+ Christian Lippka (CL)

+Mathias Bauer
+Henning Brinkmann
+Stephan Schäfer

Minute Taker

MMP (next: OS, PB, GT, OS, DR, CJ, CL, FS, MMP)

Distribution List

Table of Contents

1 Action Items

2 Roundtable

1 Action Items




previous items

Arrange meeting to discuss technical problems for new context sensitive toolbar handling

Christian Jansen


new items

Provide a list of controls in OOo to support the project of native controls

Christian Jansen new
BP will find out if the TabListBox can be utilized for a two column tree control Hans-Peter Burow new

1.1 Comments on Action Items

2 Roundtable

2.1 Undo

2.1.1 Undo History

Henning wrote a spec for a more descriptive undo history in OOo Writer. We will adopt this approach for all OOo modules. It has to be specified what actions need a better name. >Insert "Oxmox"< in OOo Writer is fine while >Move Frame to Position xy< is less informative. For OOo Calc we should display the affected cells. [cf.]

2.1.2 Undo Steps

We like to improve the chunks for undo actions. E.g. typing in OOo Writer records: >Word1 | SPACE | Word2< as 3 steps, rather than taking Word1+SPACE as 1 UNDO action.

Replace All is treated as 1 undo action.

Spellchecking is treated as several actions. [cf.]

According to OS, a Save operation in OOo Writer flushes the undo stack. As the other modules do not show this behavior this is considered as a bug.

Redlining in OOo Writer tables is a problematic area for undo.

What about document property dialog changes. They definitely change the document. Are they candidates for undo? In any case they should not flush the undo stack.

Insert a object from the Navigator to the document with drag&drop. The object is inserted as a section. And the action cannot be undone. This is another candidate to improve the undo capabilities of OOo.

Please contact Matthias ( to point out more areas for undo.

2.1.3 Limited Undo Stack

We have no statistical data on the memory footprint of the undo stack. But 20 steps is definitely a too small number. We decided to increase the default [Options>OOo>Memory>Undo>Number of Steps] to 100. A new maximum is needed because an unlimited (= just memory constrained) undo stack is technically not possible for OOo2.0

2.1.4 Undo of Macros

The situation is complex. Macros start and stop. They change documents, not necessary just the document that was active when they were started. Additionally macros can run in parallel.

For undo have to distinguish at least between programmed macros and recorded macros. For recorded macros we can offer a one step undo because they are related to just one document.
All other macros can not be treated as one-step undo-able. If they cause actions in a document these actions are added as plain actions to the undo stack. To give feedback to the user about the origin of the action the name of the macro can/should (?) be added to the undo history as a disabled item >Macro m1 started< ... >Macro m1 finished<

Undo API

The undo API needs functions to access the undo stack.

  • what actions are in the undo stack?
  • move back & forward in undo stack

We do not need undo calls to add new items to the undo stack.

UNO calls should wrap the undo API calls.

2.2 Native Controls

Stephan Schäfer and Dan Williams are working on native controls for OOo2. Stephan with focus on Windows, Dan on Gnome. OOo 2.0 will utilize native controls from the operating systems. Buttons, combo boxes, check controls, radio controls, tab controls, and scrollbars (to name a few) will be drawn by the OS libraries.

This is VCL-internal. Proprietary controls outside VCL keep the OOo1.1 style. This means that e.g. rulers, progress bars, header bars are not affected by this change. Nonetheless they can adopt style elements like disclosure plus/minus signs for tree list controls in the future.

Menus are not part of the native controls project. They have to be considered in a separate step.

OS: Windows

VCL will use Windows XP Theme API calls to draw the controls in OOo. Window Blinds are supported. This gives OOo the Luna look for Windows XP. We are also prepared for Longhorn in the future.

Windows 2000 uses a different API. We have to see to what degree the changes work here as well.

OS: Gnome

OOo2 will support native controls on Gnome.

OS: Mac

OOo 2 will no longer have the option Option>>View>Look&Feel. But the use of native controls is also a huge step for an Aqua version of OOo on Mac OS X.

Form Controls

OOo will continue to use our own controls for form elements. This assures that documents look the same on all platforms, and that all features are available.

Basic Dialog Editor

The Basic dialog editor will adopt the native controls. Printing of dialogs is an open question.


In OOo 1.1 VCL draws the text for all controls. It was key to provide an API for assistive technology to tell what string is at position xy on the screen. If the controls draw the text on their own we have to find a solution to gather the information for the assistive tools. Maybe we provide an internal flag to draw the text the one way or the other.

Changes in Appearance Options

  • Options>>View>Look&Feel is no longer needed.
  • Options>>View>Colored Tab Controls is no longer needed.
  • Options>>View>Single Line Tab Headings is another candidate to go away.
    • some DB dialogs make heavy use of this feature. We have to wait until this dependency is gone.

Problems today

Highlighting/hot state/mouse over is not working yet.

UI-mirroring for right-to-left user interfaces (RTL) can bear some problems with shading, ie. the light source coming from top right instead of top left. We can address this for Windows, while Gnome is an open area.

2.3 Two-Column Layout for TreeView Control

CJ likes to introduce a two-column tree control for the customization of the menu structure. 1st column displays the menu items, while the second displays the shortcuts. A requirement is that the columns are sizable. PB will find out if the TabListBox can be utilized for this

Apache Software Foundation

Copyright & License | Privacy | Contact Us | Donate | Thanks

Apache, OpenOffice, and the seagull logo are registered trademarks of The Apache Software Foundation. The Apache feather logo is a trademark of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners.