cherry-pick from master

caused by commit 5333782d
"convert SETTINGS_ #defines to 'enum class'"

Change-Id: Id0c2738a61f73223f6c8716f04a619c8cb84c0a9
Reviewed-on: https://gerrit.libreoffice.org/17493Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Wrong copy-paste

Change-Id: I7460c095c7bbb340be2cab32c4724688076c5952
Reviewed-on: https://gerrit.libreoffice.org/17477Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
(cherry picked from commit 4a847bb4)
Reviewed-on: https://gerrit.libreoffice.org/17488Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

In case we had a toplevel window W1, the paint was triggered for window
W2 and we had a sub-widget W3, then previously the buffer was created
for W2, so the pixel offsets had to be set relative to W2 when rendering
W3. As a consequence, if a single window was painted, then it was
always painted in the top left corner.

Now that the buffer is persistent and is always created for W1, make
sure that we paint to the correct offset, and W3 is always painted at
the same offset, regardless if it was painted directly, or just because
it's a child of W2.

With this, the buffer conents is closer to what is on the screen, even
if it's not perfect yet.

Also:

- PaintHelper: restore set buffer properties
- let PaintBufferGuard also manage pixel offset
- no need to tweak map mode in PaintBuffer()

Conflicts:
	vcl/source/window/paint.cxx

(cherry picked from commits 94a6daa0,
c36a00b8,
28e465d2 and
ec1a0354)

Change-Id: Ibf0e89ad18e5763bd2a01e69d91da163c24a309d
Reviewed-on: https://gerrit.libreoffice.org/17518Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

The hard-coded "/" separator causes getFileURLFromSystemPath to fail,
and it's not obvious why the URL is being converted to a system path
in the first place.

Change-Id: I06ebe6d92954c4f3c884ae6f0b327ea8a36c10a4
(cherry picked from commit 8bf374b9)
Reviewed-on: https://gerrit.libreoffice.org/17512Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

...introduced with c1b9d61b "tdf#88276: Add slot
and handlers for toolbar|sidebar buttons"

Change-Id: Ic63a7766b7f0ccae9144a0ef276e2df63fc22f2e
(cherry picked from commit 4275056a)
Reviewed-on: https://gerrit.libreoffice.org/17508Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The change to sal/log.hxx affects extensions too which are not required
to use a C++11 compiler.

Change-Id: I3ed08f9a02a2e082fcdb821bce84244597f2390a
(cherry picked from commit f168fcae)
Reviewed-on: https://gerrit.libreoffice.org/17502Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Ibb674e17eedfc325d3e335aa074391ad7b2b2aa2
(cherry picked from commit 6c853a98)
Reviewed-on: https://gerrit.libreoffice.org/17486Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: Ibb4a308cfae3598e4d4e9759806c48f6a581bc83
(cherry picked from commit 8a323729)
Reviewed-on: https://gerrit.libreoffice.org/17485Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

So at least in case of the CTRL_LISTBOX, getNativeControlRegion is
called for a type and part unsupported by IsNativeControlSupported.

For whatever reason, this results in broken listboxes drawn in
Base's "Table Design" dialog, when selecting "field type", which
draws the listbox on top of the cell.

To make it worse, it seems the listbox is actually drawn to a
smaller space then the actual requirement. Appearently it seems to
use the content rect, instead of the bounding rect.

So in addition to fixing the drawing, this patch increases the
listbox bounding rect, which looks too large in normal dialogs, but
makes the Base's listbox better readable.

Change-Id: I112ec038fd20ad33facd260d16b5d68b508d2bd0
Reviewed-on: https://gerrit.libreoffice.org/17438Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>
(cherry picked from commit ef126328)
Reviewed-on: https://gerrit.libreoffice.org/17448Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

- correct return value in Execute method: returned alays False, should return True when successful
- Item property of collection did not work because incomplete object initialisation

Change-Id: I9b2e682afb21747766e918bf905e35d9485b751d
Reviewed-on: https://gerrit.libreoffice.org/17351Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

The web wizard runs some XSLT over the exported file.  It registers
a handler that is called when the output stream is closed, and this
Process.streamClosedHandler() calls terminate(), which causes the
deadlock, because it wants to join() the extra XSLT thread but the
handler is actually called from the XSLT thread itself.

Fix that by moving the terminate() to another function that runs in the
main thread.

It does not deadlock on Unixes because osl_joinWithThread() actually
detects an attempt to join the calling thread and returns early.

