Native Widget Rendering

Document - ID	Specification Owner	Last Change	Status
	Stephan Schäfer	01/14/2005	Final
Conforms to	
Applies to	VCL
Task ID(s)	i25130
Category	Feature

Abstract

To better integrate OpenOffice.org with the underlying desktop environment all widgets should have the same look as those used in native applications for that platform. This includes the proper reaction to changes of the desktop theme which should change the look immediately.

i-Team Members

	Name	E-mail Address
User Experience	Christian Jansen /CJ	christian.jansen@sun.com
Development	Stephan Schäfer /SSA	stephan.schaefer@sun.com
Quality Assurance	Thorsten Martens /TM	thorsten.martens@sun.com
Documentation	Frank Peters /FPE Uwe Fischer /UFI	fpe@sun.com uwe.fischer@sun.com
		mailto iTeam

Approved for Implementation

	Approved by	Date
User Experience	CJ	31.03.04
Development	SSA	31.03.04
Quality Assurance	TM	01.04.04
Documentation	FPE UFI	01.04.04
String Review	EM	14.04.04

Document Change History

Rev. Level	Change	Initials	Date
1.0	initial version	SSA	30.03.04
1.1	added temporary screenshot for Vew options	SSA	01.04.04
1.2	received iTeam approval	SSA	01.04.04
1.3	removed temporary screenshot of ViewOptions dialog	SSA	27.04.04
1.4	added list of supported controls	SSA	28.04.04
1.5	added UI Font section	SSA	23.06.04
1.6	added tool bar, menu bar and popup menus to list of supported controls	SSA	14.01.05
1.7	column and row headersuse flat look on all platforms	SSA	23.11.04
1.8	UI Design of Toolbars for Window XP Luna Look specified	CJ	Jan. 14, 2004

Contents

Glossary	1

Glossary

Term	Description
Widget or control	A user interface element like a button, scrollbar or edit field.
Native widget	A widget that is provided by the system for use in all applications. Because OpenOffice.org implements its own widgets they look the same on all supported platforms.

Motivation

OpenOffice.org comes with its own look which is closely related to the look of Windows 95. Regardless of the underlying platform, the look is always the same. It is the user's responsibility to change the look of OpenOffice.org by choosing a different 'Look&Feel' under Tools->Options->View. However, those looks are hard coded and do not necessarily reflect the look of the environment.

As a solution, all widgets (or controls) should be rendered using the platform's own widget drawing methods which will give OpenOffice.org the same look as a native application on that platform. This will have no affect on the functionality (or feel) of the widgets, it will only affect their look.

Changes to the User Interface

In general the UI should behave exactly as before. All widgets must still have all of their functionality, nothing should work differently than before.

To not change the look of documents however, native widget rendering will not be used in form controls. Controls in documents must use the (same) classic look on all platforms.

Changed View Options Dialog

Because several options in Tools->Options->View make no sense in combination with native widgets (and are questionable even without it) they will be removed. This affects the following options:

Look&Feel

Flat buttons

Menu follows mouse pointer

Single line tab headings

Colored tab controls

The following options are renamed or changed:

Display -> User Interface

Scale -> Scaling

Additionally the scaling percentage can only be chosen between 80% and 130%.

The option:

Use system font for user interface

is moved from the Accessibility options page to the View options page. See also chapter UI Font

For better readability disabled UI elements will have their text rendered without an additional white shadow. When running under Windows XP and using the new Windows XP style 3D borders should be avoided to better fit the overall flat look. As an example the following screen shot shows the changed status bar, but it will also affect borders of drop down windows and other window borders:

Figure 1 Status bar without 3D borders

The following screen shot shows the new Tools->Options->View page:

Figure 2 Changed View options

String list

Item	English	German	Comments
	Scaling	Skalieren	
	User interface	Benutzeroberfläche	
	Toolbar icon size	Symbolgröße	
	Show inactive menu items	Inaktive Menüeinträge anzeigen	
	Font lists	Liste der Schriftarten	
	Show preview of fonts	Schriftartenvorschau anzeigen	
	Show font history	Benutzte Schriftarten anzeigen	was Schriftarten Historie...

Supported Controls

The following controls will fully support native widget rendering:

Push Button

Radio Button

Check Box

Combo Box

Edit Box

List Box

Spin Box

Tab Page and Tab Items

Scroll Bar

Menu Bar

