VCL UI Rework
Contents
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 basic layout containers in toolkit/
- Implement import in xmlscript/
- Implement support in dialog editor in basctl/
- Implement resource file encapsulation / helper API
- Commence porting simple dialogs
Basic layout containers
These can be based on Michael's previous layout prototype: the essence of which was to retain the flat VCL widget hierarchy - while having a parallel layout / containment hierarchy to perform the layout. Since toolkit/ implements the useful (albeit strangely named) XLayoutConstrains interface, this can be done rather easily in toolkit/. We should initially aim to implement only a few simple containers: Box / Alignment etc. and add more as we go.
import in xmlscript
This will require some new parent elements to represent the containers and some re-factoring of the import / export code here. This can be done on hand-tweaked files.
support in dialog editor
This will require more GUI work, extending the palette and adding properties specific to layout containers.
resource file / helper API
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.
porting dialogs
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 limit the scope of the code changes.
