just the straight-forward MessageDialog cases first
a) remove border_width from message dialog .ui so as to take
the default border width
b) retain 12 as default message dialog border for vcl widget case
c) remove layour_style from message dialog button boxes so as to
take the default mode (a no-op for vcl widget case)
d) use gtk response ids (vcl builder will converts to vcl ones)
Change-Id: I7de281093a1b64f92f71ca11e7cbba42bb658154
Reviewed-on: https://gerrit.libreoffice.org/50143
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
The documentation suggests this should disable recovery, so read the
config value at the same place where we disable recovery due to the
environment variable.
Change-Id: I342ae58201aa1d731a5913c2f0598ddff2a8d602
Reviewed-on: https://gerrit.libreoffice.org/49706
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The current update MSVC 2017.5 supports fancy new C++ features, but
unfortunately in its default C++14 mode it falls over and dies with
an internal compiler error as soon as it sees the WeakImplHelper
variadic template.
In order to work around the ICE, build everything as C++17,
which somehow doesn't crash.
This causes loads of deprecation warnings about obsolete std::this
and badly designed std::that, almost all of them from boost headers,
which are well known for following every best practice in the C++ book.
Liberally sprinkle macros around to suppress the warnings for now,
like we already do with the other million warnings from boost headers.
Change-Id: Ia6b6ef5e457b5fe3c8cfe361ba5da39376bb7c4c
Reviewed-on: https://gerrit.libreoffice.org/48225
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
When application is initializing, initially request handler is not
processing requests (its state is Starting). Requests processing is
enabled in Desktop::OpenClients() after recovery had been processed.
If another soffice process is started, it communicates over already
established pipe, and sends a request to the first process. In
IpcThread::process(), it is decided if the request needs to be checked
for completion (e.g., if a file or specific module was requested to be
open). After that, the prepared request is posted for processing. In
case when the completion should be checked, PipeIpcThread::execute()
then waits for Processed condition indefinitely.
Request is processed in RequestHandler::ExecuteCmdLineRequests, which
first checks that handler's state is RequestsEnabled, and if it isn't,
then returns. Otherwise, after processing, Processed condition is set.
The problem is, thus, in case when the request comes before requests
processing is enabled (e.g., when recovery dialog is open): request
handler thread waits indefinitely, but the processed condition will
not be set. This will not allow to close the pipe to second process,
and it will hang indefinitely. The IPC thread will be hung even after
user closes recovery dialog, and continues working with program. So,
subsequent attempts to open files from file manager (launching new
process) will fail, and new zombie soffice processes will wait the
first indefinitely. Also, when first process will be closed by user,
the deinit sequence will attempt to wait for the IPC thread to finish
(in RequestHandler::Disable(), after all visible windows had been
closed), which will leave the first process hung, preventing all
subsequent attempts to open LibreOffice.
This patch ensures that the Processed condition is set at any outcome
in RequestHandler::ExecuteCmdLineRequests. Also, it brings (possibly
hidden) recovery dialog to front, making the reason why following
attempts to open files fail apparent to user.
Change-Id: Ibddf7483e5b1d6167ac7f307ea2442119f446129
Reviewed-on: https://gerrit.libreoffice.org/48280
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aron Budea <aron.budea@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I492363d79e443221b139f0c192a552cc5548ee4f
if ui is set to track the locale automatically and the current locale
has no match in installed resources but has a match in the list of
languages that libreoffice was compiled to contain
so e.g. de_AT locale shouldn't trigger the installation of anything if
langpack-de is already installed and yue_HK shouldn't trigger install
of anything cause that not supported (at time of writing) for libreoffice
put Fedora/RHEL/Ubuntu naming schemes in here.
I moved the lang code from svl to svtools so I could use the restart dialog
to prompt to restart after the langpack is installed, but packagekit's blocking
mode seems to be no longer blocking and control returns immediately which is a
change since the last time I played with this stuff, so drop the restart thing
for now. The lack of a blocking modal also makes the "run this on idle when there's
a toplevel window up and running" a bit futile, but lets keep that for now anyway.
caolanm->rene: I know you'd disable this anyway, so Debian is left out, there's
also config key Office/Common/PackageKit/EnableLangpackInstallation to disable
this too.
Change-Id: Ice731be539850338ccdd8af87839e0b4d83f01e7
Reviewed-on: https://gerrit.libreoffice.org/46856
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...by directly calling shutdown(3) on the underlying socket, to make
dbus_connection_read_write fall out of its internal poll(3) call blocked on
POLLIN (upon which it returns false). (dbus_connection_close only calls
close(3), so calling it from DbusIpcThread::close would merely decrement the
socket file descriptor's reference count.) This removes the need for the sent-
to-self "Close" command (whose processing turned out to be too brittle in
parallel with closing the connection down, witness my previous three fruitless
commits in this area).
There appears to be no need to explicitly call dbus_bus_release_name, as the
session bus apparently takes care of releasing the name as soon as the
associated connection is closed.
Also there should be no need to call dbus_connection_read_write_dispatch instead
of just dbus_connection_read_write, and dbus_message_pop_message should probably
be called in a loop, until all queued messages are processed.
Change-Id: I13f30b6676a531f349e953329e910c1ff45ee53e
switching back to a "Close" message-to-self without a response (as it had been
before dc3ff192f3 "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
...that caused Flatpak'ed LO to sometimes not terminate properly after
243d743dae "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
Previosly (since commit 9ac98e6e34)
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>
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>
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>
--printer-name and --outdir are only valid command-line parameters
if they directly follow their parent parameters (--print-to-file
and --convert-to). Placing them out-of-order (e.g., using another
parameter between --convert-to and --outdir) results in a generic
message that --outdir is an unknown parameter.
This change makes more useful message for these errors to avoid
user confusion.
Change-Id: I924e8571eec3de9058fe18be3789ccee2bc98c7d
Reviewed-on: https://gerrit.libreoffice.org/42039
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Tunelling 1 piece of information through 20 layers of abstraction
Advanced tunelling all the way to sfx2
Exhausted beyond recognition arrived to [Flat]ODF filter
Change-Id: I0597c20c28f5cf8e2c60c4398622b36bda83abd0
Reviewed-on: https://gerrit.libreoffice.org/41777
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Rename the global opencl namespace to openclwrapper. Its public API is
after all declared in a file called openclwrapper.hxx. The confusion
started when part of the OpenCL code was moved out from sc some years
ago.
Change-Id: I98ebd8498b2244804411e5de9169eb619f86070b
Noel Grandin