Change-Id: Ic25500637f1748bf117bafd7483d589729a2e658

Change-Id: I9f23a6077046809083e254d4c79590b67b071fb3

The problem is that in tiled rendering LO doesn't always consider the
document to be modified. Some operations such as Bold, Italic, etc do
not mark the document as being modified, but we need to be able to save
the changes. This solved the issue by always allowing to save.

Change-Id: Iaf8120abadc768a07b24f42c287c50080b4e4d89
Reviewed-on: https://gerrit.libreoffice.org/17665Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>

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>

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>

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>