Age | Commit message (Collapse) | Author |
|
because of addToUnoRc and addToConfigmgrIni which use push_front
(and no easy way to change this), I couldn't use vectors
+ use for range loops
Change-Id: I15300122b449b3a5af7c6402a7ad4cd5a2000413
Reviewed-on: https://gerrit.libreoffice.org/44233
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I264a8b4d8fc90f647d5a6f1aef4a190353d494e5
Reviewed-on: https://gerrit.libreoffice.org/44143
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I65c395157d2b68a549a6fecf9abf1fd46446d960
Reviewed-on: https://gerrit.libreoffice.org/44109
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib1cd2278d1af651b96f07c8831382bba7f51aed6
Reviewed-on: https://gerrit.libreoffice.org/44037
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I1beb5ab3f06debdca7ebf999af7ac879a41ea47e
Reviewed-on: https://gerrit.libreoffice.org/43959
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: pranavk <pranavk@collabora.co.uk>
|
|
Change-Id: I245c58a3d97eb0d60e7063e9c34c77d33739801d
|
|
switching back to a "Close" message-to-self without a response (as it had been
before dc3ff192f3f048059cf149f416d0b237eb33b014 "Avoid further unwanted
interference of DbusIpcThread::execute/close"). Especially on a first start of
LO (where it restarts after creating the UserInstallation), it had been observed
that DbusIpcThread::close was blocked waiting on a reply in
dbus_connection_send_with_reply_and_block while DbusIpcThread::enable had
already successfully (i.e., without emitting any of the SAL_WARNs) proceeded
past sending the reply and was blocked on closeDone_.wait(). However that can
happen---it should be clear by now that I don't understand anything at all about
DBus. :(
Change-Id: Id5f368a60b2d8dd8b7074308ac1ad6b6545131ff
|
|
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
|
|
Removed the IPC part of init for iOS.
Lo_init() completes for iOS without errors.
Change-Id: I7ce38758883bebea1de6ac149ba8768593c7cb78
|
|
...after 38081c0884b64ed1132047973b4dccc42d548c89 "Avoid race between
DbusIpcThread::close and DbusIpcThread::execute"
Change-Id: I812f53525f4c2c051781321dac7096e3bf0d7054
|
|
...that caused Flatpak'ed LO to sometimes not terminate properly after
243d743dae127fe11ecd7f807121da8815af8f01 "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
|
|
InitVCL() needs to be called for iOS, even though it runs
without desktop, since that function fills structures like
mpDefInst
Change-Id: Icebd4a4111881b46a8abc1e1988921a19e5e4527
|
|
Change-Id: I2dacb21cd0c9618dadb49912e0f09c9ab576f9b0
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia6a498c07fffd1790ad433287ef4d1cf82085887
Reviewed-on: https://gerrit.libreoffice.org/43695
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0f6e284d232388019bfa33f07a4afc864e0040a9
|
|
Change-Id: I9791fceb975ca9d0a0ca0ae61c0890826d06c564
Reviewed-on: https://gerrit.libreoffice.org/43510
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iaeb0060f390035bb214b9d1d8d090e7b933c9f77
Reviewed-on: https://gerrit.libreoffice.org/43509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The OSL_ASSERT doesn't make any sense, if you don't know what it
compares. So simply log all found updates.
Change-Id: I002b65cf4a658036916a217a89d0df7f0168ee70
|
|
Change-Id: Ia1a03f324e9b66dc36abadc326843b88b33ed249
Reviewed-on: https://gerrit.libreoffice.org/43348
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.
Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ia23dafd07133779144965682df3b7125a3214235
Reviewed-on: https://gerrit.libreoffice.org/43046
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This reverts commit a599eeab786ecbe1b5b6509e3c792e5c1ba31248, plus follow-up
fa4431449d0306e8179f53a2a69c549800bd24bd "Avoid bogus loplugin:dllmacro
'unnecessary *DLLPUBLIC declaration ...'". See (abandoned)
<https://gerrit.libreoffice.org/#/c/42983/> "loplugin:dllmacro: Handle implicit
member functions" how this would have needed to be extended to give consistent
results across Linux and macOS, but then would have started to remove DLLPUBLIC
from entities that apparently need to at least have default type visibility on
macOS and started to make tests fail.
|
|
Change-Id: Ia632e4083222ad9e7f17c2ad0d0825f189c700cc
Reviewed-on: https://gerrit.libreoffice.org/43071
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iab3c142cd85ca54bf3c37a0710ce7da7a5d77a35
|
|
Change-Id: If81cd3d4508ba3f44304a9ec9b643bf771e8930c
|
|
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd
Reviewed-on: https://gerrit.libreoffice.org/43025
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4a1f04b9dfe9e3ebbc174380db93c332e958ccfa
Reviewed-on: https://gerrit.libreoffice.org/43060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Before commit 3840aede596e6fc24f7ed7df9100fb028134aac6 releasing
an unlocked SolarMutex was simply ignored, but now it aborts.
So run the LicenseDialog GUI code holding the SolarMutex, as
required.
Change-Id: Id9f5f6146cdfe2b21b68a2cdffc9dd4a527b551c
Reviewed-on: https://gerrit.libreoffice.org/42951
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
We can specify whether it is an invalidation or something else in the
payload.
Change-Id: I95c5fc0a0a88b5277eaa93c8d1f9b937bddce7b3
|
|
Change-Id: I06a081835d246f752e57f8cc289162ed31fc91d4
|
|
Now gtktiledviewer can show floating window dialog widgets when user
clicks any of such widget in the dialog.
Change-Id: I13d756f236379bc8b2041ed41cb7b502f7fd9b24
|
|
Events from the dialog in GTV are forwarded correctly, but the events
are still not processed by the dialog in core.
Change-Id: Ib95ac0a3cd23f6cc2763c21425a67402b15f2de2
|
|
Change-Id: I94578b9e9c7fc2e6a9d14effe456d821768a0bcb
|
|
These are used to supress any dialog invalidations emitted while
painting the dialog. We are not interested in any such invalidations.
Change-Id: I2a7b018124af501bce18adbff0f5db85adf5fce2
|
|
After painting the dialog, also write width and height of the rendered
dialog. The dialog is rendered
always on the top left of the given canvas, so client can crop the
canvas accordingly.
Change-Id: If052058a6db8a85d4e28ec88cffcca05564b17f0
|
|
Change-Id: I1d85729a1ac1a99d33ea2bde1b50ccf4c05ca9a9
|
|
Change-Id: I3828113bce3b7d32e90e461a299986e363115a83
Reviewed-on: https://gerrit.libreoffice.org/43002
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
on classes which are fully defined in a header file
Rename the dllprivate plugin to dllmacro and add the functionality
there.
Change-Id: I4581d551c46a8f61213d95973f323359d08278d8
|
|
also make the plugin ignore the case where we have var decl's in the
clause we want to flatten, which could lead to problematic extension of
variable lifetime
Change-Id: I3061f7104e8c6a460bf74f5eac325a516ec50c59
Reviewed-on: https://gerrit.libreoffice.org/42889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I879a52820d78d9151ef64dd21612379f617f66e2
Reviewed-on: https://gerrit.libreoffice.org/42726
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Ia6402f6d2c978cbd5557052a43e9728ca9e11173
Reviewed-on: https://gerrit.libreoffice.org/42285
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I95b90128e93f0d88ed73601bcc5a7ca9279d4cf1
Reviewed-on: https://gerrit.libreoffice.org/42560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iff59d3049ba40b4338ef8eec67d08a96b0834d2b
Reviewed-on: https://gerrit.libreoffice.org/42578
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0bd4cb463575af843c72d9c8aaf91742203532a4
Reviewed-on: https://gerrit.libreoffice.org/42283
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I5c22ff70d3895b0f4a86eb8be85dde971604874a
Reviewed-on: https://gerrit.libreoffice.org/42480
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
|
|
Change-Id: Iadb0ebb66809c192fb817b8c7cf2f8cdb4d0b874
Reviewed-on: https://gerrit.libreoffice.org/42419
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ied81f20900060ff6a78704fa9195320b8fb86e45
Reviewed-on: https://gerrit.libreoffice.org/42269
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
This is a f70e0ec6b3c61a7c7caa469949b0ac8016c89854 follow-up.
Change-Id: I4acf00a6da85ed14be4ed0ca20d541a9441736e7
Reviewed-on: https://gerrit.libreoffice.org/42266
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|