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

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

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

Change-Id: I27a860fbbedd2174c60c199af18cae76e02abc25
Reviewed-on: https://gerrit.libreoffice.org/43759Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

and fix bug in ScriptDocument::getTitle
which has been there since

    commit e304ba66
    Date:   Thu Mar 15 14:59:30 2007 +0000
    INTEGRATION: CWS basmgr02 (1.1.2); FILE ADDED

plugin is off by default since it uses expensive parentStmt() calls

Change-Id: Id0f16baec48e0381e0083594d7e59b58b023da2f
Reviewed-on: https://gerrit.libreoffice.org/43750Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I3d468ac495c37f8b155f14943bd0a0ac10bd9d06

Change-Id: I83c719594a29cde8385a22793f17812e7d5c12bb
Reviewed-on: https://gerrit.libreoffice.org/43796Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

Regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=19910c461230f70bb9e98ad44db3525f0d755724
tdf#112658: fix leak when calling TextEngine::SetAttrib

Change-Id: I4f1edf41e11f3cdfda6071b30a84372db68cd59d
Reviewed-on: https://gerrit.libreoffice.org/43795Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Currently only backspace is supported. No undo yet.

Change-Id: I9a384d19bbaaaab05093d0d4ba74f089c6a4fae1
Reviewed-on: https://gerrit.libreoffice.org/43630Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>

Change-Id: Ia1f4d1254583d04d1993e9a0ce8ad1f1aaa868d3

Change-Id: Ibd25502384cd248f1070d26266222e18fb9e2e47

Change-Id: Ie63e62995bee0fd950cea0668f5ae06c903b25a3

Change-Id: Ib39ca1e1d73ad4dc91c70ac3f4cdd1bdd24c2b29

Change-Id: Icc007d5c08f88ffdeb6e2d033615dccb140862ea

Change-Id: I0778ecffe5dbc5fdfe24705d37511e197a4a1ce4

this is WIP and crashes and leaks left'n'right

Change-Id: If4be8cf6d426b705b5dbb5893a18cdbce2aa541a

Change-Id: I72da846525128a689d92598b64e6a70062ff1c69

Change-Id: Id30494fa1b01510e300f39b985b3a49ea58d81bc

Change-Id: I1a1625428cca0be7ece5fb4604aaacef4967a405

add log area too

Change-Id: I187c04c8646ec9c9264d84938e1ccf3a1cbd62f1

Change-Id: I70f0c4147721a20459e1183ff40cf0ac8adf49e6

Change-Id: I132b7702cda2504ecad07d407b160eeb47798624
Reviewed-on: https://gerrit.libreoffice.org/43693Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: Icbfc6d1c7ec5c64671025ce4c4f39f282d2edb08
Reviewed-on: https://gerrit.libreoffice.org/43685Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

OUStringBuffer::append(double) always uses '.' decimal separator.

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

Change-Id: I99eb764842838b1481483b69d9183e52834e1298
Reviewed-on: https://gerrit.libreoffice.org/43629Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>

...when compiling as C++17, so the ParenExpr is no longer hidden behind
ExprWithCleanups/CXXConstructExpr/MaterializedTemporaryExpr wrappers.

Change-Id: I81346edbef46cad72bf53a43f162a75d19b6c713

...similar to a2d814ac
"loplugin:implicitboolconversion"

Change-Id: Id664a066549498548c123e8dbdc68ba43af9348e

("explicit conversion (NoOp) from 'const bool' to 'bool' implicitly cast back to
'const bool'", seen now with a recent trunk Clang 6, and with experimentally
enabling -std=gnu++17 for the LO build; not sure what caused this to be
triggered only now for me)

Change-Id: I5310961b1d50870d3ae06554e4cb37e12ac68151

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

Change-Id: I143e8df0e16ad921777b9caabde8e1c3f8bd61df
Reviewed-on: https://gerrit.libreoffice.org/43788Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

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

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

the gif in question has gif disposal mode "previous" set
on the first frame

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

Change-Id: I1e65f075a0519db86836b3aa09848178796a020b

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

Change-Id: I5a14ff75c27062e33cbd93efb931c203135648a3

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

...that caused Flatpak'ed LO to sometimes not terminate properly after
243d743d "solenv/flatpak-manifest.in:
incorporate upstream sandboxing improvements" had removed --socket=session-bus
and thus introduced flatpak-dbus-proxy into the mix:

