# EditorConfig: http://EditorConfig.org # top-most EditorConfig file root = true # General settings [*] end_of_line = lf insert_final_newline = true charset = utf-8 trim_trailing_whitespace = true # Source code files [*.{c,cxx,cpp,h,hxx,hpp,java,py}] indent_style = space indent_size = 4 # Makefiles [{Makefile,*.mk}] indent_style = tab trim_trailing_whitespace = false # Patch files [*.patch.*] trim_trailing_whitespace = false pan='2'>cgit logo index : lo/core
LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/vcl/unx/gtk3_kde5/gtk3_kde5_filepicker_ipc.cxx
AgeCommit message (Collapse)Author
2023-10-15Repurpose loplugin:stringstatic for O[U]String vars that can be constexprStephan Bergmann
...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>
2022-03-11tdf#114150: Remove duplication of strings found in file dialogsJulien Nabet
Change-Id: I86f720a23dd9d400d39d9606e073b483850a9df2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131153 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-05fix --enable-gtk3-kde5 buildCaolán McNamara
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>
2021-08-06drop intermediate vcl::Window from Application::GetDefDialogParentCaolán McNamara
Change-Id: I96be984cbefeb8e45bf49de4c50a225a46fbefb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120089 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-03fix enable-gtk3-kde5 buildCaolán McNamara
Change-Id: I020e6e74f800e58bee71674d2219a89c40a70eda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119930 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-03-25fix gtk3_kde5 buildCaolán McNamara
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>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
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>
2021-01-27tdf#139609 avoid fetching unnecessary xid under gtk3Caolán McNamara
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>
2021-01-26fix --enable-gtk3-kde5 buildCaolán McNamara
Change-Id: I3a49a184f06e7d78a461c3a868de8054aa7069bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109954 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...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>
2020-12-08Remove redundant strlen callStephan Bergmann
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>
2019-10-25tdf#42949 Fix IWYU warnings in vcl/unx/gtk3 and gtk3_kde5/Gabor Kelemen
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>
2019-04-17gtk3_kde5: No longer kill fpicker process on timeoutMichael Weghorn
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>
2019-03-15Fix build with older versions of BoostTomáš Chvátal
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>
2018-10-08loplugin:external (--enable-gtk3-kde5)Stephan Bergmann
Change-Id: Id096bd25cd6df5941eaec45f7573f5887ae51d79
2018-10-08tdf#120261 gtk3_kde5: Leave event handling on gtk3 side to gtkMichael Weghorn
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>
2018-09-06tdf#119685 Fix infinite loop in gtk3_kde5 filepickerMichael Weghorn
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>
2018-01-25gtk3_kde5: port away from boost::processMilian Wolff
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>
2018-01-23Various loplugin in --enable-gtk3-kde5 codeStephan Bergmann
Change-Id: Ic12464f01950a5037bb6819a2722aba5a7e3e2e6
2018-01-23Introduce gtk3_kde5 vcl pluginMilian Wolff
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>