Difference between revisions of "VCL UI Rework"

Revision as of 18:54, 12 April 2007

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.

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.

Re-use of existing code (Important)

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. Furthermore, this would allow the existing GUI editor to be used by the UE team to tweak GUIs without extra help (or conceivably OO.o to tweak it's own GUI at run-time) which would be much appreciated. Finally - adding layout support to the form editor would be rather helpful for all OO.o users.

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 SIDs to identify strings, feature creep into re-writing i18n might kill this project.