Instead of painting on the vcl::Window directly, take a
PaintBufferGuard, and use the vcl::RenderContext of it, that may be
either the vcl::Window or the toplevel frame's buffer.

Trigger the paint of the buffer by informing the guard what area was
painted. In case of direct painting, both the ctor and the dtor of the
guard is a NOP.

This means that finally we can also assert Invert() calls on the output
device, so that direct paint can't happen when double-buffering.

Also:

- make PaintBufferGuard visible outside paint.cxx
- move buffer paint logic to PaintBufferGuard

(cherry picked from commits c85b2511,
a6c7a0bf and
c64a7ce1)

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

Change-Id: Ia8c7da1e321f363efee2d60b29078b35fcbe1dcd
Reviewed-on: https://gerrit.libreoffice.org/17571Reviewed-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Unicode collation ignores control characters and other specific
characters, see
http://www.unicode.org/charts/collation/chart_Ignored.html
and thus is not suitable to be used for Equal/NotEqual operators.

Change-Id: Ib84713e1da59d92e07bc974d93b6def8217bb067
(cherry picked from commit 1e5e7b93)
Reviewed-on: https://gerrit.libreoffice.org/17240Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Hence we need a separate string as header in the dialog. Unfortunately I
did not see this when applying 0cf38e7d

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

I missed a similar bug lower down

Change-Id: I673c69dd1d36cc1b502a7de7821a05d859313aac
(cherry picked from commit 0c08cb23)
Reviewed-on: https://gerrit.libreoffice.org/17537Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Bug introduced by commit fb14be5f
"create new 'enum class' SotClipboardFormatId to unify types"

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

tdf#91278 related

Change-Id: Iab4728b07649bcbb1beb372e68369f3762b13a5c
(cherry picked from commit 01eea7fe)
Reviewed-on: https://gerrit.libreoffice.org/17264Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I6b226f8e992b3a2b6bcebc44b36ca1f2f06a128e
Reviewed-on: https://gerrit.libreoffice.org/16894Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit ebdc15f9)

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

Change-Id: I476f0ffaef383f3227c0c12b50fcdebf393190f6
Reviewed-on: https://gerrit.libreoffice.org/17487Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit dea885f8)
Reviewed-on: https://gerrit.libreoffice.org/17561Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

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

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

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

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

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

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

Change-Id: I85c7cc01113bc4ac810c450a6460059463cc8e03
(cherry picked from commit 450727fd)
Reviewed-on: https://gerrit.libreoffice.org/17554Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I088633e4cff278e1add8eeea8828f9ba9c9fb140
(cherry picked from commit c7d66949)
Reviewed-on: https://gerrit.libreoffice.org/17545Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ic45f65d10835eb39b6709e7adeed1392905ea631
(cherry picked from commit f4a2c604)
Reviewed-on: https://gerrit.libreoffice.org/17564Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

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

Change-Id: Id9dee9cfe065b30c2ae9bade1098d16e2c659c23
(cherry picked from commit d657a976)

Add a dependency from main.xcd to config_host.mk to rebuild it when the
version number changes.

Change-Id: I6878d58def57942f117b0b6e49a6c03abbeca5af
Reviewed-on: https://gerrit.libreoffice.org/17539Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit da011e05)
Reviewed-on: https://gerrit.libreoffice.org/17541

I did not notice this before, as my user profile had a custom window
size; but with an empty user profile the buffer had a 0,0 size, so the
buffered result was empty, as no ImplHandleResize() was invoked.

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

This was only done in the new gtk3 backend, all other backends seem to
ignore the GDK_KEY_RELEASE event (especially the gtk2 one). So make the
gtk3 backend code consistent with the other backends.

Change-Id: I3bdecb7ce05190ee2496bc552ca79375fb6fd713
Reviewed-on: https://gerrit.libreoffice.org/17431Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit a2eaa1bb)
Reviewed-on: https://gerrit.libreoffice.org/17529

Change-Id: I9888f8ab7bccdd2902d619487279999f2ff9ab13
(cherry picked from commit c1617b8d)
Reviewed-on: https://gerrit.libreoffice.org/17513Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  68c46e7dbaf5cf34a5b5ccb80122801dad778bbe

missing space Open Statement[Runtime] → Open Statement [Runtime]

Change-Id: If90b4d89c0dc7172b417b30dd242278386813244
(cherry picked from commit bbece63b0f7b182f8bbf36accef29bb7a42e7800)

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>