Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


On 12/23/2015 10:38 AM, Maxim Monastirsky wrote:
commit 22328a224df4619218b88205838307f70612207e
Author: Maxim Monastirsky <momonasmon@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@gmail.com>
     Tested-by: Maxim Monastirsky <momonasmon@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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.