Age | Commit message (Collapse) | Author |
|
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I86f720a23dd9d400d39d9606e073b483850a9df2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131153
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib8967575c8f94436255be3145fb74af6741cad26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124765
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I96be984cbefeb8e45bf49de4c50a225a46fbefb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120089
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I020e6e74f800e58bee71674d2219a89c40a70eda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119930
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
since...
commit a0656ec6fc2b41e65f1b40dbd64f546175e2762f
Date: Thu Mar 25 09:53:33 2021 +0300
const OUString -> const OUStringLiteral
Mostly automated rewrite
Change-Id: Ia5e24f7c5ed9e4608c264435463c60f417c2c915
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113082
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Mostly automated rewrite
Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
because of the side effects
using a bare GtkGrid as m_pSocket in vcl/unx/gtk3/gtk3gtkobject.cxx
is perhaps a poor choice, getting its xid causes poor side effects
wrt events belonging to its child widgets getting delivered to
the SalFrame widget, so duplicate scrolling after showing a opengl
slide and/or showing a video and lots of flickering
we're (generally at least) not using the xid under gtk3 so don't set it
unless it's explicitly asked for. Happily the gtk Player::createPlayerWindow
doesn't use its arg[0] xid in any case, so don't bother setting it for
that backend.
Change-Id: I1c59a607a332635091782c3b49de10647558f301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109941
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3a49a184f06e7d78a461c3a868de8054aa7069bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109954
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
068f244222edcc5916fe864a0265ab6ccb4e43d2 "gtk3_kde5: port away from
boost::process" had introduced this as
return OUString::fromUtf8(OString(ret.c_str(), ret.size()));
(so would have preserved embedded NUL characters in ret, even if such should not
exist in a pathname anyway and this form was likely not chosen over the shorter
return OUString::fromUtf8(OString(ret.c_str()));
with the intention of preserving embedded NULs).
Then ec3aee0ef36f1ec3848581009b0de01e0ffd5e8f "Fix build with older versions of
Boost" replaced that with
return OUString::fromUtf8(OString(ret.c_str(), strlen(ret.c_str())));
which has the exact opposite effect of cutting at the first embedded NUL (which,
again, was likely not the motivation for choosing this form).
Change-Id: Ic2d432907bce38a0314a0556a9540d08cdc42929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107443
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Also recheck vcl/source after recent reworks and f-u-i updates.
Some new blacklist entries were needed for keeping existing
fw declarations in headers.
Add blacklist entries for removals causing no-pch build failures
that were reverted in:
a3b03ba1316b1ec0a9b0a3b45b96dc0a49aa9f1f
75d924db95559cff5f699bad8fe34bb0aeac0ff6
b57052ec2bbe548ca495a32b4bfce1d1c71caf33
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I71227806288b68ef2a2cd56244899fd56bd0db8d
Reviewed-on: https://gerrit.libreoffice.org/81163
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In some observed cases, 100 ms were not enough for the separate
'lo_kde5filepicker' process to terminate properly, in particular
on slow or busy hardware.
Drop the timeout here and just wait for the process to finish
to avoid killing it unnecessarily, which could e.g. lead to file
dialog settings/state not properly being saved by the native KDE
Plasma QFileDialog (plasma-integration, e.g. in
'KDEPlatformFileDialogHelper::saveSize'), so that the last
used mode or size would not be remembered.
The assumption is that the separate fpicker process should now
properly finish in all cases, in particular since commit
93815c2b04f1905e43c695caf5cc2c594bb897ce.
Should that assumption not hold, let's rather fix the underlying
issues than increasing the timeout here.
Change-Id: I0a58c1425940fbfaecb5012a24fd9a0222cbaccb
Reviewed-on: https://gerrit.libreoffice.org/70834
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: Ic5fa7c703821c23e704d2c58f9a04d0ac8ce8ef2
Reviewed-on: https://gerrit.libreoffice.org/69308
Tested-by: Tomáš Chvátal <tchvatal@suse.cz>
Tested-by: Jenkins
Reviewed-by: Tomáš Chvátal <tchvatal@suse.cz>
|
|
Change-Id: Id096bd25cd6df5941eaec45f7573f5887ae51d79
|
|
This introduces a new thread that takes care of handling the IPC
command and result for executing the file picker
('Commands::Execute'), which is the only command in the file
picker that may block for a longer time until it receives its
result from the kde5 side (namely, when the dialog has been
closed).
While the file dialog is being executed, activate a dummy GTK dialog
that also takes care of handling events in its main loop as long
as the file dialog is shown. The dummy dialog is closed together
with the KDE file dialog.
(Since the actual KDE file dialog is run as a separate process,
this one is mostly "transparent" to the soffice process from the
point of view of a dialog.)
This allows dropping the custom event processing previously done
in 'Gtk3KDE5FilePickerIpc::readResponse()' that had the potential
to cause all kinds of problems, e.g. when another event related to
the file picker was triggered from a Java process via UNO.
Change-Id: I3d663253f09320f7a8e0d9ec32a8fd6ec191c189
Reviewed-on: https://gerrit.libreoffice.org/61253
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Since 'string::find()' returns the position of the given
character in the string and that was passed as the amount of
characters to delete from the string, 'm_responseBuffer'
would always be a string starting with a newline character
afterwards, when this part of the code was reached.
Subsequent calls to 'Gtk3KDE5FilePickerIpc::readResponseLine'
therefore always returned an empty string and left
'm_responseBuffer' unchanged, resulting in the lambda function
inside 'readResponse' in 'gtk3_kde5_filepicker_ipc.hxx' to
loop infinitely.
While at it, make a little more explicit that 'it' is of type
'size_t' here.
Change-Id: I3b1c209f8307ab71465d9538a82616dff8656415
Reviewed-on: https://gerrit.libreoffice.org/60047
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
While this uglifies the code, it removes a dependency on newer
boost 1.64+ which ships boost::process. This helps on systems
where LO is linked against system boost and an older version
of boost is used.
Additionally, and this is the main motivation, this makes it
easier to backport these changes to 5.2, where the bundled boost
is also only at 1.60.
To keep the required changes at a minimum, the osl_* API for
reading from/writing to the stdout/stdin of the helper process,
we buffer the responses on a line-by-line basis. Note that one
cannot simply reuse osl_readLine on the non-seekable oslFileHandle.
Instead, we have to roll our own simplistic readLine implementation...
Change-Id: I1197e38cb2416e926d8ba985accd6c10d78bcc52
Reviewed-on: https://gerrit.libreoffice.org/48490
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Ic12464f01950a5037bb6819a2722aba5a7e3e2e6
|
|
This is a hybrid plugin which mostly wraps the GTK3 vclplug. Only
the file and folder picker are replaced by KDE dialogs. This gives
us a well-maintained GTK LO base with basic KDE integration with
minimum effort.
To prevent issues with nested event loops, the KDE dialogs are
launched from a separate process, the new lo_kde5filepicker helper
executable. A trivial stdin/stdout IPC mechanism transfers the data
between LO and the Qt/KDE helper. The usage of an external process
also allows us to copy'n'paste between LO and the KDE file dialog
without freezing the UI, as would happen when one would do this
in-process. This is in general also the architecture applied by the
kmozillahelper, which is used to integrate KDE file dialogs into
Firefox.
While the KDE dialog is shown, the GTK3 main window is disabled and
close requests are ignored. The KDE dialog in turn also sets the LO
window as transient parent. Together, this makes the illusion perfect
and the KDE dialog behaves like a modal dialog. This works properly
also with multiple LO main windows, and only individual windows will
get blocked as one would expect.
Functionality wise, most of the features of the KDE4 dialog are
supported. You can pick files and folders, and save files under a new
name. Some custom checkbox widgets are supported, but lists, buttons
and preview widgets are not yet implemented. Also, loading remote
files via KIO is not possible yet.
Change-Id: I1a97cf7c272307a19ace4222d5f12253bc722829
Reviewed-on: https://gerrit.libreoffice.org/47718
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|