[Libreoffice-commits] core.git: New saving behavior

[Stephan Bergmann]

On 12/23/2015 10:38 AM, Maxim Monastirsky wrote:
> commit 22328a224df4619218b88205838307f70612207e
> Author: Maxim Monastirsky <momonasmon at gmail.com>
> Date:   Tue Dec 22 13:12:23 2015 +0200
>
>      New saving behavior
>
>      Changes in this commit:
>
>      - AlwaysAllowSave config is gone. Saving is always permitted, unless in
>        a read only document. Also changed the behavior in dbaccess to match
>        sfx2.
>
>      - The toolbar save button is always enabled, to always give access to
>        the dropdown. That's the case even in a read only document, except
>        that it changes to DROPDOWNONLY, and the save as command icon+tooltip.
>        In table/query designers we still disable the button in read only state.
>
>      - When the document is modified, the toolbar button gets a special icon
>        to indicate that.
>
>      TODO:
>
>      - Icons for the document modified state are still missing. I added some
>        fake links to Tango's links.txt in order to test the new behavior.
>        These links shouldn't stay as-is in a production version!
>
>      Change-Id: I56c169bf48b78faaf53c2989ce8624f8297ffb6e
>      Reviewed-on: https://gerrit.libreoffice.org/20839
>      Reviewed-by: Maxim Monastirsky <momonasmon at gmail.com>
>      Tested-by: Maxim Monastirsky <momonasmon at gmail.com>
[...]
> diff --git a/officecfg/registry/schema/org/openoffice/Office/Common.xcs b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
> index b8d9828..1655acb 100644
> --- a/officecfg/registry/schema/org/openoffice/Office/Common.xcs
> +++ b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
> @@ -5606,13 +5606,6 @@
>           </info>
>           <value>false</value>
>         </prop>
> -      <prop oor:name="AlwaysAllowSave" oor:type="xs:boolean" oor:nillable="false">
> -        <info>
> -          <desc>Determines if the user can save the document even when it's not
> -          modified.</desc>
> -        </info>
> -        <value>false</value>
> -      </prop>
>         <prop oor:name="ExperimentalMode" oor:type="xs:boolean" oor:nillable="false">
>           <info>
>             <desc>Determines if various experimental, and potentially unstable
[...]

Just a reminder that removing a configuration property is incompatible, 
and comes at a cost:

* Settings for the property in .xcu files (a UserInstallion's 
registrymodifications.xcu, or .xcu files included in LO extensions) will 
silently be ignored (emitting a SAL_WARN in debug builds).

* But client code accessing the configuration via the UNO API will 
trigger exceptions when accessing that property (e.g., 
css.beans.UnknownPropertyException upon calling 
css.beans.XPropertySet.get/setPropertyValue).

It should always be weighed whether keeping the property (even if 
dysfunctional) or removing it is the better choice overall.  And if it 
is removed, that should be mentioned in the release notes.