summaryrefslogtreecommitdiff
path: root/vcl/qt5
AgeCommit message (Collapse)Author
2020-09-09tdf#136323 qt5: Remember accessible objectMichael Weghorn
'QAccessibleCache::insert' from the Qt library has a 'Q_ASSERT' checking that the corresponding 'QObject' for which the 'QAccessibleInterface' provides information is actually the same as the object passed as a parameter: QAccessible::Id QAccessibleCache::insert(QObject *object, QAccessibleInterface *iface) const { // ... QObject *obj = iface->object(); -> Q_ASSERT(object == obj); However, 'Qt5AccessibleWidget::object' so far was always returning 'nullptr', triggering this assert when using a Qt version not built with 'QT_NO_DEBUG'. To fix this, remember and return the object as needed. Change-Id: I4015b4c37aa8a073b02465df580a7235884e6cf3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102196 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 4461d49c6cfce22c2c96185b0a1d07bfe9709268) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102126 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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 14eccc62b53e202cd9ed63442481922a320fc02e. Change-Id: I391ad91ded90e4518ab024572d3f182769b0bcda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99453 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-07-04tdf#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> (cherry picked from commit 06fb3e7b7f1079c276ad2f048cd94299b4bd7006) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97575
2020-07-03tdf#131991 Qt5 RTL mirror mouse wheel X positionJan-Marek Glogowski
Just like all the other events, the mouse wheels X position must be mirrord in LO RTL mode. Change-Id: I28e8da0455d941f42f869b08edcdbe570de366c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97338 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 9eda78fd53fe3c76eb9d4b63add68f266f551b10) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97354 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97875 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2020-05-23tdf#130478 Enhance Dashed line drawing on all systemsArmin Le Grand (Collabora)
For more info and explanation including state of process information and discussion(s) see task please. Adding corrections for gerrit build Change-Id: Ie10fb8093a86459dee80db5ab4355b47e46c1f8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88130 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2020-04-20Qt5 implement DELETE_ITEMS action in file pickerAlexander Volkov
It is used to clear "Version" listbox before adding new items. Change-Id: I4cb9557c8f56d80c1dfac68dc2b5b45b5c69c2f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91982 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 3a22be0178b950ab3d21eadab2bc34e7ea93eec8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92174 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-03-31tdf#131533 Qt5 defer dropping clipboard ownershipJan-Marek Glogowski
This is maybe a Qt bug. Calling QClipboard::setMimeData from Qt5Clipboard::setContents after a previous call to QClipboard::clear results in a clipboard ownership failure. In a terminal you'll see: "QXcbClipboard::setMimeData: Cannot set X11 selection owner". Calling Application::Reschedule() after the clear() doesn't help. The result is a de-sync between the LO's clipboard state and the real clipboard state, which will lead to a crash on LO shutdown. I'm not sure this fix is correct. Maybe this could also be handled by some X11 flush operation. But it's the only working solution I could find: don't clear, if LO re-claims the ownership later. I tried to reproduce the ownership error by modifying the Qt fridgemagnets example, adding some QClipboard::clear and QClipboard::setMimeData calls to the drop handling, but couldn't reproduce. Maybe the dynamic Qt5MimeData object is also involved. Change-Id: I32b6575a78a4b10a2e2b7b189303ab3a40dc69ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90990 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 313081c0703c66918e95640c74cd57312a1e8bba) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90963
2020-03-04Qt5 unify font attribute conversionsJan-Marek Glogowski
Adds conversion functions for VCLs FontWeight, FontWidth and FontItalic to Qt5FontFace and remove the partial "switch" tables from KF5SalFrame. And correctly handle the FontWidth in Qt5Font as the stretch value, so the default font in qt5 gets the correct stretch and doesn't look bold. Also contains commit b9a124aae67cbd64917f07f2dca6603f149c018b ("Qt5 just ignore invalid font attributes"). This ignores the *_DONTKNOW and _FORCE_EQUAL_SIZE values, except for the stretch, where we map DONTKNOW to QFont::AnyStretch. Change-Id: I698986416dff13e6dfaf9dfa7f95851b89e9137d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89813 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 63ea1e811a3b3806b6b2408d759a449f4e086eb3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89797 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-28tdf#130071 tdf#127815 qt5: Use ExtTextInput only for multi-char key eventsMichael Weghorn
Only call the SalEvent::ExtTextInput callback for key input events if their text is longer than one character, in which case treating them as SalEvent::KeyInput would produce incorrect results, given that only the first character is set as the SalKeyEvent's mnCharCode below (s.a. tdf#124118). S.a. commit 61c8324394c690ced18ce692ab6d29c8031ad1a8 ("#88063# fixed event handling for redflag", 2001-06-12) which made events with text longer than 1 unicode char to be handled by SalEvent::ExtTextInput for the gen VCL plugin even if not in preedit mode. Process other key events by calling SalEvent::KeyInput callback, which e.g. makes shortcuts involving non-Latin characters (tdf#130071) and auto-insertion of non-breaking spaces when typing French text (tdf#127815) work. The gtk3 and gen VCL plugins also use the length of the text as one criterion to make a disctinction of whether to call SalEvent::ExtTextInput or SalEvent::KeyInput, s. GtkSalFrame::IMHandler::signalIMCommit and X11SalFrame::HandleKeyEvent. Those also take into account whether in preedit mode, but for the qt5 case, input method events when using e.g. ibus are handled in Qt5Widget::inputMethodEvent and the Qt5Widget::handleKeyEvent code path is not used anyway. Change-Id: I2f8925ea26a4fb5419226265c579242889e2a506 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89663 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins (cherry picked from commit 1c6ea413cb01c0b482f87e625ba208eec230618a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89670 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
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> (cherry picked from commit 4fe30879af391c32074a003a7a6ddd45431d212a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89268 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-22tdf#130831 Qt5 don't blit damage to empty imageJan-Marek Glogowski
This prevents the crash, but I'm not sure having an empty buffer image at this point is correct. But it doesn't look like anything is missing in the dialog and a crash is definitly worse. Change-Id: I7d0330b4e4a7ca64655a51c226e425e53ba12118 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89203 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 813cde918338bccc4f711230616340cad2c1d4a0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89140 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-22tdf#130499 Qt5 no qApp == main threadJan-Marek Glogowski
If there is no QApplication, we can ignore the GUI thread. Change-Id: I0d2faf4799d493ad0b6074b40242c443d4bc43dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89241 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit c6fb366e05370af553af2130b370909ed4495cff) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89141 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-02-20tdf#130794 qt5: Actually, ignore non-spontaneous QEvent::ShortcutOverrideMichael Weghorn
In fact, the assumption in commit 034f56015c1c7a61faede33fb5306f63b5585632 ("tdf#126785 qt5: Ignore external QEvent::ShortcutOverride") was a fallacy and it's exactly the other way around: "Normal" typing leads to "spontaneous" events of type QEvent::ShortcutOverride, since those originate from outside, are triggered via X11 events or Wayland equivalent, and the non-spontaneous ones are the additional ones that happen when e.g. the Orca screen reader is enabled. In a short test, no non-spontaneous QEvent::ShortcutOverride ever occured when using LibreOffice a bit with Orca disabled on X11 or Wayland (and on Wayland also not with Orca enabled, since Qt accessibility is broken there, s. QTBUG-73945 [1]). (Side note: In a quick test with Qt 5.12.5 and Plasma on Wayland, 'xcbSourceDispatch' from Qt library's qxcbeventdispatcher.cpp was also used in the Wayland case to when processing the keyboard events). [1] https://bugreports.qt.io/browse/QTBUG-73945 Change-Id: I1be1977e67f84fa657f6fc197e0b91822b6a3a2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89073 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 69e708868f6046cada955a16bca966370ce3218a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88960 Reviewed-by: Katarina Behrens <bubli@bubli.org>
2020-02-19tdf#128921 tdf#130341 tdf#122053 qt5: Native PopupMenusMichael Weghorn
This implements native PopupMenus for the qt5 VCL plugin, which not only gives them the native look and feel, but also makes context menus faster (tdf#128921), accessible (e.g. to the Orca screen reader, tdf#122053), and makes them work for a case in Base's relationship dialog where entries in the non-native context menu were not selectable/clickable (tdf#130341). For now, this always shows the popup menu at cursor position, which can be changed by taking the Rectangle passed to 'Qt5Menu::ShowNativePopupMenu' into account if there should be any need. Change-Id: Ie52cbc682acacb92716ff51e8bf7f1ab07d34cf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88512 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 1e0b16f8695498e4eea7c2208aabf7e7664ce749) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88491 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-02-18tdf#126785 qt5: Ignore external QEvent::ShortcutOverrideMichael Weghorn
For some reason, an extra external QEvent::ShortcutOverride event is triggered when a key is pressed and e.g. the Orca screen reader is enabled, which would result in duplicated input when handled as key input event as well. Therefore, ignore those ShortcutOverride events that are "spontaneous", i.e. "the event originated outside the application (a system event)". [1] [1] https://doc.qt.io/qt-5/qevent.html#spontaneous Change-Id: Ibccacb69c31d4d7ebd512c704f0e4df978c5281f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88852 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 034f56015c1c7a61faede33fb5306f63b5585632) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88790 Reviewed-by: Katarina Behrens <bubli@bubli.org>
2020-02-10tdf#129809 qt5: take a reference in case m_aContents is replacedMichael Weghorn
This takes over Caolán's solution for gtk3 from dbcdc5cd98df5756a96559e467cad95c629343ca ("tdf#129809 take a reference in case m_aContents is replaced") for the qt5 case as well, to prevent that the XTransferable is destroyed along with the Qt5MimeData object as new QMimeData are set in the clipboard, as follows: 1 Qt5Clipboard::setContents Qt5Clipboard.cxx 2 TransferableHelper::CopyToSelection transfer.cxx 3 TransferableHelper::CopyToSelection transfer.cxx 4 SwTransferable::CreateSelection swdtflvr.cxx 5 SwWrtShell::SttSelect select.cxx 6 SwWrtShell::SelectTextAttr move.cxx 7 SwTransferable::GetData swdtflvr.cxx 8 TransferableHelper::getTransferData2 transfer.cxx 9 TransferableHelper::getTransferData transfer.cxx 10 Qt5MimeData::retrieveData Qt5Transferable.cxx 11 QMimeDataPrivate::retrieveTypedData qvariant.h 12 QMimeData::data qmimedata.cpp 13 QInternalMimeData::renderDataHelper(QString const&, QMimeData const *) 14 ?? 15 ?? 16 ?? 17 QXcbConnection::handleXcbEvent(xcb_generic_event_t *) 18 QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) 19 ?? 20 g_main_context_dispatch Change-Id: Ic712c901a31131efc596cac7f00f14bb6a7ce068 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88192 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 1d7b1a15059a77fde9afa14d0b9a508142bfc247) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88258 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-12Qt5 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> (cherry picked from commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca) Reviewed-on: https://gerrit.libreoffice.org/84810
2019-12-09tdf#129071 Qt5 set file picker parent widgetJan-Marek Glogowski
If the XInitialization::initialize has a parent option, use that system window ID to find the parent Qt5Frame and set this as the parent of the file picker. This way the file picker doesn't show up as a separate window in the KDE task bar and get the proper icon. Just setting it transient to the parent is not enough. This also includes the terminate listener handling, so an open file picker won't prevent LO to shut down gracefully (which is handled independent from the document modified state). Change-Id: I62aef532e739e7fea9fe8a4b4e6c0e205faae1d9 Reviewed-on: https://gerrit.libreoffice.org/74544 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit d79a41a02cd46c50cab08ba1a5d5b213b6843251) Reviewed-on: https://gerrit.libreoffice.org/84756
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> (cherry picked from commit d8e3a08f06dcfea02c3f2f2a8578486381d77df7) Reviewed-on: https://gerrit.libreoffice.org/84619
2019-12-06Qt5 hide more Qt5FilePicker detailsJan-Marek Glogowski
* Make most members private * Drop some unused members * Rename some single-char variables for easier reading * Spread some constness * Finalize the KF5FilePicker class * Test the native picker setting of the QFilePicker, instead of an additional bool member This is just some refactoring. While not strictly needed, it helps keeping the following patches fixing tdf#129071 more compact. Change-Id: I15ffe4de848a9498d7f61f99bcf031257da7cb08 Reviewed-on: https://gerrit.libreoffice.org/84456 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit f33b6e915fdc29cff25cc93784a04df866ad6bc3) Reviewed-on: https://gerrit.libreoffice.org/84551 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-27tdf#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> (cherry picked from commit ec554ac30236fa7949e9866d01319d4e3e88c983) Reviewed-on: https://gerrit.libreoffice.org/83838 Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-11-19tdf#128434 correctly release fonts in destructorsJan-Marek Glogowski
This adds ReleaseFonts() calls to all destructors of SalGraphics and TextRenderImpl derivated classes, which implement SetFont. During destruction a base class can't call into derivated classes, as these are already destructed, so we have to spread these calls manually. Change-Id: Ia57db04f7df665e5205212ce512119e2f60e3379 Reviewed-on: https://gerrit.libreoffice.org/82967 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit f8e1f8652255cadd80a991aa3e059ee631b333b8) Reviewed-on: https://gerrit.libreoffice.org/83149
2019-11-15tdf#128710 Qt5 don't force immediate paint on showJan-Marek Glogowski
I tried to build a minimal reproducer with QMainWindow and a QDialog and miserably failed. All variants of show, hide, modal change, move, resize, processEvents(QEventLoop::AllEvents) just worked. I was able to produce "qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow) ... major code: 18 (ChangeProperty)" entries in my ~/.xsession-errors, but that didn't matter for my program. Then I started to comment code blocks in Qt5Frame and after that continued in Qt5Widget, found that ShowEvent produced a modal window, albeit with an obviously missing paint event. But that is fixable by just queuing one in LO. I tried to debug that broken behaviour to find the real cause of the bug, but as I already knew from commit e770bacc85a0 ("Qt5 workaround modal change after show bug"), this bug has some timing related component, so that sadly didn't result in any conclusion. Change-Id: Iaec45997179365fae5430120f86e435aa5e88447 Reviewed-on: https://gerrit.libreoffice.org/82745 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 5d23f7748f33414a95297fa9f374a37e76de687b) Reviewed-on: https://gerrit.libreoffice.org/82805
2019-11-13tdf#123851 Qt5 handle broken ScrollBar valueslibreoffice-6-4-branch-pointJan-Marek Glogowski
If the scrollbar has a mnMin == 0 and mnMax == 0 then nVisibleSize is set to -1?! I don't know if a negative nVisibleSize makes any sense, so this just handles this case without crashing LO with a SIGFPE in the Qt library. If min == max then the visible size is just zero. It's actually not clear, that this crash is the same then the bug report, but it fixes at least the later reproducer crash. Change-Id: Ib2dd51ddecfd24ddf2d89f746cbc8975269e13da Reviewed-on: https://gerrit.libreoffice.org/82600 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
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-08loplugin:redundantpointerops simplify *p.get()Noel Grandin
Change-Id: I12517651fb3f777fd08e384992bb3e84b340ad85 Reviewed-on: https://gerrit.libreoffice.org/80382 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-07tdf#112368 Qt5 don't lose ownership in flushClipboardJan-Marek Glogowski
I didn't know that flushClipboard is called for simple text edit fields for C'n'P operations, and not just on LO shutdown. This way the simple text is actually secured in the clipboard instandly, as there aren't complex mime-types to generate and secure. As a result we also need to protect flushClipboard from loosing ownership, which wasn't needed for the shutdown-only case, as this would give up ownership anyway. Change-Id: Ib3cd4979228fc645a27c658abb3df38ccf8c8956 Reviewed-on: https://gerrit.libreoffice.org/80042 Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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-10-04tdf#127529 vertical text not drawn in slideshow canvasCaolán McNamara
because the canvas text drawing impl falls back to using an OutputDevice view of the canvas to use the vcl text drawing apis to achieve vertical text To get an OutputDevice view of the canvas there is a specific VirtualDevice ctor available to create a VirtualDevice that, unlike the normal case, doesn't have its own specific backing buffer, but instead draws to the underlying target provided via the SystemGraphicsData arg The svp/gtk impl missed that understanding and provided an ordinary VirtualDevice with its own backing buffer, not a VirtualDevice that would draw to the expected target surface of the canvas. So the vertical text was drawn to a different surface than the intended one, and was just discarded. The cairo use in the canvas long precedes the use of cairo in vcl itself. Seeing as text is now rendered with cairo in all cases where the canvas uses cairo its probably now pointless for canvas to have its own text rendering path. Change-Id: Ie3b0a43ca2b746cbfe25e2d0415315b3d5403cd2 Reviewed-on: https://gerrit.libreoffice.org/80162 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-04Related: tdf#127529 make it harder to misunderstand this VirtualDevice ctorCaolán McNamara
Change-Id: I250bc68da118a994a2e0ff8ab9eb11112827756d Reviewed-on: https://gerrit.libreoffice.org/80158 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-02tdf#112368 Qt5 handle owned, non-LO clipboard contentJan-Marek Glogowski
LO can actually create clipboard content, which is not backed by an XTransferable, for example when copying / selecting the text of the file name in the QFileDialog. So the ownership check in Qt5Clipboard::handleChanged is wrong and we just have to prevent freeing the content in handleChanged while changing the handle from Qt5Clipboard::setContents. This patch simply sets a boolean member, while the QClipboard is changed by LO, to handle this case. Change-Id: Icc41c32c1f9807e7adff7a9ae16a6c6cacc83f1b Reviewed-on: https://gerrit.libreoffice.org/79992 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de> Tested-by: Jenkins
2019-09-28loplugin:constmethod in vclNoel Grandin
Change-Id: I6a456979a6cfcd7920dc468baf9b23013cb701a4 Reviewed-on: https://gerrit.libreoffice.org/79783 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-26remove internal use of 16-bit packed formatsNoel Grandin
none of our supported hardware uses these any more Change-Id: Ic95d6df619a05df0bec1f5870596cb2bb3bcc6cb Reviewed-on: https://gerrit.libreoffice.org/79476 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-11loplugin:redundantfcast check for std::function castNoel Grandin
noticed by mike kaganski Change-Id: I210f6d2655edde74d9256c6147b7d15a88180196 Reviewed-on: https://gerrit.libreoffice.org/78743 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-06use unique_ptr in CreatePrintGraphicsNoel Grandin
Change-Id: Ib9ca0173f3b5bb090ae71f8622fef717a47e8a2b Reviewed-on: https://gerrit.libreoffice.org/78704 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-27Consolidate ImplCalcLineSpacing()Khaled Hosny
Move getting UPEM and font tables to the functions and use HarfBuzz API to get them. In the future we might stop reading the tables ourselves and use HarfBuzz metrics API instead. Change-Id: I3f4511628fd33200bae94cdcd96479ba3e6d2fba Reviewed-on: https://gerrit.libreoffice.org/78081 Tested-by: Jenkins Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
2019-08-27loplugin:referencecasting find more redundant static_castNoel Grandin
Change-Id: I3a51812bbd3fcdc6b11e47cb12962f0d4fa7a2ae Reviewed-on: https://gerrit.libreoffice.org/78191 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-23loplugin:returnconstval in vclNoel Grandin
Change-Id: Id4a0b460ba3c43e80b80ae6e2da9e40a6753e14c Reviewed-on: https://gerrit.libreoffice.org/77965 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-08-21Qt5SvpGraphics::handleDamage: Don't leak BitmapBufferMichael Weghorn
Leak found by valgrind. Change-Id: If2d03e94467210bc0e485e6a81bf8480a958323d Reviewed-on: https://gerrit.libreoffice.org/77889 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-08-20loplugin:constvars in vclNoel Grandin
Change-Id: Ic454a4d9520992eaecef4b64ec73d49e52ffcc2c Reviewed-on: https://gerrit.libreoffice.org/77828 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-20Fix typosAndrea Gelmini
Change-Id: Iae76994e275517d7a1e7b9e29111159f1ec93e2d Reviewed-on: https://gerrit.libreoffice.org/77766 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-18tdf#88205 Adapt uses of css::uno::Sequence to use initializer_list ctorJulien Nabet
in vcl Change-Id: Ibd66e5ed9064612b73d08fac179ee46dc5b0a4b6 Reviewed-on: https://gerrit.libreoffice.org/77656 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-15loplugin:sequenceloop in unoxml..vclNoel Grandin
Change-Id: Ic3c48ec4d86252b62d3dd25bbc198f7d7fb75e90 Reviewed-on: https://gerrit.libreoffice.org/77533 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-13tdf#126680 Revert "VCL make horizontal scrolling depend on RTL"Jan-Marek Glogowski
This reverts commit 845743131b733b52eb913048f55f5efdd013b24f. And fixes the direction in Qt, which I intentionally broke. Didn't find time yet to fix all the backends, so just stay with the original code. Change-Id: I9967a0d7e75dcb99f8465e9eecf81afe2d351064 Reviewed-on: https://gerrit.libreoffice.org/77390 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): vclStephan Bergmann
Change-Id: I0bd1d26f6fc4052b812fde33ebd1d63111426942 Reviewed-on: https://gerrit.libreoffice.org/76627 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-07-12Qt5 drop special QPushButton handlingJan-Marek Glogowski
Basically reverts commit 3f0dbdd61df ("Draw button focus so that it doesn't obscure the actual button") and declares qt5 doesn't support an extra native focus for a button. LO's own "ant" focus is prevented by Qt5Data::Qt5Data(): pSVData->maNWFData.mbNoFocusRects = true; pSVData->maNWFData.mbNoFocusRectsForFlatButtons = true; Change-Id: Ifdce615cac92f69b008780cf986cdfd0915ccd14 Reviewed-on: https://gerrit.libreoffice.org/75415 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
generated by cgit (git 2.34.1) at 2024-05-25 04:21:05 +0000