Re-Arranging the common Office UI code

The Situation
The Goals
The Way

Keep it (for the moment?)
Toolbox Controllers
Tab Pages
Floating Tools
Factories
Proposed Libraries

The Situation

Currently, the code for common user interface (I'll abbreviate this with CUI from time to time) elements are wide-spread over at least 4 different projects: SVTOOLS, SFX2, SVX, OFFMGR.
This includes:

• common base classes like the SfxTabDialog/SfxTabPage

• frequently used components such as Character Formatting

• self-contained components like the internal file-open dialog

• common toolbox controllers like the one for the Undo/Redo-dropdown

• specialized SfxPoolItems

Note 1: This does not include fundamental controls like buttons, fixed texts, and such - they're part of the VCL layer, and we're not interested in them here. Also, this does not include low-level UI helpers as the SvTreeListBox and BrowseBox - at least not in the first run.

The reasons for this are various, one bold-printed line in the list of these reasons titled "History" ....
Several drawbacks of the current situation become obvious (most of them having a "performance issue" label on their back).

• Maintaining this primeval forest becomes more and more difficult as it grows.

• The startup behaviour of the office suffers: Just because later on, there may be a need for, say the character formatting tab page, the library containing this page is loaded at the moment the writer is started

• An application does not have a chance to deny loading of unused code: Opening the Tools/Options dialog means loading a lot of code for some pages present there - though they're not needed

Note 2: To prevent this question from arising: We're not talking about actually creating tab pages which are not needed. There already are good mechanisms which ensure that there is no page for the Load/Save options created if you do not open the Options dialog on exactly this page. But the code for this page is loaded into memory - as well as the code for, say, position and size of a shape of the drawing layer, and on some platforms also the code for the UNO representation of some drawing layer components, just because they're all in one lib -- Did I already mention that it's weird?

Note 3: Of course, there are a lot of options pages which are application specific and not implemented in the CUI, but in the application itself. But splitting the applications into a core and a UI part is a completely different story.

The Goals

We want to have:

• a clear structure in the high-level components which are necessary for a common office UI

• libraries specific to the CUI

• a more intelligent grouping of code, thus decreasing the overhead of loading unnecessary code.

• the possibility to load shared code on demand, thus improving startup performance

The Way

Well, the following is not really a comprehensive description of "The Way". It is an introduction to what we think could be steps on the way to reach the goals. It is neither complete nor finished, it's just a rough outline at the moment.

There is some stuff which won't be moved in a first run. This includes:

• The OfficeApplication class. This global application class should stay in OFFMGR - it handles common application-wide tasks, and it is needed as soon as a doc is opened, anyway.

• Image Lists. Currently, such lists for CUI purpose are found in OFFMGR (and SFX2?). Load-on-demand seems to be unnecessary for them (they would be loaded as soon as the first document is opened, which is

• small MessageBoxes: moving them seems to be oversized

• SFX-Toolboxes (such as the common Office-Toolbar): as above

• Print Dialog / Document Info Dialog: They're integrated with the current SFX framework (callbacks into SfxModules and such), and thus should not be moved at the moment - this can change in the future

Toolbox Controllers

If a application wants to bind a given ToolboxController to a slot id, it calls some kind of (static) RegisterXYZ method. There are different shades of this (sometimes the slot id is passed, sometimes it's hard coded, some controllers need a module pointer passed, etc.), but the main idea is always the same.

So, for outsourcing the controllers to CUI, we need to broaden the interfaces so they cover all possibilities, which mainly means that there needs to be a static RegisterXYZ function for every controller.

Tab Pages

Looking at the various commonly used tab pages we currently have, we can discern at least 3 groups:

1. pages used for the drawing layer

2. pages for common options

3. other dialogs

It seems reasonable to reflect these groups in different libraries. Users who do not use drawing functionality during a session won't load a). Users who have already adjusted their office to their very personal preferences will never load b) in all subsequent sessions.

Because of the factory concept, we can change this grouping later (if we see the demand) without changes in the applications.

Floating Tools

There are some common tools which appear in a floating window, and are (potentially) needed as soon as a document is opened. This includes the Stylist, the Navigator, and the Find & Replace dialog. Thus, it would make sense to have these tools in a common library.

Factories

A main requirement is to load code, only on demand. This means we need factories to create all the components we want to provide.

Note 4: It surely is oversized to use UNO mechanisms for this (though UNO already features an abstract factory concept), as this would mean that our components would need to be wrapped in UNO.

Looking at what kind of interfaces, applications typically use, we have the following:

• factories: For tab pages, a Create method is passed when referring to a page class, which means we need a factory which creates such factory functions.

• direct instantiation: For dialogs, the applications need immediate access to an instance of a class, thus we need to provide simply factories

• static init functions: For toolboxes, as mentioned above, an application needs to know (and call) a static RegisterXYZ function only.

In ideal, applications would link only against a library containing all the factory methods, and create all needed components indirectly using these factories. We then can even hide the more detailed library structure: Whether a given tab page (created by a factory) is located in library X or library Y is of no interest to the application. This placement in libs can even be changed without any notice - the application still only calls the factory, and the factory decides which other lib to load to create the component.

Of course, we still need to expose the interfaces of the classes created by the factories, which in C++ means the class declaration has to be exported, and the methods have to be kept virtual (as calling non-virtual method requires linking against the implementation lib.)

Proposed Libraries

Suggestion for libraries to introduce in CUI (in the following, dialogs is an alias for "dialogs, tab pages, and such" :)

1. drawing layer dialogs

2. option dialogs

3. other dialogs

4. floating tools (Stylist, Navigator, Find dialog)

5. FileDialogHelper, File-Open dialog, Document'n'Templates dialog, Help-UI

6. Toolbox controllers, base classes, factories

e) and f) would be libraries to link against (because they contain components which a normal application needs, very often this does not matter).
d) would be a lib containing tools which are needed often, but not always, and would be loaded on demand.
a) and c) are loaded on demand only

Perhaps e) can be split up even more, moving the pure UNO components (which counts for the file dialog, nearly for the Help-UI, and potentially for the DocTempl dialog) into separate libs.