office-gobmx/configmgr
Justin Luth 87a8b2c0d1 GenericCommands: fix Fontwork tooltips
These were terribly confusing.

.uno:Fontwork does NOT insert fontwork text, despite the tooltip name.
It opens up the old fontwork dialog that modifies contour properties
so that the text can flow along the contour.
The UIname is Fontwork, so lets have an automatic tooltip for that.

.uno:FontworkGalleryFloater has a UIname of "Fontwork Style",
but the auto-generated tooltip was "Fontwork". (Notice that this
conflicts with the UIname of the other one. So when you add "Fontwork"
to your toolbar, and chose the icon with the tooltip "Fontwork" you
get a different item.) Since this one actually inserts text, and
doesn't actually modify any existing style (that's the function of
Fontwork Shape), lets give this one the tooltip "Insert Fontwork Text".

Therefore, this patch effectively switches the two tooltip names around,
which much better matches their function, and their UIname.
I expect that this was the original 2016 intention anyway...

At the end, I decided to also change the UIname to "Insert Fontwork",
since the gallery is normally added to insert menus...
The unit test I had to modify just looked like a functionality test
and had nothing to do specifically with the label's string.
(It was last changed for tdf#91781 which made no specific
reference to fontwork.)

This might help documentation bug tdf#118336 a bit too.

Change-Id: I152596781def2d8dba47f53e345976543e3131bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88101
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Tested-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-02-06 23:11:39 +01:00
..
inc/pch make update_pch also consider files in <module>/src/**/inc 2020-02-01 20:12:21 +01:00
qa GenericCommands: fix Fontwork tooltips 2020-02-06 23:11:39 +01:00
source std::set<T*> -> o3tl::sorted_vector 2020-02-04 10:09:04 +01:00
CppunitTest_configmgr_unit.mk loplugin:logexceptionnicely in configmgr..connectivity 2019-06-14 11:05:59 +02:00
IwyuFilter_configmgr.yaml tdf#42949 Fix IWYU warnings in configmgr/* 2019-07-17 13:58:57 +02:00
JunitTest_configmgr_unoapi.mk Simplify and fix Java UNO API test makefiles 2018-11-09 07:37:00 +01:00
Library_configmgr.mk do not require $(SRCDIR) in every gb_Library_set_precompiled_header 2019-09-23 10:47:25 +02:00
Makefile switch to include-based build rather than sourced-based build 2012-02-05 19:34:05 -06:00
Module_configmgr.mk tdf#46723 - enable configmgr unit tests 2015-02-11 10:00:32 +01:00
README an uno -> a uno 2019-05-10 14:50:59 +02:00

UNO services to access the configuration database

== Functional Overview ==

This code parses the settings that are described in the [[officecfg]]
directory, and provides a UNO API that code can use to set and get
settings.

== Source Overview ==

configurationprovider.cxx
configurationregistry.cxx
defaultprovider.cxx
services.cxx
 UNO service implementations.

access.cxx
childaccess.cxx
rootaccess.cxx
 UNO objects passed to clients.

components.cxx
 Central singleton that aggregates all data (reads in the XML files, manages
 modifications and global notifications).

groupnode.cxx
localizedpropertynode.cxx
localizedvaluenode.cxx
node.cxx
propertynode.cxx
setnode.cxx
 Internal representations of data nodes.

parsemanager.cxx
parser.hxx
valueparser.cxx
xcdparser.cxx
xcsparser.cxx
xcuparser.cxx
xmldata.cxx
 XML file reading.

modifications.cxx
writemodfile.cxx
 Modification management.

broadcaster.cxx
 Notification management.

additions.hxx
update.cxx
 Extension manager interface.

data.cxx
lock.cxx
nodemap.cxx
partial.cxx
path.hxx
type.cxx
 Utilities.


== Some Implementation Notes ==

=== Mandatory Set Members ===

- A set member can be marked as "mandatory," meaning that a member of that name
must always be present in a set.

- The above definition implies that calling replaceByName on a mandatory set
member is OK.

- The XCU format can contain oor:mandatory attributes on nodes.  (The XCS format
does not support them.  In the registrymodifications file, oor:mandatory
attributes should never be needed, as being mandatory cannot be controlled via
the UNO API.)  The XCU reading code only evaluates the oor:mandatory attribute
for set members, and ignores it everywhere else.

- Only true sets support mandatory members.  A localized property for the "*"
locale, though acting much like a set, does not support mandatory members.

- The OpenOffice.org Registry Format document claims that group extension
properties are implicitly mandatory, but at least the new configmgr code does
not treat them like that (i.e., they can be removed again).

- For simplicity, setMandatory/getMandatory are available as virtual functions
at the base Node, even though they can only make sense for GroupNodes and
SetNodes that are set members.  The default getMandatory implementation returns
NO_LAYER, meaning oor:mandatory is not set to true in any layer.  (Returning
NO_LAYER simplifies the code, e.g., removeByName does not have to check whether
getMandatory is called on a member of a true set to decide whether to forbid
removal.)

- When committing changes (made through the UNO API), the "mandatory" status of
inserted nodes must be updated (in case the insert is due to a replaceByName, or
the "mandatory" flag was added by a concurrent modification of a lower layer).
Also, for to-be-removed nodes, removal is ignored for (newly; due to concurrent
modification of a lower layer) mandatory nodes (but still recorded in
registrymodifications, so may take effect once the lower layer addition is
removed again---whether or not that is a good idea).


=== XcuParser Modification Recording ===

- XcuParser records modifications when reading user layer data
(valueParser_.getLayer() == Data::NO_LAYER).

- oor:finalized and oor:mandatory attributes cannot be set via the UNO API, so
it is assumed that user layer data does not contain them (for one, they are not
written by writeModFile; for another, the logic to record modifications expects
a locprop(modify,fuse) to be followed by one or more value(fuse,remove), which
would not necessarily be true if the locprop were only present in the user layer
data to flag it as finalized).

- The logic to record modifications considers the top of the XML element stack.
In the following list of all possible cases, items marked with an asterisk are
recorded:
 ... group(modify,fuse) - group(modify,fuse) - ...
 ... group(modify,fuse) - set(modify,fuse) - ...
 ... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse)
 ... group(modify,fuse) - *prop(remove)
 ... group(modify,fuse) - locprop(modify,fuse) - *value(fuse)
 ... group(modify,fuse) - locprop(modify,fuse) - *value(remove)
 ... group(modify,fuse) - *locprop(replace) ...
 ... set(modify,fuse,replace) - group(modify/fuse) - ...
 ... set(modify,fuse,replace) - *group(replace/fuse) - ...
 ... set(modify,fuse,replace) - *group(remove)
 ... set(modify,fuse,replace) - set(modify/fuse) - ...
 ... set(modify,fuse,replace) - *set(replace/fuse) - ...
 ... set(modify,fuse,replace) - *set(remove)
Legend: "...": zero or more further items
        "- ...": one or more further items
        "modify,fuse" etc.: any of those operations
        "modify/fuse": a modify or a fuse on an existing member
        "replace/fuse": a replace or a fuse on a non-existing member