...at least while MenuWindow is mostly a TODO still;
and ImplHanldeHelpEvent can be protected

Change-Id: Ice0bb37e7e774e51445a9d78b2cf5eaba12f6341

...as https-equivalent to complement vnd.sun.star.webdav scheme.  See the mail
thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2015-August/069929.html>
"What autogen.sh for an alternative ContentProvider for dav:// scheme?" for why
it is considered beneficial to have the WebDAV UCP support---in addition to the
standard pair of http[s] schemes---a non-standard pair of
vnd.sun.star.webdav[s] schemes different from the "accidentally supported"
non-standard pair of dav[s].

Change-Id: I7032aa1ed599f735969cf0163cd9dc121a1fdcb3

cf. 9228f412 "Missing davs URL scheme handling"

Change-Id: Ia161691cc213b5b2c1a3a589ce05b6ad8558013c

...looks like it was just forgotten in e557f06c
"INTEGRATION: CWS tkr10: i84676 neon and gnome-vfs2"?

Change-Id: I1bae95273f43e58425181bbc4667f87a6389e3a9

Change-Id: Id4419b6b902b742117e248870b6a663c9c58955f

Change-Id: Id2ee43ff95b6d28252f58e4930b81faf8b3b4b7f

Change-Id: I262a9e75ec20fad15b550b84989fd7acc118c53a

Change-Id: I8ccaf0e8eea9c47257561e66114972bebf16e3af

Change-Id: I0d67b6c155d44e9c9072ef7c3519850c45a51313

Change-Id: I000a8fbfec9c81a61773b5db24b5a7b6c708dc06

with the variadic variants.

Change-Id: Id8d0c61b0454652abbbd09be0c72696a057dc2d2
Reviewed-on: https://gerrit.libreoffice.org/18008Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Ie36f46e2eae72e8838aa5e45f96bd02fef45f7d5

Change-Id: I9abe56c88171629b68d72119f1359d750675d08a

Change-Id: I83634fa276048607cc0572178964417ce7373e0c

Change-Id: I50e07779a541bbea6b285a855fb54d419d4aed13

(which is a single-instance service, so there is likely no benefit in
initializing it lazily anyway)

Change-Id: Ie7e8272f11372149391a1190d5e71137dddaa03b
Reviewed-on: https://gerrit.libreoffice.org/18016Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I5ab147c8b737396db6371b9d92e7f19955ed7f28

Change-Id: I16d5772b0f8455518866cb03729e9bab95be8087

Change-Id: I983a24964f71967f1c0fdbde6dde0524d8c3456c

Change-Id: Ib3dacf63db01649992c7fe7571b54f964202fc3b

Change-Id: I5be4cfb951100d36054e409043cb9becbe52338d

Change-Id: Ibeace7ce7621033cf04e3186c212bbb4a27492a1

Change-Id: Iaab5763d4fbde431bac6f7ecbf4527ad889b6891

Change-Id: I0244f12f1ee2e61ac577222a14b011aee5ddbd54

Change-Id: I2801f54cecf9c8b7d43f8e1c1699cfd7fdd918e3

Change-Id: I5fca36f79aa98606770c77dad5b757288bd47842

Change-Id: I63e2f5055a87593708f672341b5849554b4db6fb

Change-Id: I5350322e5c957127fe125e633b31b2492410995e

Change-Id: If1b2bfe308caa2bce92e73d2c5c86ee273faed93

Change-Id: I4c4294b7fb1cb537ba3ae3e6e7e747a3333b7469

Clang (at least the one from newest Xcode 7 Beta) warn both that
fResult "is used uninitialized whenever 'if' condition is false" *and*
that the very same "condition is always true".

Change-Id: I9e2424e7323046edbfe1af3c9f960df49e0809dd

Change-Id: I1b05edc954125e5bdeed05b5fdce1430f8eaba26

Change-Id: I0e3d6f00a79bc33e1db1329df217e7e867dfd511

Change-Id: I4c06290f09e5bfecd2c1de896e19cb5036a3a0e9

Change-Id: I1ba5583d9121b541b6b76588f1334980abe3836e

Change-Id: I45cb0e62278d8c3154ae8ad54ca4c93b3e177969
Reviewed-on: https://gerrit.libreoffice.org/18030Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: I69f45dd2d7426ecd99dca7e80e98e95c3e52d4a0

Since the gradient frame backgrounds were added in LO 4.1, we export
this:

 fo:background-color="transparent" draw:fill="solid"

Which doesn't make a whole lot of sense as this is really a "none" fill,
and now with the backward compatibility stuff in the style import code
we get the pool default color added when setting the BackTransparent
property, and with the draw:fill="solid" it becomes visible and the
background color is now Sky Blue 1.

So try to detect draw:fill="solid" without draw:fill-color attribute
and contradicting transparent legacy attribute and nerf it.  This way
we also export draw:fill="none" again, although still with a bogus
draw:fill-color but that shouldn't cause any harm.

Change-Id: I1c2bea46ba7d9a3f042b875df0ca12c7f6037909

... frame/paragraph backgrounds.

If a style is set to have draw:fill="solid" and a derived style to
draw:fill="none" then the derived one must have
fo:background-color="transparent" to override the parent for old
consumers like LO <= 4.3/AOO <= 4.1 that don't understand draw:fill.

Change-Id: I5b56c7ace927338239195c6bfcfef1950544c8d2

The problem is that if the FillStyle is NONE, setting only
ParaBackTransparent but not ParaBackColor does absolutely nothing.

This means that if a parent style sets a background color, then a
derived style cannot override it to be transparent.

Cause is that getSvxBrushItemFromSourceSet() defaults to setting a
0xFF transparency on the SvxBrushItem.

There is still a problem that getSvxBrushItemFromSourceSet() sets the
pool default item's color and that is also exported to ODF again as
draw:fill-color, but together with draw:fill="none" it should not cause
harm, at least for consumers that prefer draw:fill attributes like
LO >= 4.4.

(regression from 7d9bb549)

Change-Id: I5312901166a0e6f0cf02369b173dc8498e4113ed