Age | Commit message (Collapse) | Author |
|
Store the origin of the Qt5FontFace and therefore the type of the
font ID and use either QFont::fromString or QFontDatabase::font to
generate the correct QFont instance.
Interestingly the QFont::fromString worked with the minimal font
string, ignoring the font style, but now fails with error messages
when including the point size. Guess Qt supports partial font
strings, as long as they match the segment types from the start.
Change-Id: I6b30423a5ae9abd8ee50d6087a3ec61d85f6320f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104652
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I0835f66b8ce478f645ca2e5c376bef9a0740c8c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104637
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This was uncovered by the fix for tdf#136555. The current color
for the start center button bar is too dark.
Regressed-by: a927e0964ba0442d53fffb22c577e54bcf183ed7
Change-Id: I36356117f03255cfbf1fa24a6391cb81cf1883db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104578
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I6a4a0f90239686ff1c94e1a550540223324184e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104540
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I768aa9bd87913bc20351fb631a6326fe01f777b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103748
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This renames AntialiasingFlags::EnableB2dDraw to just Enable,
and the AntiAliasB2DDraw names to just AntiAlias. This is
in preparation for a second commit that will actually separate
the AA and B2D functionality of these flags.
Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I137019c15d3ee2886ad1bd53e671a89990891481
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103506
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...with qt5-qtbase-devel-5.15.1-1.fc33.x86_64 on Fedora 33:
> ~/lo/core/vcl/qt5/Qt5Widget.cxx: In member function ‘virtual void Qt5Widget::wheelEvent(QWheelEvent*)’:
> ~/lo/core/vcl/qt5/Qt5Widget.cxx:144:59: error: ‘QPoint QWheelEvent::pos() const’ is deprecated: Use position() [-Werror=deprecated-declarations]
> 144 | fillSalAbstractMouseEvent(rFrame, pEvent, pEvent->pos(), pEvent->buttons(), nWidth, aEvent)
> | ^
> ~/lo/core/vcl/qt5/Qt5Widget.cxx:196:5: note: in expansion of macro ‘FILL_SAME’
> 196 | FILL_SAME(m_rFrame, width());
> | ^~~~~~~~~
> In file included from /usr/include/qt5/QtGui/QFocusEvent:1,
> from ~/lo/core/vcl/qt5/Qt5Widget.cxx:32:
> /usr/include/qt5/QtGui/qevent.h:225:19: note: declared here
> 225 | inline QPoint pos() const { return p.toPoint(); }
> | ^~~
But for one the types used by the other calls of the FILL_SAME macro do not have
a position member function, so stop using the macro and spell it out explicitly
here. And for another, QWheelEvent::position returns a QPointF instead of a
QPoint, so need to convert that with toPoint. And for a third,
QWheelEvent::position is only available since Qt 5.14 according to
<https://doc.qt.io/qt-5/qwheelevent.html#position>.
Change-Id: I6e64fc9717a9f5a85303f070c6a1b66ed21ec458
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103475
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...with qt5-qtbase-devel-5.15.1-1.fc33.x86_64 on Fedora 33:
> ~/lo/core/vcl/qt5/Qt5AccessibleWidget.cxx: In function ‘QAccessible::Relation {anonymous}::lcl_matchUnoRelation(short int)’:
> ~/lo/core/vcl/qt5/Qt5AccessibleWidget.cxx:138:20: error: ‘constexpr QFlags<T>::QFlags(QFlags<T>::Zero) [with Enum = QAccessible::RelationFlag; QFlags<T>::Zero = int QFlags<QAccessible::RelationFlag>::Private::*]’ is deprecated: Use default constructor instead [-Werror=deprecated-declarations]
> 138 | return nullptr;
> | ^~~~~~~
> In file included from /usr/include/qt5/QtCore/qglobal.h:1304,
> from /usr/include/qt5/QtCore/qnamespace.h:43,
> from /usr/include/qt5/QtCore/qobjectdefs.h:48,
> from /usr/include/qt5/QtCore/qobject.h:46,
> from /usr/include/qt5/QtCore/QObject:1,
> from ~/lo/core/vcl/inc/qt5/Qt5AccessibleWidget.hxx:14,
> from ~/lo/core/vcl/qt5/Qt5AccessibleWidget.cxx:20:
> /usr/include/qt5/QtCore/qflags.h:123:80: note: declared here
> 123 | QT_DEPRECATED_X("Use default constructor instead") Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}
> | ^~~~~~
Change-Id: Ic0c113fe208764e8bc0b9c3fbf7358d6af4000ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103474
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
This is basically just some refactoring. Most interestingly the
MacOS used to work with 257 glyphs. I couldn't find any
explaination for the 256 glyph limit. Sadly the PrintFontManager
is out of scope. That needs more inspection.
Change-Id: Ibfa0e905f5efeb7d4a609884d64b4ed2615a9d3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102688
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
|
|
Basically implement it the same way then Windows and MacOS.
Change-Id: I643581af49aeb9274505e90e12acbe5bcf0c98fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102687
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Since removed code in the previous commit is primary used in
CreateFontSubset and GetGlyphWidths, you have a high chance, that
the CMAP was already used for displaying a font, so it's already
decoded and can be forwarded. Also the lookup should be faster in
general this way.
Change-Id: Icf4d8a1a84ff6ccdaccb7e870abe5df3837f9541
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102686
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
|
|
This makes GetFontCapabilities and GetFontChatMap members of the
PhysicalFontFace. These are implemented in all the real font face
classes anyway. Also provide dummies for the PDF buildin fonts.
Change-Id: Icb8cb14480ce1e020977b8f69892095d787982ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102683
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jenkins
|
|
Implemented like on Windows and MacOS.
Change-Id: Ib0d5125b77770446d4ca01efbb7c54d9c6bdb2e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102594
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Not sure if this is strictly needed, and obviously it will be
"wrong" for a sub font containing just some of the glyphs, but
since other backends also do this, follow suit.
Change-Id: Ib83542b685b38d800d09b7a19780f9ac619c7ad0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102487
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
We're working on the font level here, not the layouting. So use
LO's TTF functions to read the glyph widths of the font directly.
Change-Id: Ib3bd59a91aa08ca9e629a45ba7539d757bef2c1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102488
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
'QAccessibleCache::insert' from the Qt library has a
'Q_ASSERT' checking that the corresponding 'QObject' for
which the 'QAccessibleInterface' provides information
is actually the same as the object passed as a parameter:
QAccessible::Id QAccessibleCache::insert(QObject *object, QAccessibleInterface *iface) const
{
// ...
QObject *obj = iface->object();
-> Q_ASSERT(object == obj);
However, 'Qt5AccessibleWidget::object' so far was always returning
'nullptr', triggering this assert when using a Qt version
not built with 'QT_NO_DEBUG'.
To fix this, remember and return the object as needed.
Change-Id: I4015b4c37aa8a073b02465df580a7235884e6cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102196
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>
|
|
This abstracts the just refactored vcl::TrueTypeFont class, so the
Qt5 backend can provide it's own QRawFont based font table access.
Change-Id: Ic71bc95bc8fe39bc7a32086d4adc78cfa00d15be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100718
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I271cc67ecf34acbf0edbda960e33315fb6a1f9dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100041
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
So I tested a lot of stuff, but missed the missing focus for new
dialog windows :-( This is IMHO a far worse problem, then the
popup, so just revert the fix.
This reverts commit 06fb3e7b7f1079c276ad2f048cd94299b4bd7006.
Change-Id: I391ad91ded90e4518ab024572d3f182769b0bcda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99451
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Report some of the stuff we can in AnyInput. And instead of
posting an event, just use QAbstractEventDispatcher::wakeUp().
Change-Id: I020a71eca7208030ddbfcd2b16d9bc4ceff315e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/73676
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I7559ab5c98a22e315549b5dfc651e937697cac22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97742
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I missed that code in the HiDPI patch. Instead of some fixed 25px
size, use the real content size and ask the QStyle for the real
size.
Change-Id: I227190baab2c1716aa40ef6d16d55dbded0830cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97538
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
I investigated the state of isWindow() and the SalFrameToTop
flags for the detached find toolbar (tdf#126607) and the Impress
presentation and the tabbed "page size" drop-down and all had the
same status (isWin: 1, flags: 12). Than I had a look at the gtk3
implementation, which just handles focus requests, if the widget
is already mapped (gtk_widget_get_mapped).
So I also dumped the visibility as the nearest equivalent in Qt to
the X11 mapped state, and that was different. In the end Qt now
also just handles the focus for already visible widgets, like
gtk3, which works for all the cases I tested (incl. tdf#125517).
And omiting either activateWindow or setFocus breaks some cases...
and I still don't understand the GrabFocusOnly flag, which is just
handled in the X11 backends at all...
Note: this doesn't happen with 7.0+, because the weld'ed version
of that control (commit 3afc718eddcd81232392d46fccc24b8ec626c8df
"rework PageSizePopup to be a PopupWindowController") doesn't
expose this bug (and also doesn't support mouse-over highlight).
Change-Id: Id085732f6a52bbc69ed47fbd3d57454756a03121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97549
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Adds Qt5Widget::fillSalAbstractMouseEvent to set the common
Sal*MouseEvent members. While the member functions of QMouseEvent
and QWheelEvent have the same name, they aren't shared via
QInputEvent, so this uses a small FILL_SAME macro for less code,
Change-Id: I3e5aa52b1bf2774251d97534ce0106a27ef5899b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97343
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Just like all the other events, the mouse wheels X position must
be mirrord in LO RTL mode.
Change-Id: I28e8da0455d941f42f869b08edcdbe570de366c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97338
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Ib2904066edd371229c5daa09b81b210e99853895
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96251
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The title is self-explanatory.
The QIcon::themeName() actually uses Qt Platform Abstraction plugins, i.e.
it's aware of KDE preferred icon theme via Qt Plasma integration module.
(note that it is _currently_ broken due to KDE bug
https://bugs.kde.org/show_bug.cgi?id=402172, which causes themeName to
return empty string; however, it's being worked on)
Change-Id: Ibc7cf9ee9ae73b492046219487760561d7d2ea45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94691
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <bubli@bubli.org>
|
|
Change-Id: Ie8fa026becb1899e466fb0e7dbb987290788aaf2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96207
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
and thus SystemFontData
Change-Id: I563a6b7c251194cd73c6b0026d4ae8485a057b28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94740
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I05b02a2f8b4b9091c7de0f7e98409d5b608ed250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94610
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use new accessibility scroll type compatible with IAccessible2.
Change-Id: I0967d1c56425e1e860db34f4b9c17427e531fe02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93636
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
For backends that do the object-to-device coordinates transformation
directly, it's necessary to also convert the size of line width.
But simply multiplying it with the matrix can also rotate the line
width "vector", making it e.g. negative. So don't use just the X
coordinate, use vector length for the transformation, which is ok.
In fact it doesn't even make sense to treat width as a vector, because
a width simply is not a vector (and for this reason it's also not
actually used).
Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
It is used to clear "Version" listbox before adding new items.
Change-Id: I4cb9557c8f56d80c1dfac68dc2b5b45b5c69c2f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91982
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This is maybe a Qt bug. Calling QClipboard::setMimeData from
Qt5Clipboard::setContents after a previous call to
QClipboard::clear results in a clipboard ownership failure.
In a terminal you'll see: "QXcbClipboard::setMimeData: Cannot set
X11 selection owner".
Calling Application::Reschedule() after the clear() doesn't help.
The result is a de-sync between the LO's clipboard state and the
real clipboard state, which will lead to a crash on LO shutdown.
I'm not sure this fix is correct. Maybe this could also be handled
by some X11 flush operation. But it's the only working solution I
could find: don't clear, if LO re-claims the ownership later.
I tried to reproduce the ownership error by modifying the Qt
fridgemagnets example, adding some QClipboard::clear and
QClipboard::setMimeData calls to the drop handling, but couldn't
reproduce. Maybe the dynamic Qt5MimeData object is also involved.
Change-Id: I32b6575a78a4b10a2e2b7b189303ab3a40dc69ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90990
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.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>
|
|
Change-Id: I58ce75e711504553c8fc606382866754286f1aa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89313
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
With the handover of transformations to line
draw calls it is no longer feasible to detect
and prepare LineWidth stuff when the old
office definition for hairlnes is used, a
line width of zero. It was managed in the
system-independent part, but now may have to
be prepared in logic and not discrete (pixel)
coordinates. To do so, find and cleanup all
places where 1/1.0 was used as hairline line
width. Adapt all seven graphic subsystems to
handle the line width == 0/0.0 cases
accordingly. Test as good as possible.
Change-Id: I2badc045474dcd51612e50597b8406a55d9dc863
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90057
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
This ignores the *_DONTKNOW and _FORCE_EQUAL_SIZE values, except
for the stretch, where we map DONTKNOW to QFont::AnyStretch.
Change-Id: Ifdf55e798566681852ad4b585f4aeb0ebfbd1cf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89884
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Adds conversion functions for VCLs FontWeight, FontWidth and
FontItalic to Qt5FontFace and remove the partial "switch"
tables from KF5SalFrame.
And correctly handle the FontWidth in Qt5Font as the stretch
value, so the default font in qt5 gets the correct stretch and
doesn't look bold.
Change-Id: I698986416dff13e6dfaf9dfa7f95851b89e9137d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89813
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>
|
|
Only call the SalEvent::ExtTextInput callback for key input events
if their text is longer than one character, in which case treating them
as SalEvent::KeyInput would produce incorrect results, given that only
the first character is set as the SalKeyEvent's mnCharCode below
(s.a. tdf#124118).
S.a. commit 61c8324394c690ced18ce692ab6d29c8031ad1a8
("#88063# fixed event handling for redflag", 2001-06-12)
which made events with text longer than 1 unicode char
to be handled by SalEvent::ExtTextInput for the gen VCL plugin even
if not in preedit mode.
Process other key events by calling SalEvent::KeyInput callback, which
e.g. makes shortcuts involving non-Latin characters (tdf#130071) and
auto-insertion of non-breaking spaces when typing French text
(tdf#127815) work.
The gtk3 and gen VCL plugins also use the length of the text as one
criterion to make a disctinction of whether to call SalEvent::ExtTextInput
or SalEvent::KeyInput, s. GtkSalFrame::IMHandler::signalIMCommit and
X11SalFrame::HandleKeyEvent. Those also take into account whether
in preedit mode, but for the qt5 case, input method events when using
e.g. ibus are handled in Qt5Widget::inputMethodEvent and the
Qt5Widget::handleKeyEvent code path is not used anyway.
Change-Id: I2f8925ea26a4fb5419226265c579242889e2a506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89663
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Qt5Frame::GetPointerState expects the cursor position relative to
the frame position.
Change-Id: Icaf7dcd8fc80d712f5138a9f9b843ccf345c5543
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89244
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
If there is no QApplication, we can ignore the GUI thread.
Change-Id: I0d2faf4799d493ad0b6074b40242c443d4bc43dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89241
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|