| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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>
|
|
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>
|
|
... 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>
|
|
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>
|
|
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>
|
|
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
|
|
to avoid unnecessarily exporting symbols
Change-Id: I6855894d0166c300ced169e36861f38811baa48d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
FWIW: most places still call FileDialogHelper::Execute instead of
StartExecuteModal. I tested with "Insert >> Text from File...".
Change-Id: I303cc89c97c8fc17015ab7831e6a324ef16a6a0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124512
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Simply said, one can't have two modal dialogs open at the same
parent in Qt. All modal windows must open as a stack, each
parented to the previous one. This is kind of logical.
Unexpectedly Qt totally breaks, if you open two modal dialogs on
the same window. This happens, because the existing paragraph
style dialog and the "sub" "list style" dialog are both children
of their Writer window.
I'm not sure the additionally introduced QWidget-based parent
handling is strictly needed. It seems Ok.
So for every visibility and modality change, we reparent the
Qt widget, either on top of the modal stack or restore the
original LO-based parent. The LO hierachy is never changed!
Change-Id: Id209c9aa67774440089dc50a6648ac293950087a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124500
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
- tested PhysicalFontCollection, noted odd behaviour with search names
and normalization
- moved PhysicalFontCollection.hxx to vcl/inc/font
- moved PhysicalFontCollection into vcl::font namespace
Note that I needed to regenerate the pch file otherwise errors were
generated.
Change-Id: Ifa0c7b871c40687bd15002565d2f7a3e408218f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122036
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
- moved PhysicalFontFace.hxx to vcl/inc/font
- added PhysicalFontFace to vcl::font namespace
- had to regenerate precompiled_vcl.hxx
- tested PhysicalFontFace, with some extensive tests for
IsBetterMatch()
Change-Id: I860022ac244f8a827f6f9cb7ed9018c5d9c328cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121970
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This adds a new "qt6" VCL plugin based on Qt 6.
Building the plugin is enabled by autogen option '--enable-qt6'
(and optionally setting 'QT6DIR' as needed).
Use the 'SAL_USE_VCLPLUGIN=qt6' environment variable
before running LO to select this VCL plugin.
Taking qt6 into account at all relevant places certainly
still requires follow-up changes, but
this builds and runs with a self-compiled
qtbase from the 'dev' git branch as of commit
3ce0672143d2eb3c3809f82998a4d71c5800d77a.
I didn't see anything obviously broken
in a quick run, but didn't test much.
This reuses and shares the qt5 VCL plugin code;
the qt6 headers and sources for now just
'#include' the qt5 ones.
Version checks are used for the code places that
need different handling to be built against Qt 6.
The build system parts in this commit were mostly done by
copying the qt5 equivalents, then adapting as needed.
Some notes on things I came across while porting
to qt6:
1) At least in my self-compiled Qt versions,
'moc' (the meta-object compiler) is located
in the 'libexec' subdirectory in 'QT6DIR', while the
Qt 5 equivalent is located in the "bin" subdirectory
of 'QT5DIR', so the configure.ac check uses the former.
2) moc does not process classes from the included headers.
Since the headers in 'vcl/inc/qt6' just '#include' the ones
from 'vcl/inc/qt5', running moc on the qt6 headers doesn't work,
so moc is currently run on the qt5 headers for qt6 as well
(s. 'vcl/CustomTarget_qt6_moc.mk').
That will have to be adapted in case the qt6 VCL plugin
uses "own" headers instead of just including the qt5 ones
at some point.
3) QX11Extras has been removed from Qt 6.
[1] says:
> Changes to Qt X11 Extras
>
> The QX11Info class has been removed.
>
> Clients that still rely on the functionality can include the private
> header <QtGui/private/qtx11extras_p.h> as a stopgap solution. To enable
> private headers use QT += core-private with qmake, or add a project
> dependency to Qt::CorePrivate with CMake.
I didn't take any closer look, just dropped the use of
QtX11Extras for qt6 for now.
4) XCB_ICCCM is no longer needed.
It is only used in qt5 to workaround a Qt bug fixed in Qt 5.12, s.
commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca
Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de>
Date: Tue Dec 3 08:32:58 2019 +0100
Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP
5) X11-specific code is still used for key modifier handling.
Therefore, still check for the XCB headers when 'USING_X11'
is set in configure.ac, and use a 'QT6_USING_X11' define
(as qt5 uses 'QT5_USING_X11').
6) There's currently no Qt 6 video sink for GStreamer.
As of today, qt-gstreamer is unmaintained and there is no Qt 6 version.
The project's README [2] says:
> 0. Maintenance Notice
> ---------------------
>
> This code is unmaintained. You can use it at your own risk.
>
> If you want to integrate video display in your QML-based UI,
> you should consider using 'qmlglsink', from gst-plugins-good.
> This is a well supported video sink that uses the generic
> gstreamer-gl stack and is in many ways superior to 'qtquick2videosink'
> that is provided by qt-gstreamer. You can use this code as an example:
> https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsink
>
> If you are not interested in using QML in your UI, then you
> may use one of the other elements provided by this module
> (see below). If you do that, it would be helpful to let us
> know that this code is still useful to you. We may consider
> adding these elements in one of the core gstreamer modules.
>
> If you are here for the Qt-style bindings, I'm sorry to disappoint you.
> The alternative is to use the C API, or the GStreamermm C++ API.
> Qt-style bindings are cool, but unfortunately they are very hard
> to maintain because they are written by hand. If you are interested
> in continuing this project, you are welcome to implement a
> generator for them, probably based on GObject-Introspection.
> I am happy to provide directions if you want to pursue such a thing.
Therefore, the Qt video sink handling is qt5-only and the
corresponding handling for GOBJECT (used for the GStreamer
video sink handling) was not taken over for qt6.
This presumably means that video playback in Impress presentations
does not work when using qt6 with they Qt Wayland plugin,
s. tdf#125219 for the corresponding bug for qt5/kf5.
(I did not build the qtwayland module to actually test this, though.
Video playback with the Qt xcb plugin in a Wayland session works.)
[1] https://doc-snapshots.qt.io/qt6-dev/extras-changes-qt6.html
[2] https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README
Change-Id: Ib105ccfb2c3630ec5d5403793a3cd9ba31d85bdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122808
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Rename those to no more include the Qt version number,
since they will be used for the upcoming qt6 VCL plugin
as well.
Change-Id: I49bf362b830e07193dca03524e0d6001d0d191a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122807
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
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>
|
|
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>
|
|
Change-Id: I2f01a8e67c52ece9b434777203aa9fbc9ac8be02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122613
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
'QString QString::fromUtf16(const char16_t *, qsizetype)'
was introduced in Qt 5.3.
The one taking a 'const ushort *' param is deprecated in Qt 6.
Change-Id: I0f2a8ecc5e3dd16aaee55a288c27c3c1d65f87ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122550
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Let 'Qt5AccessibleWidget' derive from 'QAccessibleTableCellInterface'
and implement the most important methods.
This is e.g. one of the steps needed to make Orca announce
the focused cell in Calc.
Since there's no specific XInterface for table cells
make use of the fact that a table cell's parent is a table
and query information from there, similar to how the following
commit does for winaccessibility:
commit 97a88e30e2e084ab860635ff4e0a03442d8a12af
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 8 14:37:53 2021 +0100
tdf#100086 tdf#124832 wina11y: Implement IAccessibleTableCell
Change-Id: I160bc04f3e4fcf7b77723540aba6945b8fdf36ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122395
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
They're unused and at first glance look like they might
be overriding the non-virtual methods
from 'QAccessibleInterface' with the same name that
do something more useful (calling 'interface_cast'
with the corresponding 'QAccessible::InterfaceType'
param).
Change-Id: I9258a5f9386f9a7d23bb35cfa33e55a169eb753e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122394
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
The convention is that we need to add sal/config.h to the start of
files.
This patch is created in preparation of a patch I have queued to test
and move PhysicalFontFace to vcl::font namespace.
Change-Id: I15dd24d7f01e077d407ac192a0413d796517eb72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122228
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Nothing checks the result and a lot of code just uses it.
Change-Id: I1a672e98d42673fd684538ead831622f6a14e9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120761
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
because this is often on a hot path, and we can avoid the splitting and
joining of strings like this.
Change-Id: I2a24a123a64b762fd0741c45eaca3ad4bdd5580d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119884
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
This bug was "unveiled" by commit
963f252cd1ea9c268a6ced68a3454b10cbee1a89 ("Qt5/KF5 get rid
of unneeded own grahics handling"). I'm not sure why I ever came
up with that code. Eventually we would need a paint event, but at
least changing the theme correctly updated LO UI, so that seems
to be handled correctly.
Change-Id: I528b551180be184427eeeeeb2977e2b7da073ce6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119237
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I0bad93927248e5d8d19a69661a1b243e55791fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If927a834f5b5d722fc36cce40e161597af6234ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116972
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0701b15a28ab3583586c0c8018c511e100b41a93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114948
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Rather use a proper alpha channel if we need transparency.
This is another small step towards merged alpha in our vcl
layer.
I suspect the intent in a lot of this code was to save memory.
Which have been a thing way back then, but these days our
backends mostly end up doing a copy-and-convert to a real
alpha channel anyway, so the existing code is actually
now a pessimisation.
Change-Id: I4a2bcbb2f76b841f05bc00580f364492829c69de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114808
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Adds the used font backend and the QPA platform name, so we don't
need to ask / verify all time (and less chance of wrong info).
Examples:
- qt5 (qfont+xcb) => QFont text rendering + X11 backend
- kf5 (cairo+wayland) => Cairo text rendering + Wayland backend
Change-Id: I1102dd6d83b0ed48318ac5c31c8ca09d4fdd73eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113945
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This was hiding tdf#141623, when I decided to implement the override
to run the kf5 VCL plugin with the qfont text rendering.
Change-Id: Id1fcd363bd77a756cb27e3a171c872ce792da5ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113956
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...apparently since 615ceb107e9faf01b568b0a2440a3f09c8f88ca6 "vcl: remove 4-bit
bitmap support from qt5 backend"
Change-Id: I8e130b6e1a2439476e6bdf934a3c380d4599c23e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113743
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is an effort to make SalGraphicsImpl mandatory for all
backends.
This introduces Qt5GraphicsBackend: a subclass of SalGraphicsImpl,
which now handles graphic rendering.
Change-Id: I42aece59d0c692ca1dd33e30f31c5bcceab02008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113734
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This changes all backends to use PixelFormat as the input to
the SalBitmap::Create method (and all the backends). This is the
first part as we need to make sure to also limit the use of
GetBitCount method and also use of it in SalGraphics.
Change-Id: I8d2b6adfcb8fe3dd78010538411f338c9a1c3996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113603
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
We removed 4-bit support for bitmaps, but the qt5 backend still has
(special) support this bitmap format, which now can safely be
removed and make the backend a lot simpler.
Change-Id: I12309909a9ee3079cef7c4e59154ac48151e18d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113619
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I92e9db7abdfe5912335fd94e42422e8556d71091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111769
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This allows the VCL backends the apply the extra alpha transformation
as it sees fit, rather than it being done manually elsewhere (and
even if the backend doesn't implement it, at least do it in one
place in the function).
With the document from tdf#136223, going from slide 2 to slide 3,
this easily saves 10-30% of CPU cycles. As an additional bonus,
using AlphaMask::BlendWith() rather than AlphaMask::Replace()
makes edges of shapes noticeably more smooth.
Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
At least with Skia this is faster than GraphicObject trying
to handle it manually, even in raster mode.
Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
this just changes the Get/Set methods, the constructor and internal
representation of Color is not changed.
Change-Id: Idb6e07cc08bbaa5bd55b6bd4b585e648aef507b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is in the spirit of tdf#108151, based on the information Qt
provides for the IM setting. I don't know how correct it is,
especially looking at Caolans comment 3 in that bug report
regarding the assumed validity of GtkIMContextInfo. OTOH it seems
to work well enough for my simple tests.
Some BG info: while the QInputMethod object is a global one, it's
"bound" to the focused window. So you'll get change events, when
you change the input window, with the correct IM settings for the
new one, be it a real window or just the menu bar.
To prevent unneeded flushes of buffers and language lookup, this
caches the current IM language of a window.
The language is not affected just by changing keyboard mappings,
which the bug reporter requested! It just works with a configured
input method, like fcitx or ibus (which can have keyboard mappings
too, which work correctly).
Change-Id: Ia9133edf4d1ce77d29adbfe57c180db15db0a560
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106354
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
