summaryrefslogtreecommitdiff
path: root/vcl/qt5/Qt5Widget.cxx
AgeCommit message (Collapse)AuthorFilesLines
2021-09-29qt5: Rename sources + headers according to new class namesMichael Weghorn1-842/+0
This renames the source and header files according to the new class names without a "5" in them, as mentioned in Change-Id: Idf422f82ca9dafbb70e9a64de9c8cfc4cc8c0909 (qt5: Remove "5" from class names in qt5 VCL plugin): > Renaming the headers and source files will be done > in a separate commit to make tracking git history easier. Change-Id: If955e77c8ba508d0a2e01e3a9df1be6dc04c4e4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122806 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-09-29qt5: Remove "5" from class names in qt5 VCL pluginMichael Weghorn1-41/+38
Rename classes for the qt5 VCL plugin to no longer contain the Qt version number "5" in them, e.g. "Qt5Widget" -> "QtWidget". Also, adapt some variable names and comments accordingly. The code will be used for an upcoming qt6 VCL plugin as well, so a "Qt" prefix fits better than a "Qt5" one. Renaming the headers and source files will be done in a separate commit to make tracking git history easier. Change-Id: Idf422f82ca9dafbb70e9a64de9c8cfc4cc8c0909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122805 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-09-10tdf#144412 Qt5 reset m_nModKeyCode on key inputJan-Marek Glogowski1-0/+6
Switching the input direction on Ctrl + L/R-Shift is actually no bug but a feature. It is triggered on key release, so it can be distinguished from / doesn't interfere with shortcut handling. That's what should happen. So trying to implement that behaviour correctly and seeing the appearingly wrong modifier events for gtk3, I found gtk3 resets the frames persistent mnModKeyCode for key input events, which also seems to fix the problem for qt5. Some additional discussion is also in tdf#103158. Regression from commit 862fdb98ca271b60a831cd5420fd16d5f9c1c747 ("tdf#143298 Qt5 send SalEvent::KeyModChange events"). Change-Id: Iafcd1db7abcdf078001ca0602ae6e374f2a169ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121858 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-08-26tdf#144037 Qt5 just close popup with mouse outsideJan-Marek Glogowski1-1/+1
How hard could it be to close a popup window when losing focus or clicking outside of it (AKA tdf#143114 problem 3)? At least with Qt it feels like solving an NP problem... So don't always force-close the popup window if clicked anywhere on it. Seems to be consistent with gen and gtk3. Change-Id: Ia1c231c0b51a55bec2c587feffcf14bb4b4cee55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121093 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-07-30tdf#143580 Qt5 don't use Qt::Popup for FLOAT winsJan-Marek Glogowski1-7/+17
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-22tdf#143493 Qt5 key modifier events don't have textJan-Marek Glogowski1-1/+1
Regression from commit 862fdb98ca271b60a831cd5420fd16d5f9c1c747 ("tdf#143298 Qt5 send SalEvent::KeyModChange events"). Change-Id: I6981af06e3a73dee45ed10416f5d3b17b860a73b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119375 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-07-20Qt5 fix Qt::Popup window handlingJan-Marek Glogowski1-2/+10
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 Glogowski1-0/+81
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-02-15Qt don't fallthrough in inputMethodQueryJan-Marek Glogowski1-6/+4
So my initiak code had a single case with fallthrough to the default, but that is totally bogus for multiple cases. I honestly have no idea, if that ever was correct. I also don't know, if simply returning an empty QVariant is the correct error handling, but the fallthroughs were definitly wrong. Change-Id: I1880a960164eccbb6a5a3832c4ae9aaeda065d43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110946 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-02-15tdf#140207 Qt downscale the ExtTextInputPosJan-Marek Glogowski1-2/+3
Qt reports the unscaled pixel values to the IM, so simply divide all values reported by SalEvent::ExtTextInputPos by the window's scale factor. This correctly positions the IM window on a scaled LO window. Change-Id: Ia639ee3e5fc0e47f7017896b34730bbda7f06a16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110945 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-11-30-Werror,-Wdeprecated-declarations: Qt::MidButton -> Qt::MiddleButtonStephan Bergmann1-1/+1
My qt5-qtbase-devel-5.15.2-2.fc33.x86_64 /usr/include/qt5/QtCore/qnamespace.h states > #if QT_DEPRECATED_SINCE(5, 15) // commented as such since 4.7.0 > MidButton Q_DECL_ENUMERATOR_DEPRECATED_X("MidButton is deprecated. Use MiddleButton instead") = MiddleButton, > #endif so lets assume that the MiddleButton replacement is available since at least Qt 4.7.0 and use it unconditionally here. (Both occurrences had been introduced with 1426437be0530a8ba5749c7e76c5ce0e9053af2f "QT5 implement some mouse handling".) Change-Id: I1db088407a4974b64ef90da75e3c13ede7647422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106862 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-26Avoid -Werror=deprecated-declarationsStephan Bergmann1-1/+6
...with qt5-qtbase-devel-5.15.1-1.fc33.x86_64 on Fedora 33: > ~/lo/core/vcl/qt5/Qt5Widget.cxx: In member function ‘virtual void Qt5Widget::wheelEvent(QWheelEvent*)’: > ~/lo/core/vcl/qt5/Qt5Widget.cxx:144:59: error: ‘QPoint QWheelEvent::pos() const’ is deprecated: Use position() [-Werror=deprecated-declarations] > 144 | fillSalAbstractMouseEvent(rFrame, pEvent, pEvent->pos(), pEvent->buttons(), nWidth, aEvent) > | ^ > ~/lo/core/vcl/qt5/Qt5Widget.cxx:196:5: note: in expansion of macro ‘FILL_SAME’ > 196 | FILL_SAME(m_rFrame, width()); > | ^~~~~~~~~ > In file included from /usr/include/qt5/QtGui/QFocusEvent:1, > from ~/lo/core/vcl/qt5/Qt5Widget.cxx:32: > /usr/include/qt5/QtGui/qevent.h:225:19: note: declared here > 225 | inline QPoint pos() const { return p.toPoint(); } > | ^~~ But for one the types used by the other calls of the FILL_SAME macro do not have a position member function, so stop using the macro and spell it out explicitly here. And for another, QWheelEvent::position returns a QPointF instead of a QPoint, so need to convert that with toPoint. And for a third, QWheelEvent::position is only available since Qt 5.14 according to <https://doc.qt.io/qt-5/qwheelevent.html#position>. Change-Id: I6e64fc9717a9f5a85303f070c6a1b66ed21ec458 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103475 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-28Qt5 refactor mouse event fill codeJan-Marek Glogowski1-25/+21
Adds Qt5Widget::fillSalAbstractMouseEvent to set the common Sal*MouseEvent members. While the member functions of QMouseEvent and QWheelEvent have the same name, they aren't shared via QInputEvent, so this uses a small FILL_SAME macro for less code, Change-Id: I3e5aa52b1bf2774251d97534ce0106a27ef5899b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97343 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-06-28tdf#131991 Qt5 RTL mirror mouse wheel X positionJan-Marek Glogowski1-1/+3
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>
2020-03-09tdf#127687 Qt5 introduce basic HiDPI scalingLuca Carlon1-21/+34
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-02-28tdf#130071 tdf#127815 qt5: Use ExtTextInput only for multi-char key eventsMichael Weghorn1-1/+1
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
2020-02-20tdf#130794 qt5: Actually, ignore non-spontaneous QEvent::ShortcutOverrideMichael Weghorn1-3/+3
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>
2020-02-17tdf#126785 qt5: Ignore external QEvent::ShortcutOverrideMichael Weghorn1-0/+10
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>
2020-02-12clang-analyzer-deadcode.DeadStoresNoel Grandin1-5/+1
Change-Id: Ifa384933569b27d0d08eb479bb95b799163ae386 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88450 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-15tdf#128710 Qt5 don't force immediate paint on showJan-Marek Glogowski1-1/+4
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>
2019-09-28loplugin:constmethod in vclNoel Grandin1-1/+1
Change-Id: I6a456979a6cfcd7920dc468baf9b23013cb701a4 Reviewed-on: https://gerrit.libreoffice.org/79783 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-23Qt5 some minor code cleanupsJan-Marek Glogowski1-3/+3
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 Glogowski1-26/+6
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-13tdf#126680 Revert "VCL make horizontal scrolling depend on RTL"Jan-Marek Glogowski1-1/+1
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-06-22Qt5 directly show tooltips + respect the help areaJan-Marek Glogowski1-7/+0
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 Glogowski1-14/+21
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-22Qt5 fix some broken RTL handlingJan-Marek Glogowski1-3/+5
For RTL decisions we always use Qt's own setting after setting it on startup using QGuiApplication::setLayoutDirection. The only difference between LO and Qt events is the mirrored cursor position, which needs explicit mirroring before reporting mouse based events (mouse and wheel). Tooltips and frame positioning will be handled in separate patches. Additionally the horizontal scroll bar direction hack based on the scroll bar button positions, needs to handle RTL explicitly. Change-Id: I5ce5e69113a6cb6a9cf37a449265c49d92a7c159 Reviewed-on: https://gerrit.libreoffice.org/74545 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-18loplugin:logexceptionnicely in vclNoel Grandin1-2/+3
Change-Id: I0ed575a11c84c2e8aabfa1b4204ba6ae27393d5f Reviewed-on: https://gerrit.libreoffice.org/74245 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-12tdf#125517 Qt5 implement a minimal Qt5ObjectWindowJan-Marek Glogowski1-25/+38
Since we can't use an input and visual transparent widget, like a GtkGrid, we have to implement input forwarding in the QWindow. Using a Qt5Widget directly results in other problems on Qt 5.12+, like these warnings (depending on the tested Qt::WA_* flags): * Attempted flush to non-raster surface QWidgetWindow(0xa386c10, name="QWidgetClassWindow") of type QSurface::OpenGLSurface (consider using Qt::WA_PaintOnScreen to exclude from backingstore sync) * QWidget::paintEngine: Should no longer be called So the current QWidget::createWindowContainer has to stay and key and mouse handling must be implemented as in Qt5Widget. And the QWindow is strangely not accessible through the windowHandle() of the container QWwidget. As a result this patch is mostly boilerplate code, publishing the Qt5Widget mouse and key handling as static functions. Change-Id: I5be5f5fa1379c6bdefab0f96604251801c252b38 Reviewed-on: https://gerrit.libreoffice.org/73566 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-09Qt5Widget: lcl_retrieveSurrounding needs SolarMutexMichael Weghorn1-0/+1
Otherwise * starting Writer * "File" -> "New" -> "Spreadsheet" * switching back to Writer window using Alt+Tab in Plasma Wayland session results in Thread 1 "soffice.bin" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff7b287bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7b13535 in __GI_abort () at abort.c:79 #2 0x00007ffff7b1340f in __assert_fail_base (fmt=0x7ffff7c75ee0 "%s%s%s:%u: %s%sAssertion `%s' failed. %n", assertion=0x7ffff14b0410 "ImplGetSVData()->mpDefInst->GetYieldMutex()->IsCurrentThread() && \"SolarMutex not owned!\"", file=0x7ffff14b03d0 "/mnt/data/development/git/libreoffice/vcl/source/app/dbggui.cxx", line=46, function=<optimized out>) at assert.c:92 #3 0x00007ffff7b21102 in __GI___assert_fail (assertion=0x7ffff14b0410 "ImplGetSVData()->mpDefInst->GetYieldMutex()->IsCurrentThread() && \"SolarMutex not owned!\"", file=0x7ffff14b03d0 "/mnt/data/development/git/libreoffice/vcl/source/app/dbggui.cxx", line=46, function=0x7ffff14b0470 <ImplDbgTestSolarMutex()::__PRETTY_FUNCTION__> "void ImplDbgTestSolarMutex()") at assert.c:101 #4 0x00007ffff0e495db in ImplDbgTestSolarMutex() () at /mnt/data/development/git/libreoffice/vcl/source/app/dbggui.cxx:46 #5 0x00007ffff2026c2f in DbgTestSolarMutex() () at /mnt/data/development/git/libreoffice/tools/source/debug/debug.cxx:91 #6 0x00007ffff4eea765 in SfxBroadcaster::AddListener(SfxListener&) (this=0x555558e61620, rListener=...) at /mnt/data/development/git/libreoffice/svl/source/notify/SfxBroadcaster.cxx:94 #7 0x00007ffff4effe4e in SfxListener::StartListening(SfxBroadcaster&, DuplicateHandling) (this=0x55555a1ebe50, rBroadcaster=..., eDuplicateHanding=DuplicateHandling::Unexpected) at /mnt/data/development/git/libreoffice/svl/source/notify/lstner.cxx:104 #8 0x00007fffbfdff188 in ScTabViewShell::AddAccessibilityObject(SfxListener&) (this=0x555558c27080, rObject=...) at /mnt/data/development/git/libreoffice/sc/source/ui/view/tabvwshh.cxx:215 #9 0x00007fffbf65754a in ScAccessibleDocument::PreInit() (this=0x55555a1ebdb0) at /mnt/data/development/git/libreoffice/sc/source/ui/Accessibility/AccessibleDocument.cxx:1303 #10 0x00007fffbfd12754 in ScGridWindow::CreateAccessible() (this=0x555558c2dd50) at /mnt/data/development/git/libreoffice/sc/source/ui/view/gridwin5.cxx:443 #11 0x00007ffff06ef948 in vcl::Window::GetAccessible(bool) (this=0x555558c2dd50, bCreate=true) at /mnt/data/development/git/libreoffice/vcl/source/window/accessibility.cxx:129 #12 0x00007fffe730f9c6 in lcl_retrieveSurrounding(sal_Int32&, sal_Int32&, QString*, QString*) (rPosition=@0x7fffffffcb90: -12560, rAnchor=@0x7fffffffcba0: -13392, pText=0x0, pSelection=0x0) at /mnt/data/development/git/libreoffice/vcl/qt5/Qt5Widget.cxx:598 #13 0x00007fffe730ff17 in Qt5Widget::inputMethodQuery(Qt::InputMethodQuery) const (this=0x555556c50ec0, property=Qt::ImCursorPosition) at /mnt/data/development/git/libreoffice/vcl/qt5/Qt5Widget.cxx:656 #14 0x00007fffe786c7f7 in QWidget::event(QEvent*) (this=0x555556c50ec0, event=0x7fffffffcef0) at kernel/qwidget.cpp:8993 #15 0x00007fffe730f0d3 in Qt5Widget::event(QEvent*) (this=0x555556c50ec0, pEvent=0x7fffffffcef0) at /mnt/data/development/git/libreoffice/vcl/qt5/Qt5Widget.cxx:466 #16 0x00007fffe782e4b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x5555556480f0, receiver=receiver@entry=0x555556c50ec0, e=e@entry=0x7fffffffcef0) at kernel/qapplication.cpp:3726 #17 0x00007fffe7835950 in QApplication::notify(QObject*, QEvent*) (this=0x555555647fe0, receiver=0x555556c50ec0, e=0x7fffffffcef0) at kernel/qapplication.cpp:3485 #18 0x00007fffe851b5a9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x555556c50ec0, event=event@entry=0x7fffffffcef0) at ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 #19 0x00007fffe5bdbf6a in QCoreApplication::sendEvent(QObject*, QEvent*) (event=0x7fffffffcef0, receiver=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:234 #20 0x00007fffe5bdbf6a in QtWaylandClient::QWaylandTextInput::updateState(QFlags<Qt::InputMethodQuery>, unsigned int) (this=0x555555655ab0, queries=..., flags=2) at qwaylandinputcontext.cpp:134 #21 0x00007fffe5bdc433 in QtWaylandClient::QWaylandTextInput::commit() (this=0x555555655ab0) at qwaylandinputcontext.cpp:98 #22 0x00007fffe5bdc4b9 in QtWaylandClient::QWaylandInputContext::commit() (this=0x555555652300) at qwaylandinputcontext.cpp:544 #23 0x00007fffe5bdc4b9 in QtWaylandClient::QWaylandInputContext::commit() (this=0x555555652300) at qwaylandinputcontext.cpp:410 #24 0x00007fffe7833aa5 in QApplication::setActiveWindow(QWidget*) (act=act@entry=0x555556f29a60) at kernel/qapplication.cpp:2088 #25 0x00007fffe7833b53 in QApplicationPrivate::notifyActiveWindowChange(QWindow*) (this=<optimized out>, previous=<optimized out>) at kernel/qapplication.cpp:2182 #26 0x00007fffe7e42ce5 in QGuiApplicationPrivate::processActivatedEvent(QWindowSystemInterfacePrivate::ActivatedWindowEvent*) (e=<optimized out>) at kernel/qguiapplication.cpp:2292 #27 0x00007fffe7e42f1d in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) (e=e@entry=0x555559c186d0) at kernel/qguiapplication.cpp:1838 #28 0x00007fffe7e1d06b in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) (flags=...) at kernel/qwindowsysteminterface.cpp:1032 #29 0x00007fffe5bfc6cb in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQt5WaylandClient.so.5 #30 0x00007fffe72e9d7d in Qt5Instance::ImplYield(bool, bool) (this=0x5555556c46a0, bWait=true, bHandleAllCurrentEvents=false) at /mnt/data/development/git/libreoffice/vcl/qt5/Qt5Instance.cxx:345 #31 0x00007fffe72e9e8d in Qt5Instance::DoYield(bool, bool) (this=0x5555556c46a0, bWait=true, bHandleAllCurrentEvents=false) at /mnt/data/development/git/libreoffice/vcl/qt5/Qt5Instance.cxx:356 #32 0x00007ffff0ec1a66 in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /mnt/data/development/git/libreoffice/vcl/source/app/svapp.cxx:457 #33 0x00007ffff0ec1f89 in Application::Yield() () at /mnt/data/development/git/libreoffice/vcl/source/app/svapp.cxx:521 #34 0x00007ffff0ec185e in Application::Execute() () at /mnt/data/development/git/libreoffice/vcl/source/app/svapp.cxx:438 #35 0x00007ffff7d3dfea in desktop::Desktop::Main() (this=0x7fffffffda80) at /mnt/data/development/git/libreoffice/desktop/source/app/app.cxx:1621 #36 0x00007ffff0edc6c9 in ImplSVMain() () at /mnt/data/development/git/libreoffice/vcl/source/app/svmain.cxx:203 #37 0x00007ffff0edc7ee in SVMain() () at /mnt/data/development/git/libreoffice/vcl/source/app/svmain.cxx:237 #38 0x00007ffff7d977a9 in soffice_main() () at /mnt/data/development/git/libreoffice/desktop/source/app/sofficemain.cxx:170 #39 0x000055555555495d in sal_main () at /mnt/data/development/git/libreoffice/desktop/source/app/main.c:48 #40 0x0000555555554943 in main (argc=2, argv=0x7fffffffddd8) at /mnt/data/development/git/libreoffice/desktop/source/app/main.c:47 Change-Id: I40bf501d07dde0c4610496aa1b2bb2a4051fdf2d Reviewed-on: https://gerrit.libreoffice.org/73696 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-06-06tdf#125201 fix QWheelEvent angleDelta() handlingJan-Marek Glogowski1-10/+23
Comming back to my initial, known broken implementation from 2017-11 (see commit 1426437be053 ("QT5 implement some mouse handling")), which just works with mouse scroll wheels. This just fixes angleDelta() based scrolling. An additional patch might be needed, if some driver just uses pixelDelta() values, but Qt explicitly states: "On X11 the pixelDelta() value is driver specific and unreliable, use angleDelta() instead.", so we'll do just that for now. Change-Id: I1be5f9392ed475aea7ab4d965a07e1e3c2574fe7 Reviewed-on: https://gerrit.libreoffice.org/73614 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-06tdf#124118 Qt5 post non-code keys via ExtTextInputJan-Marek Glogowski1-19/+31
Originally I tried to implement the gtk3 way by shoving all key input in some way through the QInputMethod. But that turned out to be impossible, because all the nice input event filtering is privately hidden in the platform abstraction. And it took me much longer to realize that gtk3 is doing this. Still the delivered code point in the KeyEvent is correct, so this simply uses ExtTextInput events for non-code key events, if LO has enabled input method support for a frame. Change-Id: Ia9bb6baf013cf790deecb9675f8309e32294e982 Reviewed-on: https://gerrit.libreoffice.org/73322 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-02Qt5 return expected QVariants int sizesJan-Marek Glogowski1-2/+2
Grep'ing the Qt source code, most of the places call toInt() on the QVariants returned from Qt::ImCursorPosition and Qt::ImAnchorPosition (toUInt() is probably a bug). So actually deliver these (and fix the 32bit build with the sal_Int32 ambiguity - there is no "signed long" QVariant constructor). Change-Id: Id6b8fbabb8156692592bdef48437db140c6b7cca Reviewed-on: https://gerrit.libreoffice.org/73349 Tested-by: Jenkins Tested-by: Rene Engelhard <rene@debian.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-28Qt5 implement SalSurface support for cairoJan-Marek Glogowski1-1/+1
Current qt5+cairo uses the plain VCL canvas. This patch is just a copy of Gtk3Surface (minus comments) with a different update call. This way the Cairo path now uses the Cairo canvas instead. It fixes at least tdf#122668 for me, but other Impress bugs might be fixed this way too. Change-Id: Iba511c851001753328293c28e53eaa4acc4315d0 Reviewed-on: https://gerrit.libreoffice.org/72921 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins Reviewed-by: Aleksei Nikiforov <darktemplar@basealt.ru>
2019-05-24tdf#125160: honour keyboard modifiers if used during DnDKatarina Behrens1-2/+3
e.g. copy-DnD with Ctrl held down. This is qt5 remix of tdf#109227 Change-Id: Ib0794c7468cc04d3d50686952305717e10c90c9a Reviewed-on: https://gerrit.libreoffice.org/72878 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-05-22New loplugin:dataStephan Bergmann1-1/+1
...following up on 1453c2c8f13bac64ecd1981af7cebf1c421808ac "prefer vector::data to &vector[0]" Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01 Reviewed-on: https://gerrit.libreoffice.org/72765 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-05-15Qt5 IM report selected text and anchorJan-Marek Glogowski1-8/+46
Implement the text selection IM queries. Never seen them, but since the text querying code is already there, it's easy to extend to include the selection. Anchor is the non-cursor position of the selection and should return the cursor in case of not selected text. Change-Id: I0e49a8593a5a6c6268395857748b5fc304372210 Reviewed-on: https://gerrit.libreoffice.org/71797 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-15Qt5 IM handle surrounding text requestsJan-Marek Glogowski1-0/+53
This is almost a C'n'P from gtk / gtk3. That code is from 2006 (see i#68048 / commit 28c5cdcc53ae068b0c763c660d61a8291dd96726). The original patch was described by the author (caolan) as hilarious. No change from my side, except using QString. Completely untested, in theory correct. Change-Id: I8373ca7ac9eda6e377da985532fd2b7cd595bf48 Reviewed-on: https://gerrit.libreoffice.org/71786 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-15qt5: Fix build error on 32 bit archsMichael Weghorn1-1/+2
... as observed in [1]: > [...] > In file included from /usr/include/c++/8/algorithm:61, > from /usr/include/i386-linux-gnu/qt5/QtCore/qglobal.h:142, > from /usr/include/i386-linux-gnu/qt5/QtGui/qtguiglobal.h:43, > from /usr/include/i386-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43, > from /usr/include/i386-linux-gnu/qt5/QtWidgets/qwidget.h:43, > from /usr/include/i386-linux-gnu/qt5/QtWidgets/QWidget:1, > from /<<PKGBUILDDIR>>/vcl/inc/qt5/Qt5Widget.hxx:22, > from /<<PKGBUILDDIR>>/vcl/qt5/Qt5Widget.cxx:20: > /usr/include/c++/8/bits/stl_algobase.h:265:5: note: candidate: ‘template<class _Tp, class _Compare> constexpr const _Tp& std::max(const _Tp&, const _Tp&, _Compare)’ > max(const _Tp& __a, const _Tp& __b, _Compare __comp) > ^~~ > /usr/include/c++/8/bits/stl_algobase.h:265:5: note: template argument deduction/substitution failed: > /<<PKGBUILDDIR>>/vcl/qt5/Qt5Widget.cxx:502:69: note: deduced conflicting types for parameter ‘const _Tp’ (‘int’ and ‘sal_Int32’ {aka ‘long int’}) > std::vector<ExtTextInputAttr> aTextAttrs(std::max(1, nLength), ExtTextInputAttr::NONE); [1] https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=1%3A6.3.0%7Ealpha1-1&stamp=1557890923&raw=0 Change-Id: Ic0e3e0b8bc65d9755b3d62385673f8d1e357b122 Reviewed-on: https://gerrit.libreoffice.org/72352 Tested-by: Jenkins Reviewed-by: Rene Engelhard <rene@debian.org> Tested-by: Rene Engelhard <rene@debian.org>
2019-05-13Qt5 handle theming-based change eventsJan-Marek Glogowski1-0/+22
Qt generates three change events when changing the KDE theme: FontChange, StyleChange and PaletteChange. LO has two: SettingChanged and FontChanged. And like Qt LO will inform all widgets / windows independently. To prevent several redraws, this patch just collects all Qt's change events and notifies LO once a bit later via a Timer. Change-Id: I9b45f543f13a84e39247a642a0e33c9ec008a46a Reviewed-on: https://gerrit.libreoffice.org/72196 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-09Qt5 IM handle (spurious?) all-empty IM eventsJan-Marek Glogowski1-7/+31
2nd attempt to fix the bug described in commit 00221089800c ("Qt5 IM allow committing empty strings") and various siblings of it. This also reverts it. What I see is calls with "all-empty" events (preedit, commit and replacementLength() == 0; no QInputMethodEvent::Attribute), some from QIBusPlatformInputContext::updatePreeditText. There are various Writer document edit states with (selected) text, undo, cursor position and focus changes to other windows via Ctrl+Tab, which will result in inputMethodEvent calls totally in contrast to the expected text state, all somehow always related to all-empty events. They currently result in wrongly deleted selected text, change of selection, cursor movement or general change of text from old preedit. Most time on focus out / window change, some times at first meta-key press after focus in. This patch tries hard not to corrupt Writers edit state with these all-empty events. No idea if this is some bug on LO's qt5 side or expected, but KDE kate and VCL gtk3 and gen work fine, so I assume Qt's behaviour is correct. FWIW gtk3 also does some extended IM handling with focus, so probably this is the Qt equivalent of it. But then I couldn't find some eqivalent code in Qt's source code. I actually expected an even more complex solution (if this really fixes all cases). Works for a multitude of tests I tried to come up with, but is quite probably not the final fix to this, as qt5 current doesn't handle replacementStart() and replacementLength() at all. Also never saw a call to Qt5Frame::EndExtTextInput. Change-Id: I4210e0588041cfb4d80dbdfdb937e430a5f7cbfb Reviewed-on: https://gerrit.libreoffice.org/71988 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-06Qt5 make Qt5Widdget's frame a private referenceJan-Marek Glogowski1-41/+38
Kind of a regression from commit 4d382636b0b1 ("qt5: Add basic a11y support"), which made it public for a single call. Change-Id: I631a861a98388223770cfca2704c3ddee6a0a8a0 Reviewed-on: https://gerrit.libreoffice.org/71836 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-05Qt5 IM allow committing empty stringsJan-Marek Glogowski1-1/+1
This is a really nasty bug, which is mainly triggered by focus change. It happens because Qt tries to delete the surrounding text on the first key press after focusing in, sending an empty commit string via QInputMethodEvent. To reproduce: * type some dummy word in Writer * select a part of the word * Alt+Tab to a different window to switch focus * Alt+Tab back to Writer * Press Alt => deletes the selected text Instead of Alt+Tab you can also switch the IM via hotkey. Change-Id: I0ce4c64aebf93a422bd3067f204da1d8f326a327 Reviewed-on: https://gerrit.libreoffice.org/71796 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-05Qt5 IM update input position on keypressJan-Marek Glogowski1-0/+3
At least my ibus installation doesn't ask for the current input position (Qt::ImCursorRectangle), in comparison to fcitx. So just as gtk3, we now actively updates the IM position on every keypress. Fixes the ibus hint window position for me, which would otherwise be displayed in the top-left screen corner. Change-Id: I9e5f0fb6b134615bc00cdd169ce8592f01239d20 Reviewed-on: https://gerrit.libreoffice.org/71785 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-05tdf#123957 Qt5 IM generate correct formatingJan-Marek Glogowski1-3/+38
Actually really evaluate some of the formating provided by the QInputMethodEvent::TextFormat attribute and not blindly underline all of the text. This evaluates the same formating that the gtk3 backend evaluates from pango, so the result should be somehow on par. Couldn't find a way to test the red strike-out text. Don't know how often I typed hyoujunnsutairu to test this bug, which - according to Google - translates to "standard style". Change-Id: I4263df6dc1e0e5ce5d8cb0be681656ccd662a830 Reviewed-on: https://gerrit.libreoffice.org/71783 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-05-05tdf#123956 Qt5 IM update cursor positionJan-Marek Glogowski1-1/+23
This sets the cursor position to the one provided by the QInputMethodEvent::Cursor attribute. Change-Id: I4a99f9939b53c69631e45d41102bf9c7f53f0ff5 Reviewed-on: https://gerrit.libreoffice.org/71782 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-04-30tdf#123859: only accept drops when drop target was registeredKatarina Behrens1-1/+0
some hard to reliably reproduce crashes when drag'n'dropping slides in slide sorter in Impress can be tracked down to null drop target. Not every SalFrame is registered as drop target, so let's accept drops (QWidget::setAcceptDrops) only for those frames that are. Change-Id: I01f006d619209c558e8d9976116daad65f51d7d9 Reviewed-on: https://gerrit.libreoffice.org/71533 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-03-05tdf#120783: take suggested/preferred DnD ops into accountKatarina Behrens1-3/+3
use those for drag operation start in Qt5Widget and eventually to construct DropTargetDragEnterEvent Change-Id: I3a92cbe722dadc64f8a210f7fd4016c8eb17216b Reviewed-on: https://gerrit.libreoffice.org/68675 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-03-04Unbreak internal DnD by using null MimeDataKatarina Behrens1-2/+2
Regression from 67b0fcea9d748c4dd8101036cbb2c587d65f0bf7 (which implements external DnD). QMimeData of internal DnD is never null, it always contains internal MimeType (but empty byte array) Change-Id: Ie12e9c3b7a3c7cebfd98064bb2fafec27c20a442 Reviewed-on: https://gerrit.libreoffice.org/68673 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-02-15tdf#123451 qt5: Detect decimal separator on keypadMichael Weghorn1-2/+7
'QtKeyEvent::key()' doesn't return a special value for the decimal separator key on the keypad ("," or "."), but just returns 'Qt::Key_Comma' or 'Qt::Key_Period'. However, the 'Qt::KeypadModifier' modifier is set in this case, so check for this one in addition and return 'KEY_DECIMAL' if those are combined. Change-Id: Ia80826e2ad5e47a1f49bef450168523d766c1d6a Reviewed-on: https://gerrit.libreoffice.org/67886 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-25 16:04:52 +0000