free(NULL) does not crash, it is defined to do nothing. Did I not know
that in 2010?

Change-Id: Ia6c4817ea87b646d643a19daabfe7850c5416cc8

Change-Id: Ia3fc26c8d3ec433e2cdf401b0fc0d70de4611210

Change-Id: I33457a2e1a213c6eb172ab188272e9688cd2ccad

Change-Id: Ic2eec30cfb5f61c53777eefeeb8bad6f552da2fc
Reviewed-on: https://gerrit.libreoffice.org/17355Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

We now have a complete toolbar controller in chart2.

Change-Id: I007d9b058e3d6800204ac035cc2aef5e93c1208b

Change-Id: Id0658cf561570a2ae15fb7fd603e6437da9cfaf2

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>

Change-Id: Ifc2f4592fdd4cfebdefc0c4b94656ffc06ddf879

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

Project: help  bbece63b0f7b182f8bbf36accef29bb7a42e7800

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

Change-Id: If90b4d89c0dc7172b417b30dd242278386813244

(Not that I know if there is any good reason to keep it optional.)

Change-Id: I92c52ad201661755e2d6eb023be7e268249b75a2

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

from both the code and the XCU files

Change-Id: I47f1f33c3ad4a37e346e3b8020dd9d3e284ccb77
Reviewed-on: https://gerrit.libreoffice.org/17522Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.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

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

Change-Id: Ie551cc9c1de20c017d8cf9f4d6f060729f9c245b

with the variadic variants in embedserv and eventattacher.

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

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

Change-Id: I9888f8ab7bccdd2902d619487279999f2ff9ab13

Change-Id: I3afde8e7f8b0b88e8f1a5d1ad71429c2aa7d7a94

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

... at least not if VCLXWindowImpl::OnProcessCallbacks drops it and
calls arbitrary event handlers.

So try to make nested SolarMutexReleaser work in that case (although
poorly).

Change-Id: I1e2a1f4d6f42f826692696f7d92d1c3d71291f39

Change-Id: I5063f7f6975d7aae8441e51a98e8b49642ed2970

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

Change-Id: Ic63a7766b7f0ccae9144a0ef276e2df63fc22f2e

This used to be necessary, but now that the "copy settings from the
window to the buffer" is always guarded with PaintBufferGuard, it's
actually one of the places that do modify the buffer settings without
undoing that later.

Change-Id: I7fde878635ffc7de7027d6d8f8de47935fc4870e

Change-Id: Ia208e3309bb64baf71ceb97cdf1b3b57b6120353

Change-Id: If0e644298c655487cf97609a66ee37c5b4bd70ae

Change-Id: I175d27311fa166d3d33f2d88184b1fcd01f5df6a
Reviewed-on: https://gerrit.libreoffice.org/17476Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>

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

Change-Id: I3ed08f9a02a2e082fcdb821bce84244597f2390a

Change-Id: Ifd6a75c4312f93c815f5d137f515724f3629fa0d

If the buffer is persistent, then any member we change on it, so it suit
our needs have to be undone once we're done with the painting.

Change-Id: I7c5491b3b27601fb367af0856ac95cc3f845647a

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.

Change-Id: Ibf0e89ad18e5763bd2a01e69d91da163c24a309d

Change-Id: I2d23f199d07b4a339f080263b27d13faddc11ffb

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>

See https://gerrit.libreoffice.org/#/c/16960/ for details

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

Change-Id: Ied02019c6e11287ba574bb861ed7b2a8da1f8083

Change-Id: Iede9204bf93014e757c4fdf4a8363a90b7577dbc

Change-Id: I3f6c5b11830fcc581e662d2c000669ee80accaf5

introduced by commit c15b4cf3
"Adapt to current Clang trunk towards 3.7"

Change-Id: I00f58d3bc79e641df9bba4e9b1d5c8463b87dc42

Change-Id: I8471af77361364ce677f7a31dda78168909dea90