summaryrefslogtreecommitdiff
path: root/vcl/qt5/Qt5Frame.cxx
AgeCommit message (Collapse)Author
2021-08-01Fix typosAndrea Gelmini
Change-Id: Ib48f6c8e0424e6843d2b3a7b3558d1d8714a80ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119792 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-30tdf#143580 Qt5 don't use Qt::Popup for FLOAT winsJan-Marek Glogowski
Main problem is, that Qt::Popup grabs the focus and therefore generates a focus-out event for the combobox, which then closes the just shown popup window. The grab happens inside QWidget private code and there is no way around it. But instead of "faking" Qt::Tooltip, this uses Qt::Widget with additional flags. Regression from commit 7e6fee830116823b9cd8e46d6962df4ea2bc1ea6 ("Qt5 fix Qt::Popup window handling"). Change-Id: Ia1f8e33d98f7ec36cf1ebc350886121dfaadd658 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119691 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-07-20Qt5 fix Qt::Popup window handlingJan-Marek Glogowski
I guess to get popup windows somehow working, they were matched to Qt::ToolTip. Fixing that by removing SalFrameStyleFlags::FLOAT from the tooltip check, resulted in rather bizarre bahviour. The Qt::Popup window is modal, as documented, but wouldn't close when clicked outside, like normal popups. And I neither got any mouse button or focus events, just some leave or enter. The only way to interact with anything again, was by clicking somewhere on the popup where it can't take focus... and it has nothing to do with the transition setting either. In the end it turned out that Qt::StrongFocus prevented the mouse events to happen. Even without it the widget accepts mouse and keyboard focus, so nothing seems lost by omitting that for the Qt::Popup case; hopefully... Change-Id: Icda7bbe87268293a400fe0da551d2804675d4c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119236 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-07-20tdf#143298 Qt5 send SalEvent::KeyModChange eventsJan-Marek Glogowski
I originally omitted this in the Qt implementation, as I couldn't find any non-working use case. The implementation got a bit hacky, because Qt doesn't have a non- native way to identify different L/R modifier keys, so we must process the X11/xkb keycode ourself, which obviously won't work on Wayland... but most times this is not relevant, so the default modifier notification may be good enough. P.S. it's basically the same code then X11 and Gtk... Change-Id: I37fbfde4a33a966b6017f3e0c280e2c7ea91e4db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119235 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-07-20tdf#143334 Qt5 don't reset buffer on style changeJan-Marek Glogowski
This bug was "unveiled" by commit 963f252cd1ea9c268a6ced68a3454b10cbee1a89 ("Qt5/KF5 get rid of unneeded own grahics handling"). I'm not sure why I ever came up with that code. Eventually we would need a paint event, but at least changing the theme correctly updated LO UI, so that seems to be handled correctly. Change-Id: I528b551180be184427eeeeeb2977e2b7da073ce6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119237 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-06-10loplugin:unnecessaryreturn SalFrame::SetPluginParentNoel Grandin
Change-Id: If927a834f5b5d722fc36cce40e161597af6234ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116972 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-15Qt5 correctly focus the navigator windowJan-Marek Glogowski
Handle SalFrame::Show's bNoActivate. The missing implementation became visible with commit 001cf630f14109b4200b218161418350562713fa ("register navigator individually in each module that it exists in") Change-Id: I5edf43bdf2b0460410fdd846c7698d00299088bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114116 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-04-11Qt5/KF5 get rid of unneeded own grahics handlingJan-Marek Glogowski
This was hiding tdf#141623, when I decided to implement the override to run the kf5 VCL plugin with the qfont text rendering. Change-Id: Id1fcd363bd77a756cb27e3a171c872ce792da5ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113956 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-04-11tdf#141623 Qt5+cairo init surface with widget sizeJan-Marek Glogowski
The QFont based rendering path directly uses the widgets size to initialize the QImage buffer image, so do the same for the Cairo surface, instead of the arbitrarily size of 640x480. Change-Id: I91326dab67cbbb5e75b78b02c34eaca61ad26482 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113955 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-02-24don't need to include vcl/layout.hxx in qt5Caolán McNamara
Change-Id: I8e08c4e5c5b92df4cbdb8ea32f40dbde25f7afd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111433 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-26use an accessor for SystemEnvData::aWindowCaolán McNamara
with an eye to making it on-demand Change-Id: If6cefd68a336dc6afe23591c857bd71034215b54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109929 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-11-22Qt5 report input method languageJan-Marek Glogowski
This is in the spirit of tdf#108151, based on the information Qt provides for the IM setting. I don't know how correct it is, especially looking at Caolans comment 3 in that bug report regarding the assumed validity of GtkIMContextInfo. OTOH it seems to work well enough for my simple tests. Some BG info: while the QInputMethod object is a global one, it's "bound" to the focused window. So you'll get change events, when you change the input window, with the correct IM settings for the new one, be it a real window or just the menu bar. To prevent unneeded flushes of buffers and language lookup, this caches the current IM language of a window. The language is not affected just by changing keyboard mappings, which the bug reporter requested! It just works with a configured input method, like fcitx or ibus (which can have keyboard mappings too, which work correctly). Change-Id: Ia9133edf4d1ce77d29adbfe57c180db15db0a560 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106354 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-11-04loplugin:unusedmethodsNoel
Change-Id: I58fb6477222a26455f5db0a7d972c46f290c085c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105261 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-03loplugin:unusedfieldsNoel
Change-Id: Ia8e2a7ce75bfded98e85fa583d1404710069d335 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105249 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-27tdf#136555 apply window bg color for button boxesJan-Marek Glogowski
The default background color of the frame is APPBACKGROUND, which is matched to GetWorkspaceColor(). That color is visible in Writer as the default document workspace background. Originally I just saw the dark background of the button box in the start center, and thought the workspace color in Qt is wrong and changed it in the reverted commit, missing the change of the color around the Writer document. Now that the button boxes's background color isn't fixed via the "branding" setting, we also must react to changed style settings, so we override the DataChanged function. This also reverts commit e0c72e31c1d455c26110c35e8780d420e17cdea6. Regressed-by: a927e0964ba0442d53fffb22c577e54bcf183ed7 Change-Id: I62396355054523baef1197a8a8af61c2f0d29ef3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104740 Tested-by: Jenkins Reviewed-by: Thorsten Wagner <thorsten.wagner.4@gmail.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-21Qt5 use base color for workspace tooJan-Marek Glogowski
This was uncovered by the fix for tdf#136555. The current color for the start center button bar is too dark. Regressed-by: a927e0964ba0442d53fffb22c577e54bcf183ed7 Change-Id: I36356117f03255cfbf1fa24a6391cb81cf1883db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104578 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-20tdf#133931 Qt5 set the themed AlternatingRowColorJan-Marek Glogowski
Change-Id: I6a4a0f90239686ff1c94e1a550540223324184e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104540 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-19use tools::Long in vclNoel
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-04loplugin:flatten in vclNoel Grandin
Change-Id: I271cc67ecf34acbf0edbda960e33315fb6a1f9dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100041 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-27tdf#135077 Qt5 revert broken fix for tdf#132172Jan-Marek Glogowski
So I tested a lot of stuff, but missed the missing focus for new dialog windows :-( This is IMHO a far worse problem, then the popup, so just revert the fix. This reverts commit 06fb3e7b7f1079c276ad2f048cd94299b4bd7006. Change-Id: I391ad91ded90e4518ab024572d3f182769b0bcda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99451 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-07-01tdf#132172 Qt5 just handle visible widget's focusJan-Marek Glogowski
I investigated the state of isWindow() and the SalFrameToTop flags for the detached find toolbar (tdf#126607) and the Impress presentation and the tabbed "page size" drop-down and all had the same status (isWin: 1, flags: 12). Than I had a look at the gtk3 implementation, which just handles focus requests, if the widget is already mapped (gtk_widget_get_mapped). So I also dumped the visibility as the nearest equivalent in Qt to the X11 mapped state, and that was different. In the end Qt now also just handles the focus for already visible widgets, like gtk3, which works for all the cases I tested (incl. tdf#125517). And omiting either activateWindow or setFocus breaks some cases... and I still don't understand the GrabFocusOnly flag, which is just handled in the X11 backends at all... Note: this doesn't happen with 7.0+, because the weld'ed version of that control (commit 3afc718eddcd81232392d46fccc24b8ec626c8df "rework PageSizePopup to be a PopupWindowController") doesn't expose this bug (and also doesn't support mouse-over highlight). Change-Id: Id085732f6a52bbc69ed47fbd3d57454756a03121 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97549 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-06-24tdf#127138: Fix detection of system icon theme with Qt5/KF5Igor Poboiko
The title is self-explanatory. The QIcon::themeName() actually uses Qt Platform Abstraction plugins, i.e. it's aware of KDE preferred icon theme via Qt Plasma integration module. (note that it is _currently_ broken due to KDE bug https://bugs.kde.org/show_bug.cgi?id=402172, which causes themeName to return empty string; however, it's being worked on) Change-Id: Ibc7cf9ee9ae73b492046219487760561d7d2ea45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94691 Tested-by: Jenkins Reviewed-by: Katarina Behrens <bubli@bubli.org>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-09tdf#127687 Qt5 introduce basic HiDPI scalingLuca Carlon
For tdf#124292, Qt's own HiDPI scaling was explicitly disabled, but it turns out, you can't really scale QStyle painting then. This patch series had a 2nd approach also used by Gtk+ currently, which relied on the scaling of ths Cairo surface, which works surprisingly good, but has to lie about the real DPI value, so nothing is scaled twice. Also all icons are then scaled instead of rendered with the proper resolution. When HiDPI support in Qt is enabled, and the application is started using QT_SCALE_FACTOR=1.25, Qt simply lowers the reported resolution, keeps the logical DPI value of 96 and changes the devicePixelRatio to the specified value. But LO still expects the real DPI values and sizes, so we have to multiply a lot of rectangles, sizes and positions. The current result is far from perfect, which you can see with the various graphics glitches, but it at least doesn't crash anymore in the ControlType::Editbox sizing code. The main problem is all the up and downscaling in the getNativeControlRegion code, so LO knows the size of the widgets for the correct layouting, since there seem to be no API to get the scaled values from Qt / QStyle. Change-Id: I687b1df6ef27724ce68326d256e9addccd72e759 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86239 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-03-06tdf#125532: White text on default/action buttons and selected tabs on macOSThorsten Wagner
Change-Id: I58ce75e711504553c8fc606382866754286f1aa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-03-02Qt5 some refactoring for HiDPI mergeJan-Marek Glogowski
This is a preparatory patch for merging the initial fix for tdf#127687, the Qt5 HiDPI scaling support, and generally to make the style handling code a little bit more readable. It includes: * Moving all lcl_ Qt5Graphics_Controls functions into the class as private functions without lcl_ prefix. * Add three additional helpers - pixelMetric, sizeFromContents and subControlRect - to cut down boilerplate QApplication::style()-> prefixes for the style calls everywhere. * Drop the superfluous Qt5Frame::TriggerPaintEvent functions. * Drop the single, broken maGeometry.nTopDecoration filling. * Split some very long lines of nested call code by using some intermediate variables. * Move a Qt5Data include from hxx into cpp Change-Id: Iae1bfafd14c4163447f3d55e2307f0f617e68a0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89751 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-02-22tdf#130827 Qt5 report frame-relative cursor posJan-Marek Glogowski
Qt5Frame::GetPointerState expects the cursor position relative to the frame position. Change-Id: Icaf7dcd8fc80d712f5138a9f9b843ccf345c5543 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89244 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-13Silence -Werror,-Wdeprecated-declarations for nowStephan Bergmann
...as seen with qt5-qtbase-devel-5.13.2-1.fc31.x86_64: > vcl/qt5/Qt5Frame.cxx:481:73: error: 'screenGeometry' is deprecated: Use QGuiApplication::screens() [-Werror,-Wdeprecated-declarations] > toSize(pScreen ? pScreen->size() : QApplication::desktop()->screenGeometry(0).size())); > ^ > /usr/include/qt5/QtWidgets/qdesktopwidget.h:79:5: note: 'screenGeometry' has been explicitly marked deprecated here > QT_DEPRECATED_X("Use QGuiApplication::screens()") const QRect screenGeometry(int screen = -1) const; > ^ [...] > vcl/qt5/Qt5Frame.cxx:490:56: error: 'screenNumber' is deprecated: Use QGuiApplication::screenAt() [-Werror,-Wdeprecated-declarations] > int nLeftScreen = QApplication::desktop()->screenNumber(QPoint(0, 0)); > ^ > /usr/include/qt5/QtWidgets/qdesktopwidget.h:75:5: note: 'screenNumber' has been explicitly marked deprecated here > QT_DEPRECATED_X("Use QGuiApplication::screenAt()") int screenNumber(const QPoint &) const; > ^ [...] Change-Id: I7db00ee0e7cd7f652af4f7426f9ea0172206d485 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86660 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-07Avoid loplugin:staticmethodsStephan Bergmann
Change-Id: I93ebdcae5c39566660edbe1d5e76cc548f5b7c49 Reviewed-on: https://gerrit.libreoffice.org/84670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUPJan-Marek Glogowski
This is the application level equivalent of the Qt5 fix for bug QTBUG-46626 / commit 0de4b32 ("xcb: fix issue with dialogs hidden by other windows"), which was broken since Qt 5.4 and is just fixed since Qt 5.12. It is needed for some window managers, which don't know about the WM_CLIENT_LEADER property. Both settings are the same, but just the latter is set by older Qt5 releases. This probably isn't a real problem, as GNOME or XFCE would use the gtk VCL plugin, but since I already wrote the code when debugging tdf#129071, there is also no reason to drop it (except: more code, more bugs...). This fix is optional and needs development headers for xcb-icccm, which can actually be compiled into Qt5. If missing configure will just print a warning, since it's a runtime requirement and we explicitly drop the linked Qt version symbol, so the potential build Qt version won't matter. Change-Id: Ifc5a8f8a40ee13779a911efb53e8b8b868614d0b Reviewed-on: https://gerrit.libreoffice.org/84299 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-12-06tdf#129071 Qt5 handle windows with parents as dialogsJan-Marek Glogowski
This is the main fix for this bug. Qt Xcb is a little picky here. It won't tell the window manager about the transient state, using WM_TRANSIENT_FOR, for all Qt::WindowTypes. The QPA internal list (see isTransient function) doesn't include the Qt::Window, which is qt5 VCL's primary used window type. This has two consequences: 1. LO dialogs show up in the plasma task manager as seperate windows. 2. LO has to handle the transient state itself, instead of relying on the window manager. This results in flickering, because LO can just push a transient window to the top again, after the parent window was activated and therefore drawn in front. So this just declares all windows with parents to be dialogs. Almost everything else should be a top-level window anyway. If not, there is SalFrameStyleFlags::DIALOG to create a parent-less dialog window. Change-Id: I89a6d46fd09e4f1d1d2904e152a26733eb266079 Reviewed-on: https://gerrit.libreoffice.org/84298 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-01boost::optional: replace uses of get_value_or with value_orStephan Bergmann
...in preparation for wholesale replacement of boost::optional with o3tl::optional, which will be an alias for either std::optional or boost::optional, and std::optional only has value_or. boost::optional::value_or was added with <https://github.com/boostorg/optional/ commit/3984c9f9a157ef116cea69bc8bb20f433320eb61> "Added function value_or()", which according to git-describe first appeared in tag boost-1.56.0. We appear to have no strict Boost baseline (the closest we get is with > [AC_MSG_ERROR(boost/spirit/include/classic_core.hpp not found. install boost >= 1.36)] in configure.ac), and at least CentOS 7 TDF machine tb76 only has boost-devel-1.53.0-27.el7.x86_64. However, any environment using Xcode < 10 that needs to make o3tl::optional fall back to boost::optional should use --without-system-boost, and external/boost is currently at 1.69.0, so should be safe. ATTENTION: In isolation, this commit will break in any environment that uses Boost older than 1.56.0. It requires the following commit introducing o3tl::optional. (But doing these changes in individual commits was deemed more valuable than supporting a hypothetical future git-bisect against an old Boost.) Change-Id: Ib31affa3eebf0d0029d8620dc6abb7a60f6c7629 Reviewed-on: https://gerrit.libreoffice.org/84127 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26tdf#126607 Qt5 activate window before setFocusJan-Marek Glogowski
.., and prevent Qt5MainWindow to take any focus. Our top level Qt5MainWindow shouldn't handle focus directly, as it's always completely drawn by the child Qt5Widget, which also handles input. So prevent any direct focus handling by setting the Qt5Widget as the focus proxy of the Qt5MainWindow. Also setting the focus of the child widget on its own seems to do nothing at all. At least I didn't see any difference after commenting the code block. But it at least has some effect, if you call setFocus on the real window, but that breaks Impress full screen mode, which somehow gets scroll bars?! Not that I understand why this is needed. At least the original X11 code just calls XSetInputFocus in this case. Change-Id: I591c031a17a7ae0b5486760cd1802522d4088678 Reviewed-on: https://gerrit.libreoffice.org/83689 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-10Set action button colors in QT5 backend tooTomaž Vajngerl
Change-Id: I8aacadbef404cdad474a58d92b947fea2aa22604 Reviewed-on: https://gerrit.libreoffice.org/82384 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2019-10-06Replace SystemEnvData pToolkit/pPlatformName strings with enumsStephan Bergmann
(and streamline those data members' names) Change-Id: Ifdd596c7a54dd507045d412c30b463468c2f798b Reviewed-on: https://gerrit.libreoffice.org/80313 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-06SystemEnvData::nSize is no longer read and can be removedStephan Bergmann
...since 5926b22b5dc33490d23d594b129eb8a70b94ffb0 "The SystemEnvData passed into the canvas factories appears to be unused". (And the user-provided SvpSalObject ctor can be removed, at which point the use in SvpSalInstance::CreateObject should be written without "()" to avoid loplugin:subtlezeroinit. Change-Id: I4392fa2d697b29c814d7b577a7b1f8c984c05e70 Reviewed-on: https://gerrit.libreoffice.org/80298 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-23Qt5 some minor code cleanupsJan-Marek Glogowski
Change-Id: I1ee81de7ef03447991e12dcf01aef7858408dc40 Reviewed-on: https://gerrit.libreoffice.org/77975 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-08-22tdf#126560 Qt5 fix D'n'D key-modifier handlingJan-Marek Glogowski
The patch has still one problem: the key-modifier state isn't reflected by the cursor, unless the user moves the mouse. There is an upstream Qt bug, reported in 2016-09 against Qt 5.6.1! It is supposed to be fixed in Qt 5.12, according to the bug report at https://bugreports.qt.io/browse/QTBUG-56218, which is still open. I thought about adding a configure test, but I couldn't imagine any realistic way to write it. And after Michael Weghorn found the bug is actually not fixed, as claimed in one of the comments, I decided to drop the warning. Change-Id: Ice8ebc4ea149282b4c1551e755efe3d4856cf782 Reviewed-on: https://gerrit.libreoffice.org/77174 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-21tdf#125922 rename kde5 to kf5 + plasma5Jan-Marek Glogowski
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as it is based on the KDE frameworks 5 libraries. This also includes: * a convenience alias to load the kf5 VCL plugin in case someone requests the kde5 plugin. * keep convenience kde5 configure switch, but warn about it * rename detected desktop from kde5 to plasma5 Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735 Reviewed-on: https://gerrit.libreoffice.org/75313 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-24Qt5 don't assert broken height or widthJan-Marek Glogowski
At least maths element docking window has a floating height of zero. So the original gtk comment about broken values is still true. And the initial SalFrameGeometry is ok, so no need to initialize it. And set default size and position on show, if not explicitly set. Change-Id: Ibe4969a164b50b666745ce010f5100af4b3ff2f6 Reviewed-on: https://gerrit.libreoffice.org/74614 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-23Fix typoAndrea Gelmini
Change-Id: I357c004e724ebe580a121bf7ecdc63da9c02343f Reviewed-on: https://gerrit.libreoffice.org/74593 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-22Qt5 directly show tooltips + respect the help areaJan-Marek Glogowski
I'm not sure why this redirection was implemented, which also ommited the provided help area. I tried hard to use vc::Window code in the beginning, but that also mirrors the cursor position for the window. Using Qt here is simply straight forward, so just do that, Change-Id: Ia8c4efc1e43b915c4b071ee26d4da37d7580817c Reviewed-on: https://gerrit.libreoffice.org/74548 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-22tdf#123779 Qt5 correctly fill Qt5Frame::maGeometryJan-Marek Glogowski
The tooltip in the bug is actually not one, but the VCL implementation of Gtk's popover widget triggered by SalFrame::ShowPopover. This has no Qt equivalent, so we currently rely on the crude VCL version. But for this maGeometry must contain the correct information, AKA the absolute, unmirrored, paintable system geometry of the frame. Then the window can be positioned correctly. The patch gets rid of most of the code initially copied from gtk, when this VCL backend was in a very early state. Change-Id: Id44e4dc2aac41f1f01d51c4d8107892e644ef243 Reviewed-on: https://gerrit.libreoffice.org/74546 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-15Fix typoAndrea Gelmini
Change-Id: I27a00608a5dba9fc467c61d5919233972b293811 Reviewed-on: https://gerrit.libreoffice.org/74093 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-06-15Qt5 move and init static m_ActiveDragSourceJan-Marek Glogowski
Change-Id: Iab82151b8d1a8281c9999983b9de5f35dfb0442e Reviewed-on: https://gerrit.libreoffice.org/74013 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-15tdf#125921 Qt5 set WM_CLASS for top level windowsJan-Marek Glogowski
Uses the same naming then the gtk3 backend, i.e. "libreoffice" for the instance name and different class names for the module windows, like "libreoffice-writer". These names are referenced in the desktop files a StartupWMClass and for example used to pin an app to the task bar. Change-Id: Ic9b8890536f6413ab59d2e0da866e2280ab3181a Reviewed-on: https://gerrit.libreoffice.org/74014 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-14KDE5 move screensafer inhibiting code into Qt5Jan-Marek Glogowski
There will presumably be more X11 specific code later to implement some "fix" for tdf#119202. Moving the screensafer inhibitor is rather uncontroversial in comparion, so start with it and use it to carry the matching configure.ac changes. A little "nightmare" are all the clashing X11 / Qt type undefs, but I couldn't find a better solution while the inhibitor continues to include the X11 headers in it's header. Change-Id: I55c89c76726d30a890178488484e954207267e89 Reviewed-on: https://gerrit.libreoffice.org/74015 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>