“Toolkit 2”

Version 0.1

November 2002, Malte.Timmermann@sun.com

Orientation

A GUI toolkit may be viewed as a set of increasingly rich layers for constructing graphical applications. The Toolkit 2 is intended two cover 2 big areas for creating applications like OpenOffice.org: The drawing or rendering API for the document content as well as everything needed for the user interface, which included widgets, layout manager and resources.

Rendering layer

The rendering layer provides a primitive drawing API for text, lines, arcs, polygons, bitmaps and much more.

The new rendering layer is primary for the document content but may also be used for creating custom widgets not provided from the new toolkit itself.

Widgets

The toolkit provides a set of widgets or controls as basic building blocks for the application user interfaces, including labels, edits, buttons, menus, check boxes and many more.

This part of the toolkit can also be referred to as 'Chrome'.

The chrome does not only contain the widgets itself but also a resource system and layout management.

Different kinds of GUI toolkits

There are different kind of toolkits:

-	Native platform GUI toolkit
Toolkit recommended by the platform vendor for GUI applications.

-	Multi-platform GUI toolkit
GUI toolkit attempts to build on the higher-level widgets/controls of the platform toolkit.

-	Cross-platform GUI toolkit
Toolkit that is built on the lowest-level graphical capabilities of the platform.

-	Platform-aware GUI toolkit
Cross-platform GUI toolkit that uses platform-sensitive themes.

Current status of OpenOffice.org

The current toolkit for OpenOffice.org is the 'visual class library – VCL'.

VCL can be seen as a cross platform GUI toolkit with some features of a platform-aware GUI toolkit. VCL is capable to use colors and some other settings from the operating system, but it has it's own look&feel for the different UI elements.

Why a new toolkit?

With a new toolkit, we want to create the base for new components and to remove VCL dependencies.

When components create their widgets only via the toolkit, it's easy to change to toolkit implementation and create system widgets instead of VCL widgets.

And if components uses only the toolkit rendering layer, you can easily exchange that implementation with e.g. a platform optimized one.

And last but not least: If we change all current application code to use the toolkit instead of VCL directly, it's possible to remove VCL sometime.

Examinations

Widgets

The application code creates the widgets in the C++ code directly with 'new <VCLWidgetClassName>', so you can't easily exchange the implementation e.g. for using system widgets instead of VCL widgets. Also there is not reference counting for the UI object.

If we want to use system widgets we also need some layout managing, because widgets can look very different on the different platforms.

For the same reason, we need a new resource system, which can be used with different toolkit implementations, and we need some more information for the layout.

Rendering layer

The application uses the VCL output device for drawing operations and text layout and has strong dependencies to VCL. The output device API is quite outdated and lacks of functionality like 3D support, which is needed for a power full drawing application.

Goals

The long term goal is to remove all VCL dependencies from the application code and use only the new toolkit.

Widgets

The new toolkit should use system widgets for better platform integration. We want to use the same widgets like all other applications on that platform, being a good citizen.

For this we also need layout management and a new resource system.

Rendering layer

We need the new rendering layer as base for the new drawing engine, which must have better support for 3D, poly polygons and images.

Customizable UI

It should be possible to exchange the UI from OpenOffice.org.

Design

Widgets

To be done.

Rendering layers

To be done.

Customizable UI

To be done.

Migration path for OpenOffice.org

We must offer an easy migration path to the new toolkit, because not all application code can be changed immediately.

Easy step-by-step migration

New graphics additionally, application code can be changed any time

Parts of GUI can change to Toolkit 2 step-by-step

Rework application GUI code, use Toolkit2

No magic changes behind VCL, widgets must be created via the toolkit, otherwise we will still have no reference counting and it will not be possible to remove VCL

Keep VCL for form controls?

We must keep VCL at least until all application GUI code is changed, which can be done step-by-step

I suggest to keep VCL implementation for the form controls

Forms may have layout problems when using system widgets

Native widgets will not be printable

Other problems with system widgets

If the layout doesn't matter, it's possible to use system widgets and provide printing routines, but then printed controls might look very different from controls used on the screen.

Resource file conversion

We need a ways to easily convert old resource files to the new syntax

First steps

It will take some time to design the new toolkit and implement it for different platforms, and it will take a lot of time to change all application code, so I suggest to do the following first:

UI code separation from the application code

The application should create all dialogs via a dialog factory or something like that, so dialogs can easily be exchanged.

For this we must create interfaces for the different dialogs used in OpenOffice.org, or at least specify a list of properties which can be exchanged.

Same must be done for context menus, but this can be a little bit difficult when the application creates the entries dynamically.

Best would be if the applications where something like 'engines', which don't create any UI elements itself and only offer notifications, all UI can be done in an other layer.

New rendering layer

We must create a new rendering layer, which first implementation must be based on VCL. So it's possible to start with the new drawing engine based on the new interfaces, which will be supported from current VCL windows, and old application modules can still work on the VCL output device and switch to the new interfaces later.

New widget APIs

Define the new APIs and create a reference implementation based on VCL.

It will take a lot of time to change all existing application code, so for easier migration we need a VCL based implementation and change the application code step by step.

Before we start changing any application code we also need the new resource system and the layout management.

Maybe it possible not to use VCL, but draw into the existing VCL document window?

Malte Timmermann

2002-02-23T09:40:41