VCL UI Rework

From Apache OpenOffice Wiki
Revision as of 15:21, 7 June 2007 by Cl (Talk | contribs)

Jump to: navigation, search

Rational

Currently all dialogs (along with most translated strings) are stored in a rather unusual binary resource file format, that has not had much love in the last decade. We need to write some new code that separates the process of designing & laying out the UI from the code - to allow UE to make our UI more beautiful, and allow future re-factoring. The existing Basic GUI dialog editor and it's XML format should be re-used, a simple C++ compatibility API created, and a number of dialogs converted to the new format.

Requirements

There have already been several attempts at adding features to VCL, and of course people have different requirements, an initial synthesis of requirements is perhaps helpful. Please do add subsequent constraints, or comments thereof.

Simple code changes (Mandatory)

Of course, we want to remove lots of code - all the immediate construction of non-core widgets that do not require special handling for a start. However - given the scope of the problem, it does not seem sensible to require some vast re-writing of each & every dialog from day 1. ie. re-implementing all callbacks using a UNO Listener type interface would kill the task, we should stick with existing callback mechanisms and signatures.

QA Test tool (Mandatory)

We need to ensure either, that relevant qa testtool tests are updated to use the new UI code, or that we have a strong back-compat story here.

Re-use of existing code (Desirable)

Clearly the existing form code has not only a working XML serialization, but code to (re)store from that, re-using that where at all possible is important. Unfortunately this code is rather complex and difficult to work with. A life-boat approach to creating a new cleaner, smaller structure and moving dialogs across would perhaps be better.

Simple new APIs (Important)

The existing & successful [libglade API] is a good model to build from. Identifying widgets and signals by strings seems to scale well and be more extensible than the SID based system.

I18n (Important)

The i18n story is important, quite possibly we'll want to process any Form XML to introduce integer IDs to identify strings, feature creep into re-writing i18n might kill this project.

Layout (Mandatory)

Adding automatic layout, as modern toolkits do, would substantially help improve the look of the UI, it's portability to other platforms, and also it's look when translated.

Reduced Inheritance (Desirable)

Currently all dialogs inherit (somehow) from VCL's Window class. Such inheritance from virtual bases generates large vtables, and substantial inefficiency across the code-base. Wherever possible we should have a child instance of the relevant window & use an aggregating pattern. In other cases, we may want to have a simple base class to inherit from with 'Show' / 'Hide' type methods that chain to the aggregated instance, and in more complex situations stick with an inherited approach.

It would also be good to do some code size profiles of the resulting code, to optimise for reduced code size.

New file format (Desirable)

Deprecating the rsc code, and preferably removing it is a good goal.

Proposed Design

Some sensible phases of the work might be:

  • Implement layout / container implementations
  • Implement new, simple, hierarchical XML serialization of widgets & layout
  • Implement helper API & port sample dialogs
  • Implement resource file encapsulation
  • Implement support in dialog editor in basctl (optional)
  • Commence porting dialogs

layout / container implementations

Several prototypes out there to choose from. Various decisions

  • as little new API as possible - use introspectable / self describing 'child' properties
  • only the basic box, table and alignment primitives necessary to start with

new XML format

This should be based on the widget hierarchy and property names, suitable mangled.

helper API

In order to reduce code impact, we should incrementally create (inline?) wrapper api around the AWT UNO APIs, providing VCL-like back-compatibility logic, to substantially limit the scope of the code changes. We should provide 'placeholders' whereby complex widgets can easily be inserted into the layout & used as-before.

We should port at least 3 sample dialogs.

resource file

The resource file format can re-use the package code for a .zip encapsulation, though some tweaks will be necessary to populate an existing dialog parent with widgets, for those widgets that are re-used elsewhere.

support in dialog editor

This will require more GUI work, extending the palette and adding properties specific to layout containers.

  • NetBeans has an interactive GUI editor that also supports layouts. Quickstart Guide
Personal tools