Drawing framework
Contents
Introduction
The drawing framework is a framework employed by the Impress and Draw applications for the synchronized activation and deactivation of resources. It design addresses the following goals
- ease of use
- flexibility
- extensibility
- abstraction from underlying frameworks
The drawing framework can be seen as a resource management system, where the resources are panes, views, tool bars, commands (slots). Different types of resources are managed by individual resource controllers. The resource controllers are synchronized by the configuration controller. Its name comes from the configuration, which describes the set of active resources, i.e. the set of visible panes, views, and tooll bars. Synchronization means that activation or deactivation of resources of different types are made in a fashion that minimizes the overall time and reduces visual artifacts, i.e. flickering. The drawing framework is implemented on top of and abstracts from existing framework functionality provides mostly by the SFX2 and Framework projects.
Current State
The drawing framework is implemented in child work space components1 for panes and views. Tool bars and commands will be integrated soon.
Framework Design
The task of the drawing framework is to negotiate between resource providers on one side and the application that wants to show or hide a resource on the other side. The negotiation process is iterative: the activation of one resource may cause the activation request of other resources. For example, when the user switches the view in the center pane to the outline view, then the task pane is deactivated.
Two phase updates
The negation process is split into two phases, one for the actual negotiation of the requested changes and the other for updating the GUI to reflect these changes.
This is supported by the use of two configurations, the current configuration and the requested configuration. The current configuration contains the currently active resources while the requested configuration contains the resources which are requested to be active.
The actual negotiation phase is triggered by the initial request, for example the switch of the view in the center pane. In this phase only the the requested configuration is modified. The requested change is stored in the requested configurtion and then is broadcasted. Listeners may react by making further requests for the activation or deactivation of other resources. These are again broadcasted and may lead to even more requests. All requests are put into a queue which is processed until there are no more pending requests.
When all requests have been processed and the the requested configuration describes a new consistent state of the GUI then the second, the update phase is started. In this phase only the current configuration is modified.
That is, the requested configuration is not modified directly in this phase. The application can of course request the activation or deactivation of resources. Therefore, in the update phase a copy of the requested configuration is used which remains unchanged during the update.
The different resource controllers are asked to activate or deactivate resources so that eventually the current configuration looks like the requested configuration. Every activation and deactivation is broadcasted like the requests for the activations and deactivations where.
It is the task of the configuration controller to optimize the the update phase with respect to time and visual artifacts, flickering. It does that by acquiring the relevant locks and by calling the resource controllers in the right order.
Three layer design
The drawing framework is made up by a couple of controllers (not of the com::sun::star::frame::XController variety), factories, and modules that are located on three layers. The assignment to one of the layers depends on the knowledge about different aspects of the resource management:
- The application layer controls when to activate or deactivate a resource
- The synchronization layer uses the configuration controller to synchronize the requests from the application layer. It has no detailed knowledge about individual resources but controls the big picture.
- The factories in the resource layer know how to activate or deactivate resources.
