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

Change-Id: I92d172a166606189ce386826eee566623ec4a83c

Change-Id: I36e2a01822883251f9556fcde0e0a9830356ac98

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>