The menu bar shall be visually separated from the Top toolbar docking area. The horizontal separation border shall have a height of 1px and shall be painted in “ShadowColor; 50% transparency”.

Popupmenus

Tool Bars

Note: due to limitations (i.e. bugs!) of the corresponding API on Windows XP, popup menus will only pick up the constant background color and the constant selection color. Special effects like gradients etc. will not show up. However, this can only be activated using 3rd party software like e.g., WindowBlinds. The default Windows XP visual styles do not make use of this. On Windows XP the tool bars and the menu bar should look like the tool bars in the Windows Explorer. (In fact there are different possibilities to render tool bars and menu bars on Windows, just compare WordPad with Explorer)

Windows XP Toolbar Design

Docked

Figure 4 shows how docked toolbars shall appear by default on Windows XP platform. A docked toolbar comes with a set of style elements specified below:

Toolbar Background: As background shall be painted by using the Rebar Control. This control is Specified in . The Rebar shall cover the menu – and the toolbar docking area Top, Bottom, Left, Right.

Toolbar Border: Each toolbar shall provided on each side a 1px width border

Toolbar Border Color:

Toolbar ShadowColor; 50% Transparency LightColor; 50% Transparency Figure 3 Toolbars and their border color

Figure 4 Example of two docked toolbars on Windows XP

Floated

On Windows XP platform each floated toolbar shall display the design, specified by the current theme. For displaying the theme, the Rebar Control shall be used.

Toolbar Design on Systems Greater Then GNOME 2.4

Docked

On GNOME platform each docked toolbar shall display the design, specified by the current theme. This includes also the border.

Floated

On GNOME platform each floated toolbar shall display the specified by the current theme.

The following more complex controls currently (OpenOffice.org 2.0) do not support native widget rendering, but are planned for future releases:

Rulers

Status Bar

Tree View Control

Column Header

To improve the look of column and row headers which can be found in the datasource window or the table control, any use of 3D borders should be avoided. The look should be the same as for the table headers in calc, i.e., flat and with a coloured selection indicator. This should be the same for all platforms:

UI Font

For better desktop integration OpenOffice.org will initially try to use the system's UI font. This means the default setting of the corresponding option has changed. To avoid choosing a font that does not fit to the UI language of OpenOffice.org, a test is performed that checks if typical glyphs can be rendered. If this test fails, the option will be unchecked and disabled. This will hinder the user to choose a UI font that makes OpenOffice.org unusable. If the system's UI font was changed to a usable font, the option will be available again after reopening the dialog.

Supported Platforms

Native widget rendering will only be available for Gnome (Version 2.4 or higher) and Windows XP (and future versions). On Windows XP the Windows XP Style must be chosen under Settings->Control Panel->Display->Appearance.

A version for KDE is developed by the community but cannot be included currently due to licensing issues.

Using native widget rendering will be the default and not an option on the supported platforms. This means there is no way to switch back to the classic look using the OpenOffice.org UI. The application will always pick up the settings of the system.

Changes to the desktop theme should directly affect the running application so that it always reflects the current system settings.

On platforms not supporting native widget rendering (e.g., Windows 98/ME/2000, CDE) the look of the application should not change.

Ideas For A Test Plan

OpenOffice.org must still work on all supported platforms (because support for native widgets is loaded dynamically at runtime it might crash on platforms that do not support it - of course it should not!)

Form controls must have the same look on all platforms. Printing of form controls must work.

Theme changes must be adopted immediately without problems. Check that different themes look the same in OpenOffice.org as in native applications. They should also react accordingly (highlight effect)to mouse over. Note: not all themes support this effect.

It would be great to have an automatic test script that opens all dialogs and saves a screen shot, so we can easily see where dialogs must be changed due to system requirements like colors. arrangement of controls etc.

Specification of the Rebar Control

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/rebar/rebar.asp

<Required – This paragraphs gives the audience idea of what to aspect from this document. It should be described shortly what problem will be solved.>

The source of software product implementation and change is the I-Team (Implementation Team). I-Teams are typically comprised of people who have skills in the areas of Product Marketing, Development Engineering, Technical Publications, and Test Engineering. I-Teams define the features or set of changes (based on input from SCs, customers, Engineering, or Marketing), plan the implementation project, perform the implementation and testing...

Native Widget Rendering

Page 6

Stephan Schäfer

2004-03-30T18:56:02