Change-Id: Ia176562fa28b97c7e8956c1e8975c9aa6ee23236
(cherry picked from commit 62de18ab)
Reviewed-on: https://gerrit.libreoffice.org/17511Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Project: translations  c99833cf91a9e95776f1a279e791f55343f51685

Updated Slovenian translation

Change-Id: Ia05064ecd5f0ff8cc48552183abaa437e331c70a

Change-Id: Iab1f29925c26e9cc862bb858d72eb528e656215b
Reviewed-on: https://gerrit.libreoffice.org/17475Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 68604006)
Reviewed-on: https://gerrit.libreoffice.org/17501

No need to call it in PaintHelper::StartBufferedPaint(), which would
happen only for the root of the paint hierarchy. It's enough to do it in
PaintHelper::DoPaint(), which happens for each widget.

(cherry picked from commits 27f6b2c0 and
8bb963c3)

Change-Id: Iaf3306ef746bedbe64be36c4efeae73afd75db2a
Reviewed-on: https://gerrit.libreoffice.org/17500Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Fix the issue caused by wrong assumption about symbol chracter
and symbol font attributes order in writerfilter. Also allow
symbols to be displayed if user's language is not Western.

Reviewed-on: https://gerrit.libreoffice.org/16543Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Conflicts:
	writerfilter/source/dmapper/DomainMapper.cxx

Change-Id: I602d9fbfa79c33c90f655dbf5ee22738b6391ae6
Reviewed-on: https://gerrit.libreoffice.org/17457Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

SwUndoFormatAttr was simply missing a case for RES_CONDTXTFMTCOLL.
Handle it the same way as an oridnary paragraph style, which seems to
work for me.

Change-Id: Ib529beb1116633e4890d5b51df39da21de485db9
(cherry picked from commit 37e93699)
Reviewed-on: https://gerrit.libreoffice.org/17428Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Instead of in PaintHelper::StartBufferedPaint(). If the buffer size is
set to match the size of a sub-widget (for which the paint was
triggered), then client using the buffer as a persistent vdev are unable
to paint at arbitrary locations.

For example, if we painted the ruler, then the blinking cursor won't be
able to paint to the SwEditWin area.

(cherry picked from commits 161f7533 and
43ac95ab)

Change-Id: Iba07070baafb5b802fc6da200696611afd2010d7
Reviewed-on: https://gerrit.libreoffice.org/17490Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: Ie2d1cb7312de6f14a5c6de81eefd7a00be6f75c0
(cherry picked from commit 396643d4)
Reviewed-on: https://gerrit.libreoffice.org/17421Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

This was causing all these "libpython3.3m.so: file not recognized: File
truncated" failures.
(cherry picked from commit 57dd4d01)

RepositoryExternal.mk: for some reason Mac wants a GeneratedPackage
(cherry picked from commit d9162d24)

Change-Id: I5d983fee8d5cd313fbd0d6ece800fa8b80d81b35
Reviewed-on: https://gerrit.libreoffice.org/17398Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: David Tardon <dtardon@redhat.com>

With scientific format, use the trick of thousand separator to detect
Engineering notation.

Change-Id: I7acdfb8bec646f9d6c1a17c334b60fa9708c8111
Reviewed-on: https://gerrit.libreoffice.org/17406Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit f4bdd798)
Reviewed-on: https://gerrit.libreoffice.org/17440

This partially brings back the behavior before
10a3db37.

Change-Id: I5b372ab56105c05dda6ecb9aa1eed1c6a0c72ea8
Reviewed-on: https://gerrit.libreoffice.org/17420Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Instead:

- create it early in Window::ImplInit(), except for the default window
  (that one is a chicken-and-egg problem, as creating a VirtualDevice
  invokes ImplGetDefaultWindow(), but creating the default window then
  would create a VirtualDevice)
- only erase the painted area of the buffer, don't create it
- use a separate bool in the frame state to track if we're in the middle
  of a (possibly recursive) buffered paint

And with that, rename CreateBuffer() to StartBufferedPaint(), as it does
not create the buffer anymore.

Change-Id: Ib33e8afa36977aa809f0ea2158a369f288cba8c7
(cherry picked from commit ea5e83ab)
Reviewed-on: https://gerrit.libreoffice.org/17445Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

With this, vcl::Cursor does not paint on the vcl::Window directly, and
in case the output should be something other than pRenderContext, it
should be a one-liner change to do that.

(cherry picked from commit 79c9598d)

Conflicts:
	vcl/source/window/cursor.cxx

