Chart2 Single-Click Concept
Currently, users have to do a double-click to activate a chart object embedded in a container document. After the double click, a following single-click selects the object below the mouse cursor. As this is quite complicated and not expected by users, the new chart should be able to do the activation and selection of an object in one step.
This is a proposal for solving this issue.
Currently, we favor a mechanism that does the following:
- When a Calc document is loaded, for all charts that have a certain flag the model should be loaded, but no view should be created unless there is no replacement-image available. See below (#Loading Charts that use Calc Data Early enough) for a more detailed information about this.
- So, a chart usually shows its replacement image. When a user clicks on the chart object with a single click, the container application must activate the chart (State UI_ACTIVE), convert the current mouse cursor position to local coordinates of the embedded object and pass them via an (to-be-defined) interface. Then the chart shows the same behaviour like when a single click is done at this position while being UI-active.
- We have to find out if a double-click in the chart is also available with this mechanism. (I.e., a user double-clicks, which does the same as a double-click in an activated chart, which is, opens the properties dialog of the selected object).
- Disadvantages: With this mechanism, the quick help texts that are shown when hovering with the mouse over chart objects will not be available until the chart is activated. That is, a user must at least have clicked once into the chart for activation to have the quick help available.
- Advantages: As the replacement images are still used (when available), scrolling through a document containing charts is much faster as no views have to be created until the chart is activated (by a single-click).
Loading Charts that use Calc Data Early enough
Charts that take their data from a container Calc or Writer document, should be loaded directly after the container document was loaded, so that they can attach as XModifyListener at the data ranges they get for data ot be able to update changed ranges in the model or trigger the view to repaint when values have changed (apparently by setting themselves to modified which results in a refresh of the replacement image).
Things to take into account with this mechanism:
- Loading of the XModel of the charts should be fast enough to avoid a performance issue with this change.
- Charts that do not have to be loaded immediately, because they have their own data should not be loaded immediately. We should find some flag that a chart can have to tell the container whether it should be loaded immediately or later.
- There exists the xlink:actuate attribute in the draw:object element that contains the chart in a Calc document. Values can be "onLoad" or "onRequest". This fits our needs: a chart with own data would have this value set to "onRequest", while a chart with data from Calc, that needs to be loaded immediately would have this value set to "onLoad" (see Behaviour of Links in xlink). However, as in the files all charts have the attribute with value "onLoad", but are not always loaded, this seems not to be implemented correctly.
- There is an OLE-cache that swaps out the model of OLE objects if too many of them are currently loaded. This mechanism must not be enabled for charts that need to have a running model to get notified about changes of the underlying data. There exists a mechanism to set an OLE-object to the "always_running" state which tells the OLE-cache not to remove those objects. This flag could also be used for the information whether to load an object immeditely mentioned before.
Alternative: The mechanism that today is at work. The Calc document contains the attribute
draw:notify-on-update-of-ranges which contains the "range" of data used by the chart. So whenever data or range-references in this given region changes, the chart is loaded and updated. With our new, more flexible mechanism of assigning data ranges to specific chart objects, this will no longer work reliably, as this would have to be a collection of ranges from all chart objects.
Disadvantages of the alternative: One thing is the already mentioned single range string containing all ranges used by the chart, which might become quite a complex, long string then. The other disadvantage is that with this mechanism the Calc document needs to have knowledge about internals of the chart, which is always a bad idea, especially as the data exists at two places and has to be synchronized correctly.