Hi Carsten,
1)For com.sun.star.ui.XUIConfigurationStorage,
we have to connect a storage when reloading/storing ui configuration,
so setStorage(...)/hasStorage of XUIConfigurationStorage are used on
this purpose. Right?
Yes.
According to this, we have to specify the storage, where the
accelerators are loaded/stored from/to, for the document accelerator
configuration. The setStorage(...)/hasStorage have also been
implemented for this situation.
But for global or module depending accelerator configuration, where
the accelerators are now loaded/stored from/to XCU, it seems that it
isn't necessary to set the storage for global/module accelerator
configuration. If we want to store their accelerators to a storage, we
can use the XUIConfigurationPersistence.storeToStorage().
Similarly, the ImageManager and UIConfigurationManager have
implemented the interface XUIConfigurationStorage, while
ModuleImageManager and ModuleUIConfigurationManager doesn't inherit it.
Yes, that's the problem. ModuleImageManager and
ModuleUIConfigurationManager don't provide this interface whereas the
accelerator configuration does. Therefore we currently don't use the
same easy solution with two different implementations for accelerators.
From my point of view it's not good to define that some methods of an
interface are not implemented. This will surprise and confuse
developers. I think we should discuss this in more detail in our IRC
meeting on Wednesday.
OK. XUIConfiguration will also be discussed later.
2)For com.sun.star.ui.XUIConfigurationPersistence,
All the 3 types of Global/module/document accelerator configuration
have to implement the XUIConfigurationPersistence. We can use the
original AcceleratorCache and AcceleratorXMLWriter to store the
accelerators to a specified storage, and I have done it in my local code.
And what's your opinions?
Yes, I think this is a good idea.
3) For com.sun.star.ui.XUIConfiguration,
It is used to add/remove configuration listener to a container. The
listeners will be notified when ui configuraiton are
changed(e.g.:replace,insert,remove an element). Right?
The same function should have already been implemented for both the xml
and xcu based accelerator configuration. The xml accelerator
configuration provides and implements an C++ interface
IStorageListener,which contains one method changesOccurred(). And
similarly css::util::XChangesListener has been provided and implemented
for the new accelerator configuration.
Currently all the listeners of accelerator configuration could be
notified when the underlying configuration is changed.
So I think global and module accelerator configuration should provide
and implement interface XUIConfigurationPersistence. Document
accelerator configuraiton should provide and implement
XUIConfigurationStorage and XUIConfigurationPersistence.
Regards,
Yan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
For additional commands, e-mail: dev-h...@framework.openoffice.org
