summaryrefslogtreecommitdiff
path: root/vcl/qt5
AgeCommit message (Collapse)Author
2022-05-17qt: Drop unnecessary reinterpret_castMichael Weghorn
`OString::getStr` already returns `const char *`, so there's no need to cast to that. Change-Id: Ief787f9823ffea075882658cf0adec29a8030199 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134455 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-05-10tdf#104930 Implement TextMetric::GetHangingBaseline.Mark Hung
The text metric value is initialized in ImplFontMetricData::ImplInitBaselines() using harfbuzz API hb_ot_layout_get_baseline. It can't handle multiple hanging baselines of the same font for different scripts yet because the script is fixed to HB_SCRIPT_UNKOWN. Change-Id: I2574f0dba45501187064b9341c573159914a4a17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133667 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2022-04-21tdf#148699 Qt track the active / shown popupJan-Marek Glogowski
I have no idea, if there can be multiple active popups in LO in some way. There can be multiple FloatingWindow and gtk does count them in m_nFloats... There is a whole lot going on in gtk3 related to isFloatGrabWindow(), with "funny" comments like: // FIXME: find out who the hell steals the focus from our frame So this goes with some "optimistic" approach: there is just one active popup, so we can track it in QtInstance. It WFM... Change-Id: I9778587696e1ad9e641dba4f102e2e921266eee6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133249 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-04-21qt6: Fix build (QtWidget::enterEvent)Michael Weghorn
In Qt 6, `QWidget::enterEvent` takes a `QEnterEvent*` param. An override for `QtWidget` was added in commit dc886bc6de2c0061a840bea2426663c3be2ecd26 Date: Tue Apr 19 16:03:56 2022 +0200 tdf#140463 Qt handle mouse enter+leave events Change-Id: I47579ce6686da321533afcef2e4436e315901059 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133235 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-04-20tdf#140463 Qt handle mouse enter+leave eventsJan-Marek Glogowski
Currently just implemented for the QtWidget, but still as a static function, so it may be used for QtObject at some point too. But there is no (mouse) enter or leave event function in QWindow, so no way to handle these there. And since we can't modify the returned QWidget from QWidget::createWindowContainer, the only way would be to expand the static QtWidget::handleEvent used by QtObjectWindow::event ... if it's actually needed at some point. Change-Id: If9009e5dfca508acd1e702df1a17eb8ad7c29690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133190 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-04-13loplugin:stringviewparam whitelist some more functionsNoel Grandin
for which we have o3tl:: equivalents Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-12tdf#148115 Qt handle tooltips via event loopJan-Marek Glogowski
Instead of calling QToolTip::showText directly from LO, this defers showing the tooltip to the QEvent processing, which takes the tooltip timeouts into account. So tooltips are shown with a slight delay, therefore they happen less fast on mouse move, reducing / avoiding artifacts of fast changing windows. This unfortunately comes with yet an other hack in the area of our fake popup windows... New handling is based on the code of the Qt Tool Tips example. Change-Id: I42634ad36dd12171c30f52f07a02a88d3c48a718 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132841 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2022-04-12tdf#148491 Qt reconnect the QMenuBar close buttonJan-Marek Glogowski
When the QMenuBar of a QMainWindow is replaced, an existing corner widget is preserved / transferred, but its connections are still severed; a bit unexpected... The documentation for QMenuBar::setCornerWidget is not really clear what is happening, but the code has this nice comment: "// Reparent corner widgets before we delete the old menu". At least there is no need to explicitly delete the button. Still we must reconnect an existing button on each SetFrame. Regression from commit 9c4ef8ce3183e27ca174475cf4a8d15cc0368f60 ("tdf#145954 Qt unshare QMenubar usage"). Change-Id: I13c31734e665b78231a08cd76ca6305122e08879 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132836 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-04-11tdf#148481 Map RefHand cursor to Qt::PointingHandJan-Marek Glogowski
Change-Id: I79c7008655f22737f92a4a6430f1380e81c1c386 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132833 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-04-10loplugin:stringview check for getToken and trimNoel Grandin
since we now have o3tl versions of those that work on string_view. Also improve those o3tl functions to support both string_view and u16string_view Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-08tdf#141578 Qt handle QtFrame screen changesJan-Marek Glogowski
LO doesn't provide any way to notify screen changes / scaling factors of a window and in fact doesn't really handle scaling factors in VCL. The QWidget doesn't receive a resize event, because it's size doesn't change, just the scaling factor. So we trigger a faked resize on QWindow::screenChanged signal. Change-Id: I6928c4c62d1c0995c70fea0088cff17849bcd1d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132650 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2022-04-07tdf#143135 Qt break recursive IM QueryCursorRectJan-Marek Glogowski
To reproduce the Impress crash, you need an IM, e.g. fcitx / ibus. This is triggered by having an active input, like double-clicking one of a presentations text fields, then leaving the window and switching back to it. This results in a stack exhaustion in a few seconds. The backtrace is basically: QWidget::setFocus QtFrame::ToTop sd::Window::GrabFocus ImplHandleExtTextInputPos QtWidget::inputMethodQuery QInputMethod::cursorRectangle QWidget::setFocus QApplication::setActiveWindow QtInstance::DoYield main I scratched my head over the longer backtrace for while, but there seems to be no good way to prevent this from LO's POV. The only alternative from the Qt VCL plugin is QtFrame::ToTop. That code is less ugly (no mutable or cached result), but QtWidget:: inputMethodQuery is earlier in the backtrace. Change-Id: Ief3a8e44bca295cc676e75050d52d70a1da98a88 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132643 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-04-07tdf#147285 qt: Prefer "text/plain;charset=utf-8" over "text/plain"Michael Weghorn
If there were no data for MIME type "text/plain;charset=utf-16" in the clipboard, but "text/plain" was provided, it was previously assumed that this would be encoded in the locale's encoding, and corresponding conversion using that encoding happened to provide "text/plain;charset=utf-16" ourselves. "text/plain;charset=utf-8" data was simply ignored, but using it (if present) and preferring it over "text/plain" is more reliable (and e.g. avoids incorrect paste of Chinese characters from Firefox into Impress when using the qt5/qt6/kf5 VCL plugins on Wayland), so use it if present. Rename the "m_bConvertFromLocale" member to better fit the new meaning. (An alternative solution to adding our own handling for "text/plain;charset=utf-8" and making assumptions for the encoding of "text/plain" data would be to let Qt handle this and just call `QMimeData::text()` for the `m_bProvideUTF16FromOtherEncoding=true` case in `QtTransferable::getTransferData`. Since qtbase commit 589a01ff6b1eacf81e74a5fc4801572135214f43 ("QMimeData: Prefer UTF-8 when multiple charsets are available", contained in Qt >= 5.13), that one handles MIME type "text/plain;charset=utf-8" in addition to "text/plain".) [1] https://code.qt.io/cgit/qt/qtbase.git/commit/?id=589a01ff6b1eacf81e74a5fc4801572135214f43 Change-Id: I89f33216bf6be02a347d245b2359273af2eb530a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132631 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2022-04-06Qt drop unused QtMenu::mpCloseButtonJan-Marek Glogowski
Change-Id: I988cabf4c07d5efd298c53b696f6d114f4f594bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132637 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-04-06tdf#145954 Qt unshare QMenubar usageJan-Marek Glogowski
The Qt code was sharing the menu bar from the top level frame, but LO expects independent menu bars per SetFrame calls. So instead of showing the new bar and then hiding the old one, this was always show and hiding the same menu bar, resulting in a hidden menu bar. As a result of unsharing, LO now must check that its menu bar pointer is still valid for usage. The QMainWindows takes ownership when a QMenuBar is assigned and destroy old ones. Change-Id: I2c6b12199a1e17a5d9f88686a4b27b1413beda47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132581 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-04-06tdf#144585 Qt fix Wayland LO fake popupsJan-Marek Glogowski
So Michael Weghorn was somehow reminded of an abandoned commit from me ("Qt5 rework parent handling") archived in https://gerrit.libreoffice.org/c/core/+/73463. The bug introducing the new QWidget parenting, tdf#145363, was resolved in a better way by explicitly setting parents for the modal dialogs, so LO doesn't break Qt anymore. The actual problem is, that an additional modal dialog needs to be stacked to the previous modal dialog; no "parallel" modal dialogs are allowed, which my original fix tried to enforce by reparenting. Then there is the problem with Qt::Popup's focus grabbing on show, which breaks LO's editable ComboBox. So LO's popup / FLOAT windows are mapped to Qt::ToolTip, which are automatically advertised as tooltips via accessibility. For X11 / xcb, Qt:Window with the Qt::BypassWindowManagerHint works well enough as an alternative, but WASM and Wayland don't seem to implement it correctly, so this just handles popups as Qt::ToolTip on all platforms. This reverts commit b00a68a8e19370e106cd76258a3c1825f43613ee ("tdf#145363 Qt reparent modal dialogs on show"). In addition the popup widgets are switched back to Qt::ToolTip. Change-Id: If726771b4e9cc3f639f21cf502b3ec5985873643 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132526 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2022-04-04tdf#147523 Qt use inner QWidget to set pointer posJan-Marek Glogowski
Regression from commit e63fe68fb1d0915b64fdf63f7fa6eed866fa3a0d ("Qt use asChild for pointer positioning"), which should just have been a cleanup for commit ca28826a087245686d7fca3ffc8ca1f03307924d ("tdf#131467 Qt set default position on first resize"). And scale the requested position by the device scale factor. Change-Id: I50b3c628d22896e987d8cc2eaf5635cb12ba3464 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132518 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2022-03-29qt: Fix typo in function name: lcl_MapUndrelineStyleMichael Weghorn
Change-Id: I50b2ffeb1b6bb490c14a307152634cc51022a426 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132276 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-03-29qt a11y: Handle TABLE_MODEL_CHANGED eventMichael Weghorn
Note however, that as of now, this doesn't have any effect in practice, since `AtSpiAdaptor` for Linux in the Qt library currently just ignores `QAccessible::TableModelChanged` events instead of forwarding them as corresponding AT-SPI events. [1] [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/accessible/linux/atspiadaptor.cpp?id=9a4c32cedda3a00e06eb3aed13a731d23f6c56d9#n1105 Change-Id: I6339d172da54bc30987bb9261ce37005ebce5501 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132222 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-03-24loplugin:constantparamNoel Grandin
Change-Id: I6bfbd0cb5c2eac60bdac69fd862154fb2f537a89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-22loplugin:loopvartoosmallStephan Bergmann
...with --enable-qt6, where QList::size() return type has changed from int to qsizetype (aka ptrdiff_t); but just replacing the use of int with a use of qsizetype would fail with --enable-qt5 in some build environments where the Qt5 qglobal.h doesn't happen to already be included, so simply replace this with a range-based for loop and be done with it Change-Id: I5a6c7b0468ed7cef6de7fb647fdb2631a8cb5b35 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131916 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-11tdf#114150: Remove duplication of strings found in file dialogsJulien Nabet
Change-Id: I86f720a23dd9d400d39d9606e073b483850a9df2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131153 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-02-23qt a11y: Handle HYPERTEXT_CHANGED eventMichael Weghorn
Change-Id: Ib4e6f06a5cdac1ac47eb3d273ca103fb5081550e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130361 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-02-23qt a11y: Handle VALUE_CHANGED eventMichael Weghorn
Change-Id: I34d813ced29a591b0a6652eeb1271a978980bba5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130359 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-02-23qt a11y: Better handle TEXT_CHANGED eventMichael Weghorn
Trigger the corresponding Qt accessibility events for deleted and inserted text rather than sending a QAccessible::TextColumnChanged event (which looks like a rather arbitrary choice...). Qt also has a 'QAccessibleTextUpdateEvent' class that could be used to send a combined event, but since we get the relevant data separately in the LO event, using the latter wouldn't make things easier. And at least for the AT-SPI case on Linux, Qt sends separate AT-SPI events via D-Bus anyway. [1] Unfortunately, qt5/qt6 VCL a11y is not yet functional enough to e.g. test that the correct AT-SPI events are actually received when using the the script mentioned in Change-Id: Ibcae27ecfccf41a909e06d01ce681e4b7b97eb25 (gtk3 a11y: Migrate from deprecated "text-changed" ATK signal). [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/accessible/linux/atspiadaptor.cpp#n964 Change-Id: Ia9282382b6d5fd6bffd536dcda2989a6da901e90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130356 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-02-18qt a11y: Map CARET_CHANGED event to Qt equivalentMichael Weghorn
The previous handling of mapping that to QAccessible::TableSummaryChanged looks rather arbitrary. Change-Id: I066cee4bd90a49a47dd29252c11f8f74edccb637 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130141 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-02-06qt5: crash entering ë with french IMCaolán McNamara
which for me with french IM enabled on my keyboard is physically AltGr+[ (crashes here on trying to underline ¨ with a length of 2) then e. Change-Id: Id59bd84af2ab4d8403b11b1a13efb2bbdb608199 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129538 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-25tdf#146941 qt: QtFilePicker::finished needs SolarMutexGuardMichael Weghorn
Change-Id: I4165c72ddd6370c8fe7faf55f9db831359f6f8a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128923 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-01-21VCL fix shutdown when run via system loopJan-Marek Glogowski
Adds DoQuit and SAL_USE_SYSTEM_LOOP to complement DoExecute. Makes it easier to switch between a LO with and without nested event processing. Unfortunatly the recovery dialogs run outside of Application::Execute(), so this currently also disables recovery handling. Follow-up (and no more Emscripten-specific) change to commit 93133585b5b52e38defc3162eeb1e7704dceafcb ("WASM optionally run any app via system loop"). Change-Id: I1b622065d7fa0c5ad03a7c7daaf8241dcc3f09a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128717 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-19WASM optionally run any app via system loopJan-Marek Glogowski
Allows LO to run via system event loop instead of having an own one and processing system events as needed. Needed for WASM, so the browser isn't blocked, as there is no way to run the browser mainloop from WASM. Generally an alternative to running LO in a WebWorker and communicating to some frontend. Change-Id: I24955638827f3b8c04240845ffc781cd28f2aa29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128602 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-19WASM Qt: various EMSCRIPTEN adaptionsJan-Marek Glogowski
* Don't create a native window handle * Use a static QMimeData for non-working clipboard * Use Qt::Tooltip for LO's popup windows Change-Id: I6b6edfa26466814cb0500116098eafcbe41bba26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128587 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-16Qt notify LO of many QScreen related eventsJan-Marek Glogowski
LO just has a single display event, SalEvent::DisplayChanged, Qt has a multitude. So this will generate multiple LO notifications. I don't see any reasonable way to prevent that. Doesn't seem a problem here. Change-Id: I2f11e53765869a4ca292a1d337347e4e7470e3c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128474 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-14VCL drop m_pInstance from *nix SalDataJan-Marek Glogowski
AKA the "*nix SalData untangling" commit. The original plan was to get rid of vcl/inc/saldatabasic.hxx and even SalData for all the *nix backends. But after many backs and forths, reinspecting the code and imagining the resulting code, I decided against that plan. All these variants would have resulted in reinterpret_cast calls, I wanted to prevent. And they would have required larger renames for no benefit. An other, related idea was to include all SalData implementations in the vcl/inc/svdata.hxx header, but that seemed like an include explosion, so was also dropped. I tried to untangling iOS from using GenericUnixSalData, as it doesn't use any of it's features. The new, minimal SalData should be sufficient. I'm leaving the easier drop of mpInstance from the Windows and MacOSX backend as a minimal interesting EasyHack. Change-Id: I5be01c1f42131a7e31cb30899392308e1e2de53b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128402 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-13allow selecting text rendering mode suitable for natural glyph positionsCaolán McNamara
Change-Id: I6b8c815fda3a48917467719432071c0716e3e9ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127338 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-12keep positions as DeviceCoordinate within SalLayoutCaolán McNamara
Change-Id: I20bbb0e252ffd09901f587599430e715dbe977b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128300 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-09Qt minimize modal reparenting a bitJan-Marek Glogowski
Change-Id: Ie7203e9d92e5971de6c2730ff847f351e5641c9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128178 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-09Qt use platform-independent visibility functionsJan-Marek Glogowski
show() isn't just some conveniently renamed setVisible(true), but presents a window in a platform-dependant way, which - at least for WASM - means maximized and without a title bar. This is not really expected and WASM can also use multiple windows. Change-Id: I3fbaec1dfc2cd32bf3a90a94dcee01ebc88e58c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128179 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-07VCL move platform code from mouse.cxx into pluginsJan-Marek Glogowski
... by moving it into ImplCreate(DragSource|DropTarget). The existing Create* variant now checks for headless mode and the IsRunningUnitTest flag, before creating the platform variants. There are two small helpers to initialize either X11 or Ole based UNO DnD interace implementations. Unfortunatly Windows requires to move two dtrans header files, but at least any other changes are minimal. Change-Id: Id79459ad71a26243b1c9cb1fe38ab236b0ab8fa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128049 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-05vcl: move drawBitmap, drawMask functions to SvpGraphicsBackendTomaž Vajngerl
Also fix the QTSvpGraphics that uses a special drawBitmap (renamed to drawBitmapBuffer) call and moved in also to SvpGraphicsBackend. Change-Id: Ic50630ba23e35a62ea3d5aaa0955a7666f2bca68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127980 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-12-21tdf#131467 Qt set default position on first resizeJan-Marek Glogowski
Setting the position in Show() is too late, because LO will try to set the mouse pointer to the default button, if configured. That obviously needs the window position. And also take the menubar offset into account. Change-Id: Ia280539c082ff6f675966869fb6643a41a17d696 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127154 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-21Qt use asChild for pointer positioningJan-Marek Glogowski
.. and refactor some variable names. Change-Id: I7d31a7a377f614bdd78f8d09852a2eda0cc47442 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127153 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-10Revert "Re-Enable DrawTransformBitmapExDirect for render backends"Armin Le Grand
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7. Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-07Re-Enable DrawTransformBitmapExDirect for render backendsArmin Le Grand (Allotropia)
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the system-dependent implementations/fast-path for DrawTransformBitmapExDirect and it's implemenations, except for Skia. This means that the current backends for Windows/Mac/Cairo/headless/Qt5 have to do expensive pixel operations when a Bitmap is 'really' transformed (rotate/shear) since some time. The nine implementations using ::hasFastDrawTransformedBitmap (grep for it) all return false, except the Skia one. Since HasFastDrawTransformedBitmap() uses that and itself is used in the very central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that fast-path shall/can be used at all, it was *no longer used* - except for Skia - what makes Skia definitely performing better with transformed Bitmaps, or the other way around - the others worse. HasFastDrawTransformedBitmap() is used in only two places, the second is in the canvas helper to decide if to try to use that fast-path for presentation rendering. A method at OutputDevice to see if that fast-path is implemented is therefore currently needed, but for the canvas helper only. Since this will/should be converted to primitive usage (hopefully) anyways, nine impementations calling these virtual functions often and the danger to produce a mismatch/ error beween implementations of hasFastDrawTransformedBitmap and drawTransformedBitmap (as happened here, but can also happen when someone adds or removes an implementation) I looked for a way to solve that differenly and more safe. Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's success I take this as base to implement a buffered test directly at SalGraphics, also directly set a local flag to detect that functionality if DrawTransformedBitmap is used anyways before the test is/would be needed. Combined wih that small test to check only if this was not yet used and thus tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will be used at the single necessary location - in the canvas helper. Since that small test direcly uses one of the nine implementations of hasFastDrawTransformedBitmap it is fundamenally more reliable and probably the copy bitmap/writeBack never really used (I tested that it works) due to an earlier use of DrawTransformedBitmap did the check potentially already. I also took a look at the cairo version (since I had this one running here) and ensured that the buffering of the system-dependent form of the Bitmap as cairo surface still works. Regarding the newly introduced fAlpha parameter I want to add some remarks: - It should be called fOpacity to make clear that it describes opacity, defining that if 1.0 == fAlpha means *no* transparency. That word is used in other graphic systems and makes more clear what function it has. It is the opposite of transparency, but works the same. - Currently all implementations of ::drawTransformedBitmap - except Skia where it was implemented - do not use it, but return false. It will in most cases not be too complicated to add/implement it, e.g. for cairo anyways a transparency surface will/is created, fAlpha can just be merged in, and the criteria for buffering that may be extended to remember for which value (if at all) of fAlpha that was prepared. I strongly recommend implementing these for our main graphic backends. - The primitive renderer uses another more general way to add an extra alpha channel to paint when needed - it draws the content (any content) that needs to be transparent to a buffer and then that buffer using the intended transparency. This is discussable since may be more expensive, but more general and keeps the interface less complex. We can see here that adding that complexity to the existing interface at OutputDevice makes the implementations more complex what might be the reason his was only implemented for one of nine backends. When adding something like this and extending the complexity I would prefer that at the same time it gets also *implemented* in all or most or at least most used cases. I want to make clear that from my POV in those cases choosing possible runtime speed over complexity is not always preferable. Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-01Qt fix non-X11 build and introduce CHECK_* macrosJan-Marek Glogowski
Explicitly uses ANY, so it's hopefully easier to read then QT, QT5 and QT6 in the otherwise same macro names. Change-Id: Ie9bbbc858f5f9db5c8b429c7b0d8a897ac6159fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126168 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-19Qt set QPainter AntiAlias hint from SalGraphicsArmin Le Grand (Allotropia)
Change-Id: I1a9e6014ead24b6edff1dbb41b70c809204d01cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125549 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-19tdf#137924 qt (>=5.14): Use proper DPI without requiring window handleMichael Weghorn
For Qt >= 5.14, don't require a window handle to retrieve the screen and then the associated DPI value from that one, but directly use 'QWidget::screen' (introduced in QT 5.14) to retrieve the screen. Previously, no DPI values would be set in case there was no window handle. This makes UI scaling work without having to manually set 'SAL_FORCEDPI' on Wayland. While various UI elements (like e.g. the "Help" -> "About LibreOffice" still look quite broken with the qt5 and kf5 VCL plugins in a Plasma Wayland session (at least on my Debian testing with Qt 5.15.2 and Plasma 5.23), they look OK when using the qt6 VCL plugin with a custom build of qtbase and qtwayland from Qt's "dev" git branches. Change-Id: I5feae46ed86a8b7d3cf92d4a973f7a0f9a9f95de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125507 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-11-18Qt implement QtFont::GetGlyphOutlineArmin Le Grand (Allotropia)
Fixes FontWork with QFont based rendering. Change-Id: I294fe89d2753b6e82a559ff847b44126f9ea3bfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125500 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-17Qt resolve native winId() on demandJan-Marek Glogowski
As for gtk3 in commit ac9789dbb36f45dcc1caf7dd2951353b1574c8ea ("tdf#139609 avoid fetching unnecessary xid under gtk3"). Change-Id: I82b2c22437e5ab957706c25fcc118b28abb07242 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125395 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2021-11-17Qt refactor SystemEnvData setupJan-Marek Glogowski
Change-Id: I900d1079c9a832a9b5170e58ce4e7a8b81d7d01b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125393 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2021-11-11qt (>=5.14): Don't create native window for QWidget in QtFrame::screenMichael Weghorn
For Qt >= 5.14, directly use 'QWidget::screen' (added in Qt 5.14) to retrieve the screen that the widget is on, rather than first retrieving a window handle, which forces a platform-native window to be created. Due to QTBUG-75766 [1], forcing the creation of native windows also leads to mouseMoveEvents not being reliably emitted by Qt, s. commit 0e3c3b842e14b9646d3697cf1266be21359e0f13 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Sat May 11 21:31:33 2019 +0200 tdf#122293 qt5: Use "alien widgets" by default on Wayland for more details. The behaviour described in tdf#122293 started showing up again after commit b00a68a8e19370e106cd76258a3c1825f43613ee Date: Sun Oct 31 02:33:46 2021 +0200 tdf#145363 Qt reparent modal dialogs on show but that just seems to have been a side-effect of 'QWidget::screen' now being called in different ways than previously. [1] https://bugreports.qt.io/browse/QTBUG-75766 Change-Id: Ic11923cef5e704c09494f96b19157372a869ae40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124997 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>