Change-Id: I57833f6f8589286260d96f412f1fcc681e6c5c8c
Reviewed-on: https://gerrit.libreoffice.org/17433Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Change-Id: Ibb7500527d0ff142a6ba89a20894258cb63eeed5
(cherry picked from commit 2d9db406)

Change-Id: Ia3931f3cac13894ccd51772312110367194e19c6
(cherry picked from commit 8552e928)

by reducing the width of the graphical element

Change-Id: Ie100629e2602f8f9a3f0e4e1ba353178f219c9a0
(cherry picked from commit 303b7758)

Revert the API change from e41c33b3
and use the existing css::util::XUpdatable instead.

Change-Id: I3eba4c7def98c8765a970d54a7fe84a320d4313e
Reviewed-on: https://gerrit.libreoffice.org/17382Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit 41d1b01a)

With this, code that wants to take a persistent render context (e.g.
vcl::Cursor) will be able to do so. This commit just moves the buffer,
though: it's still created / deleted by PaintHelper.

Having it in ImplFrameData means that we'll have one buffer / one
system window: i.e. toplevel window and its sub-widgets share a buffer.

(cherry picked from commit a33e0379)

Conflicts:
	vcl/source/window/paint.cxx

Change-Id: Ic37220a2a483a7389aa04cd4313b6fc61a5408bf
Reviewed-on: https://gerrit.libreoffice.org/17414Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

(cherry picked from commit 86d2cdda)

Change-Id: I0a876e9afa9a90f312d68611a8adf5a962da784d
Reviewed-on: https://gerrit.libreoffice.org/17413Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

With this, vcl::Cursor will be able to paint to a vcl::RenderContext,
too; not just directly, which is needed for double-buffering.

(cherry picked from commit 09bd5846)

Conflicts:
	include/vcl/window.hxx
	vcl/source/window/window2.cxx

Change-Id: I868f6cd9b08afe59611ef266911a894a26cacedc
Reviewed-on: https://gerrit.libreoffice.org/17401Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

With this, the print preview window no longer performs direct paint.

(cherry picked from commit 46e7991b)

Conflicts:
	sw/inc/pagepreviewlayout.hxx

Change-Id: I53f05d8a3b723bc131f21a485e0ffec71484670a
Reviewed-on: https://gerrit.libreoffice.org/17394Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

JunitTest_forms_unoapi_3 just crashed in DropTarget::disposing()
with m_pDropTarget pointing to garbage.

Change-Id: Icb5ad15a3d4b857b45553543d404e14abbac4374
(cherry picked from commit 372d4166)
Reviewed-on: https://gerrit.libreoffice.org/17388Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

With this, when the user select an other page in the print preview
window, the selection rectangle is no longer painted directly.

Change-Id: I85f1cb9d09c8545222ed49ff0acf819540d10920
(cherry picked from commit da24bd36)
Reviewed-on: https://gerrit.libreoffice.org/17381Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

With this, the print preview window does not paint the selection
rectangle on opening directly anymore.

(cherry picked from commit 0c114151)

Change-Id: Ie4d24dfc4d64c74b22dcd1476778f4eac6f4cd13
Reviewed-on: https://gerrit.libreoffice.org/17363Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

Change-Id: I6b7379323a86242b42a8a5137807c535bf1d7c46
(cherry picked from commit 6be72cc2)
Reviewed-on: https://gerrit.libreoffice.org/17374Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

This method is used to get the sheet's name and to display it
in the tabs (sheet selector)
I've also added an unit test for it and uncommented a similar one

Change-Id: Ia866815c594a873812c71a6c86e303c869e1f093
Reviewed-on: https://gerrit.libreoffice.org/17294Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 50fe21c7)
Reviewed-on: https://gerrit.libreoffice.org/17368

Change-Id: I24868acec66a72abbb52b8026ed3a092dbd97632
Reviewed-on: https://gerrit.libreoffice.org/17347Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit 11f24bc2)
Signed-off-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I8e4983a91d4f97a2a20fbeed89d4e0f186c35fad
(cherry picked from commit f29ac1d9)
Reviewed-on: https://gerrit.libreoffice.org/17373Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

here we appear to check if the preceding optional entries are of certain
types. Presumably if they are optional then its legal for them not to
exist at all, just that if they are there they should be in the right
order.

Change-Id: Id147b91d7d375d7985d901cda112c7757dc3fb19
Reviewed-on: https://gerrit.libreoffice.org/17353Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I81a784ab506d0d3ae266d7341b8ff7a163dcd8d2
(cherry picked from commit 442b788b)
Reviewed-on: https://gerrit.libreoffice.org/17327Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>