Age | Commit message (Collapse) | Author |
|
`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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
Change-Id: I79c7008655f22737f92a4a6430f1380e81c1c386
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132833
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
Change-Id: I988cabf4c07d5efd298c53b696f6d114f4f594bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132637
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
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>
|
|
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
|
|
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
|
|
Change-Id: I50b2ffeb1b6bb490c14a307152634cc51022a426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132276
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: I6bfbd0cb5c2eac60bdac69fd862154fb2f537a89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132030
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: I86f720a23dd9d400d39d9606e073b483850a9df2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131153
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib4e6f06a5cdac1ac47eb3d273ca103fb5081550e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130361
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I34d813ced29a591b0a6652eeb1271a978980bba5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130359
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I4165c72ddd6370c8fe7faf55f9db831359f6f8a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128923
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ie7203e9d92e5971de6c2730ff847f351e5641c9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128178
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
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>
|
|
... 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>
|
|
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>
|
|
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>
|
|
.. 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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I1a9e6014ead24b6edff1dbb41b70c809204d01cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125549
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
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>
|
|
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>
|
|
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
|
|
Change-Id: I900d1079c9a832a9b5170e58ce4e7a8b81d7d01b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125393
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
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>
|