| Age | Commit message (Collapse) | Author |
|---|
|
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: I12c88016740d94d4f2fcf0e1f83658dd2c3922a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102912
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This adds handling for the background color when
drawing controls in the qt5 VCL plugin, as was done
in the following commit for the gtk3 VCL plugin:
commit 2c9052802ea411dffbf5906c4914611fcbfbc6a5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Aug 24 17:18:03 2020 +0200
tdf#136094 Handle background color in drawNativeControl
For some reason, the proper background color is not passed
to 'Qt5Graphics_Controls::drawNativeControl' for the
multiline edit in the sample document ('rBackgroundColor
is 'COL_AUTO' instead), while it works as expected for the
gtk3 case. Setting a color inside
'Qt5Graphics_Controls::drawNativeControl' for testing purposes
made that one show up, so the problem is elsewhere.
I'll create a separate bug report to keep track of this and
reference it in tdf#136094.
Change-Id: I4df0d803c017422e0a2f5c05c6b4d2d8a8fa68c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102911
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Make gtk3's 'GtkSalGraphics::drawNativeControl'
take into account a control's background color,
if any is explicitly set:
Set background/fill color (in 'Edit::ApplySettings')
also for the case where the control is drawn "natively",
but don't draw the background in the generic 'Window::Erase'
method for the case of native drawing; instead handle it when
drawing the control itself.
This adds an additional parameter to pass the background color to the
relevant '{d,D}rawNativeControl' methods (defaulting to 'COL_AUTO')
and implements the required handling to apply the background color
for the gtk3 case.
qt5/kf5 will probably be handled in an upcoming commit as well.
Windows as well as the "gen" VCL plugin were not affected by the
issue, so remain unchanged and just ignore the new parameter.
In a quick test on on macOS, the rendering of the controls
in the sample doc was broken beyond just the missing background
colors (s. screenshot attached to tdf#136094); the behavior there
also remains unchanged by this patch, the new parameter is ignored
for now.
Change-Id: I01923a504fea2367ae96032104f09099e35f410e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101284
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
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>
|
|
This is a preparatory patch for merging the initial fix for
tdf#127687, the Qt5 HiDPI scaling support, and generally to make
the style handling code a little bit more readable.
It includes:
* Moving all lcl_ Qt5Graphics_Controls functions into the class as
private functions without lcl_ prefix.
* Add three additional helpers - pixelMetric, sizeFromContents and
subControlRect - to cut down boilerplate QApplication::style()->
prefixes for the style calls everywhere.
* Drop the superfluous Qt5Frame::TriggerPaintEvent functions.
* Drop the single, broken maGeometry.nTopDecoration filling.
* Split some very long lines of nested call code by using some
intermediate variables.
* Move a Qt5Data include from hxx into cpp
Change-Id: Iae1bfafd14c4163447f3d55e2307f0f617e68a0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89751
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Mark some stuff SAL_DLLPUBLIC_RTTI in
include/vcl/metaact.hxx
in order to make ASAN happy.
Change-Id: I97febe0968bf58b9cbe60ce647f0ada25e6f4bb0
Reviewed-on: https://gerrit.libreoffice.org/84202
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Basically reverts commit 3f0dbdd61df ("Draw button focus so that
it doesn't obscure the actual button") and declares qt5 doesn't
support an extra native focus for a button.
LO's own "ant" focus is prevented by Qt5Data::Qt5Data():
pSVData->maNWFData.mbNoFocusRects = true;
pSVData->maNWFData.mbNoFocusRectsForFlatButtons = true;
Change-Id: Ifdce615cac92f69b008780cf986cdfd0915ccd14
Reviewed-on: https://gerrit.libreoffice.org/75415
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
I don't understand why WidgetDrawInterface, which is basically a
copy of the SalGraphics native controls interface, duplicated it,
instead of cleaning things up.
The whole commit message of commit 8fcfa3853a81, which added this
code, is just: "custom widgets: Custom Widget Themes". That's it.
So this patch does, what the original one skipped: replacing the
SalGraphics interface with the WidgetDrawInterface. One result is
the addition of handleDamage to SalGraphics to correctly handle
the damage done by a custom widget theme to the underlying
SalGraphics implementation.
Change-Id: I5fda1a64b28e6560fb3c62e02b6dcda827f698e2
Reviewed-on: https://gerrit.libreoffice.org/74118
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Nothing KDE specific left in there, so just merge it.
Change-Id: I11712961f2abc5e11256a158300ec6b388f9ee44
Reviewed-on: https://gerrit.libreoffice.org/73680
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I8d26503d68ed3dcc37574e247de3eae02b4e0f53
|
|
The native painting code in the kde5 backend is Qt based only.
To prevent multiple inheritance, it's moved into an extra class
and just leaves the backend specific QImage blitting in the
specific SalGraphics implementation.
Change-Id: I3d5f58f42a37966794541fe1214c1b9557376a98
Reviewed-on: https://gerrit.libreoffice.org/58652
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
