1/************************************************************** 2 * 3 * Licensed to the Apache Software Foundation (ASF) under one 4 * or more contributor license agreements. See the NOTICE file 5 * distributed with this work for additional information 6 * regarding copyright ownership. The ASF licenses this file 7 * to you under the Apache License, Version 2.0 (the 8 * "License"); you may not use this file except in compliance 9 * with the License. You may obtain a copy of the License at 10 * 11 * http://www.apache.org/licenses/LICENSE-2.0 12 * 13 * Unless required by applicable law or agreed to in writing, 14 * software distributed under the License is distributed on an 15 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 16 * KIND, either express or implied. See the License for the 17 * specific language governing permissions and limitations 18 * under the License. 19 * 20 *************************************************************/ 21 22 23 24#ifndef __com_sun_star_drawing_framework_XConfigurationController_idl__ 25#define __com_sun_star_drawing_framework_XConfigurationController_idl__ 26 27#ifndef __com_sun_star_drawing_framework_ConfigurationChangeEvent_idl__ 28#include <com/sun/star/drawing/framework/ConfigurationChangeEvent.idl> 29#endif 30#ifndef __com_sun_star_drawing_framework_XConfigurationControllerBroadcaster_idl__ 31#include <com/sun/star/drawing/framework/XConfigurationControllerBroadcaster.idl> 32#endif 33#ifndef __com_sun_star_drawing_framework_XConfigurationControllerRequestQueue_idl__ 34#include <com/sun/star/drawing/framework/XConfigurationControllerRequestQueue.idl> 35#endif 36#ifndef __com_sun_star_drawing_framework_XResourceFactoryManager_idl__ 37#include <com/sun/star/drawing/framework/XResourceFactoryManager.idl> 38#endif 39#ifndef __com_sun_star_drawing_framework_ResourceActivationMode_idl__ 40#include <com/sun/star/drawing/framework/ResourceActivationMode.idl> 41#endif 42 43module com { module sun { module star { module drawing { module framework { 44 45published interface XConfigurationChangeListener; 46published interface XConfigurationChangeRequest; 47published interface XResourceId; 48published interface XResource; 49 50/** The configuration controller is responsible for the management of the 51 set of active resources. 52 53 <p>There are two configurations of resources:<ul> 54 <li>The current configuration contains the set of currently active 55 resources.</li> 56 <li>The requested configuration describes what the current configuration 57 should be. The requested configuration is changed usually by calling 58 <member>requestResourceActivation()</member> and 59 <member>requestResourceDeactivation()</member>.</li> 60 </ul></p> 61 62 <p>When the two configurations differ then the current configuration is 63 updated eventually to reflect the requested configuration. An update 64 takes place when the following three conditions are fulfilled. 65 <ol> 66 <li>when the last pending request for configuration changes has been 67 processed,</li> 68 <li>when the <member>update()</member> method is called.</li> 69 <li>when the configuration manager it is unlocked after formerly being 70 locked.</li> 71 </ol></p> 72 73 <p>Requests for configuration changes are handled in a two step process: 74 <ol> 75 <li>First the requested configuration is updated iteratively: Every 76 request that is being made by calling 77 <member>requestResourceActivation()</member> or 78 <member>requestResourceDeactivation()</member> results in one or more 79 function objects, that each implement the 80 <type>XConfigurationChangeRequest</type> interface. These are inserted 81 into a queue. The request objects in the queue are processed 82 asynchronously one at a time in the order in which they are inserted. 83 Only when one request object is processed a change to the requested 84 configuration is made. These changes are broadcasted to registered 85 <type>XConfigurationChangeListener</type> objects. Listeners may 86 decide to make requests that then are added to the queue. For example 87 when the view in the center pane is replaced by another view, some 88 listeners may want to turn some side panes on or off, or show other 89 views in the side panes.</p> 90 <p>This process goes on until the queue of request objects becomes 91 empty. Until this point only the requested configuration has been 92 modified. No resources have been activated or deactivated.</p></li> 93 94 <li><p>The second update step activates or deactivates resources so that 95 the current configuration (the one that comprises the actually active 96 resources) reflects the requested configuration.</p> 97 <p>The order in which resources are activated or deactivated depends on 98 the dependency between the resources. For example a view depends on the 99 pane it is displayed in. Resources that other resources depend on are 100 activated first and deactivated last. The order is undefined for 101 unrelated resources.</p> 102 <p>Note that the second update step may not be able to activate (or even to 103 deactivate) all the requested resources. Either because they are 104 temporarily or permanently unavailable. For example, during the 105 start-up of a new Impress application the side panes are displayed 106 with a visible delay because they are not provided sooner by the 107 underlying framework. Such anavailable resources are not forgotten but 108 remain in the requested configuration. Every time the configuration 109 controller updates its current configuration these resources are 110 requested once more.</li></ol></p> 111 112 <p>The configuration controller sends the following events: 113 <ul> 114 <li><const>ResourceActivationRequested</const> is sent when the 115 activation of a resource has been requested and the resource is not yet 116 active in the requested configuration. The event is sent when the 117 configuration change request is executed, not when the 118 <member>requestResourceActivation()</member> call is made.</p> 119 <p>The <member scope="ConfigurationChangeEvent">ResourceId</member> member is set to the requested 120 resource. The <member>ResourceObject</member> member is not 121 set.</p></li> 122 <li><const>ResourceDeactivationRequested</const> is sent when the 123 deactivation of a resource has been requested and the resource is active 124 in the requested configuration. The event is sent when the 125 configuration change request is executed that is created when for 126 example <member>requestResourceDeactivation()</member> is called.</p> 127 <p>The <member>ResourceId</member> member is set to the requested 128 resource. The <member>ResourceObject</member> member is not 129 set.</p></li> 130 <li><const>ConfigurationUpdateStart</const> is sent before the update of 131 the current configuration starts.</p> 132 <p>The requested configuration is available in the <member 133 scope="ConfigurationChangeEvent">Configuration</member> member. The 134 <member>ResourceId</member> and <member>ResourceObject</member> members 135 are not set.</p></li> 136 <li><const>ConfigurationUpdateEnd</const> is sent after the update of 137 the current configuration ends.</p> 138 <p>The requested configuration is 139 available in the <member scope="ConfigurationChangeEvent" 140 >Configuration</member> member. The <member>ResourceId</member> and 141 <member>ResourceObject</member> members are not set.</p></li> 142 <li><const>ResourceActivation</const> is sent when a resource is 143 activated, i.e. when a new object of a resource is created (or taken 144 from a cash).</p> 145 <p>The <member>ResourceId</member> and <member>ResourceObject</member> 146 members are set to the <type>XResourceId</type> and object reference of 147 the activated resource.</p></li> 148 <li><const>ResourceDeactivation</const> is sent when a resource is 149 deactivated, i.e. when an object that previously was part of the 150 configuration is removed from the configuration.</p> 151 <p>The <member>ResourceId</member> and <member>ResourceObject</member> 152 members are set to <type>XResourceId</type> and object reference of the 153 deactivated resource.</p></li> 154 </ul></p> 155*/ 156published interface XConfigurationController 157{ 158 interface XConfigurationControllerRequestQueue; 159 interface XConfigurationControllerBroadcaster; 160 interface XResourceFactoryManager; 161 162 /** Request the activation of a resource. 163 <p>The request is processed asynchronously. Notifications about 164 configuration changes are sent after this call returns.</p> 165 @param xResourceId 166 The resource whose activation is requested. 167 @param eMode 168 <p>When eMode is <const>REPLACE</const> then, before adding the 169 resource activation to the request queue, similar resources 170 linked to the same anchor are removed. This makes it easer to 171 switch between resources whose activation is mutually exclusive. 172 For example, there can only be one view per pane, so before 173 activating a new view the old one has to be deactivated.</p> 174 <p>When eMode is <const>ADD</const> then the resource is requested 175 without further changes.</p> 176 */ 177 void requestResourceActivation ( 178 [in] XResourceId xResourceId, 179 [in] ResourceActivationMode eMode); 180 181 /** Request the deactivation of a resource. 182 <p>The request is processed asynchronously. Notifications about 183 configuration changes are sent after this call returns.</p> 184 <p>Requesting the deactivation 185 of a resource that is not active is not an error.</p> 186 @param xResourceId 187 The resource whose deactivation is requested. 188 */ 189 void requestResourceDeactivation ( 190 [in] XResourceId xResourceId); 191 192 193 /** Return the active resource specified by the given resource id. 194 @param xResourceId 195 A valid resource id. This should, but does not have to be, the 196 resource id of an active resource. 197 @return 198 When the given resource id specifies an active resource then 199 that resource is returned. Otherwise an empty reference is 200 returned. 201 */ 202 XResource getResource ( 203 [in] XResourceId xResourceId); 204 205 /** Lock the processing of configuration change requests. 206 <p>This is only necessary when more than one change request is being 207 made in a row. It prevents an update being made (with all the visible UI 208 changes) before all change requests are being made.</p> 209 <p>Recursive <member>lock()</member> calls are recognized: the 210 configuration controller is locked while <member>lock()</member> was 211 called more often than <member>unlock()</member>.</p> 212 */ 213 void lock (); 214 215 /** Unlock the processing of configuration change requests. 216 <p>When <member>unlock()</member> is called as many times as 217 <member>lock()</member> and the queue of configuration change 218 requests is not empty the configuration controller continues the 219 processing of the change requests. An update of the current 220 configuration will eventually being made.</p> 221 */ 222 void unlock (); 223 224 /** Explicitly request an update of the current configuration. 225 <p>Call it when a resource is activated or deactivated 226 without the control and knowledge of the drawing framework. Calling 227 this method (from outside the drawing framework) should hardly every 228 be necessary.</p> 229 */ 230 void update (); 231 232 /** Return a copy of the requested configuration. 233 <p>Modifications to the returned configuration have no effect on the 234 drawing framework.</p> 235 */ 236 XConfiguration getRequestedConfiguration (); 237 238 /** Return a copy of the current configuration. 239 <p>Modifications to the returned configuration have no effect on the 240 drawing framework.</p> 241 */ 242 XConfiguration getCurrentConfiguration (); 243 244 /** Replace the requested configuration with the given configuration and 245 schedule an update of the current configuration. 246 <p>Together with the <member>getCurrentConfiguration()</member> and 247 <member>getRequestedConfiguration()</member> methods this 248 allows the saving and restoring of configurations. However, the 249 given configuration can have other origins then these methods.</p> 250 <p>The given configuration is transformed into a list of of change 251 requests so that the resulting reqeusted configuration equals the 252 given configuration. This has the advantage that not only the 253 resource activations and deactivations but all configuration 254 changes are properly broadcasted.</p> 255 <p>Note that because of the configuration change notifications 256 listeners can make more configuratio change requests, so that the 257 resulting requested configuration can be different from the given 258 configuration.</p> 259 @param xConfiguration 260 This typically is a configuration that was obtained with an 261 earlier <member>getRequestedConfiguration()</member> call. 262 */ 263 void restoreConfiguration ([in] XConfiguration xConfiguration); 264}; 265 266}; }; }; }; }; // ::com::sun::star::drawing::framework 267 268#endif 269