> Oct 24 15:25:16 <sberg_> I'm not sure who's at fault there; on the LO side I
>  have a thread processing incoming dbus requests (DbusIpcThread::execute,
>  <https://opengrok.libreoffice.org/xref/core/desktop/source/app/officeipcthread.cxx#552>);
>  that thread is typically waiting within dbus_connection_read_write_dispatch
>  for new messages; if LO wants to close, it needs to get that thread out of
>  dbus_connection_read_write_dispatch, and the only way I found back then is
>  what's in DbusIpcThread::close (just following DbusIpcThread::execute), with
>  a big "this apparently needs a more DBus-y design anyway" testament to my
>  cluelesness re dbus; it calls dbus_bus_get_private to connect to itself, and
>  send a Close message that'll cause DbusIpcThread::execute to fall out of the
>  loop; the dbus_bus_get_private leads to a flatpak_proxy_incoming in the
>  proxy, which returns TRUE, and after that I see no further activity in the
>  proxy (but not sure what functions I should all put breakpoints on), and the
>  LO side is hung in dbus_bus_release_name a few lines futher down
> Oct 24 15:26:20 <alexlarsson> sberg_: i ran this:
>  https://github.com/sgh/dbus-examples/blob/master/dbus-signal.c
> Oct 24 15:26:27 <alexlarsson> sberg_: which calls dbus_bus_release_name
> Oct 24 15:26:30 <alexlarsson> and it seems to work for me
> Oct 24 15:26:39 <alexlarsson> If i --own-name=org.DBusTest.SignalTest
> Oct 24 15:27:50 <sberg_> so maybe it's related to my unorthodox way of trying
>  to quit the dbus loop there;  if anybody with a clue about dbus would be
>  willing to help me with the above, I'd be very grateful :)
> Oct 24 15:28:06 <alexlarsson> I don't see how the proxy should affect it tho
> Oct 24 15:28:11 <alexlarsson> other than maybe timing?
> Oct 24 15:29:06 <sberg_> maybe; I think I've seen things actually succeed once
>  when I stepped through the proxy somewhat manually
> Oct 24 15:31:01 <alexlarsson> sberg_: eeeentresting
> Oct 24 15:31:07 <alexlarsson> sberg_: so, it does an own-call
> Oct 24 15:31:13 <alexlarsson> sberg_: maybe that is what breaks?
> Oct 24 15:31:33 <sberg_> yeah, that's my dumb speculation
> Oct 24 15:34:38 <alexlarsson> So, you send the close from another thread, not
>  waiting for the reply
> Oct 24 15:34:56 <alexlarsson> then you start working on the main connection
>  immediately
> Oct 24 15:35:02 <alexlarsson> shouldn
> Oct 24 15:35:25 <alexlarsson> shouldn't you grab the mutex after that?
> Oct 24 15:36:35 <alexlarsson> This whole thing smells racy
> Oct 24 15:38:18 <alexlarsson> My guess is that with regular dbus, the flush
>  call will schedule dbus daemon which sends back the message, waking up the
>  other thread before continuing
> Oct 24 15:38:22 <sberg_> alexlarsson, ah, yeah, I see; apparently didn't
>  occur to me back then that I mustn't call dbus_bus_release_name when the
>  execute loop may still be busy
> Oct 24 15:38:25 <alexlarsson> But now you have two context switches
> Oct 24 15:38:37 <alexlarsson> so we continue before we get the reply
> Oct 24 15:38:44 <alexlarsson> eh, not reply
> Oct 24 15:38:46 <alexlarsson> the close message
> Oct 24 15:38:52 <alexlarsson> and then you race
> Oct 24 15:39:11 <alexlarsson> Honestly i don't remember the exact rules for
>  dbus threadedness
> Oct 24 15:39:58 <sberg_> ...so looks like something that can be corrected on
>  the LO side after all; I'll give it a try
> Oct 24 15:40:17 <alexlarsson> you're calling dbus_threads_init_default(), so
>  it should be nominally threadsafe
> Oct 24 15:40:29 <alexlarsson> still, I imagine it can still deadlock
> Oct 24 15:43:12 <alexlarsson> sberg_: i still don't see the exact deadlock
>  though
> Oct 24 15:43:32 <alexlarsson> i imagine working on the separate private
>  connection is threadsafe
> Oct 24 15:43:35 <alexlarsson> and we flush that
> Oct 24 15:44:08 <alexlarsson> then we call dbus_bus_release_name, which i
>  imagine would block if the dbus thread is in read_write_dispatch
> Oct 24 15:44:35 <alexlarsson> The question is, why is the close message not
>  delivered?
> Oct 24 15:44:44 <alexlarsson> I mean, we flushed it...
> Oct 24 15:45:48 <alexlarsson> sberg_: oh, i think i know
> Oct 24 15:45:53 <alexlarsson> sberg_: release_name probably sent some message,
>  but then the other thread pop:ed the reply
> Oct 24 15:46:04 <alexlarsson> sberg_: queue very long wait
> Oct 24 15:51:53 <sberg_> alexlarsson, yeah, sounds plausible; thanks!
> Oct 24 15:52:14 <sberg_> (now that I want to reproduce it, closing succeeds
>  cleanly every time I try, of course...)
> Oct 24 15:54:48 <alexlarsson> sberg_: obviously
> Oct 24 15:55:30 <alexlarsson> sberg_: that just makes the race theory more
>  valid tho
> Oct 24 15:57:31 <sberg_> alexlarsson, yup, after stopping the unrelated
>  background LO build that had put the machine under full load, I see it hang
>  again in release_name, while the execute loop is still happily running too;
>  that nicely confirms your theory
> Oct 24 15:58:28 <alexlarsson> sberg_: alternatively you could tell your users
>  to always build LO in the background
> Oct 24 15:59:04 <sberg_> I'll try to put that into the release notes; lets
>  see...

Change-Id: I2a8a58f9259d2854f42f4aa3db5bb232cf70845d

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

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