2024-11-18 09:33:05 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; fill-column: 100 -*- */
|
2018-08-06 17:22:29 +02:00
|
|
|
/*
|
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
|
*
|
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
*
|
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
|
*
|
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <vclpluginapi.h>
|
2019-06-16 14:19:09 +00:00
|
|
|
#include <WidgetDrawInterface.hxx>
|
2018-08-06 17:22:29 +02:00
|
|
|
|
|
|
|
|
#include <memory>
|
|
|
|
|
|
2019-06-07 22:20:53 +02:00
|
|
|
#include <QtGui/QImage>
|
2018-08-06 17:22:29 +02:00
|
|
|
#include <QtGui/QPainter>
|
|
|
|
|
#include <QtGui/QRegion>
|
2019-06-07 22:20:53 +02:00
|
|
|
#include <QtWidgets/QPushButton>
|
2020-02-29 12:43:32 +01:00
|
|
|
#include <QtWidgets/QStyle>
|
|
|
|
|
#include <QtWidgets/QStyleOption>
|
2018-08-06 17:22:29 +02:00
|
|
|
|
2021-09-28 15:02:47 +02:00
|
|
|
class QtGraphicsBase;
|
tdf#127687 Qt5 introduce basic HiDPI scaling
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>
2020-02-29 13:39:29 +01:00
|
|
|
|
2021-09-28 15:02:47 +02:00
|
|
|
class QtGraphics_Controls final : public vcl::WidgetDrawInterface
|
2018-08-06 17:22:29 +02:00
|
|
|
{
|
|
|
|
|
std::unique_ptr<QImage> m_image;
|
|
|
|
|
QRect m_lastPopupRect;
|
2021-09-28 15:02:47 +02:00
|
|
|
QtGraphicsBase const& m_rGraphics;
|
2018-08-06 17:22:29 +02:00
|
|
|
|
|
|
|
|
public:
|
2021-09-28 15:02:47 +02:00
|
|
|
QtGraphics_Controls(const QtGraphicsBase& rGraphics);
|
2018-08-06 17:22:29 +02:00
|
|
|
|
2019-06-16 14:19:09 +00:00
|
|
|
QImage* getImage() { return m_image.get(); }
|
2018-08-06 17:22:29 +02:00
|
|
|
|
2019-06-16 14:19:09 +00:00
|
|
|
bool isNativeControlSupported(ControlType nType, ControlPart nPart) override;
|
|
|
|
|
bool hitTestNativeControl(ControlType nType, ControlPart nPart,
|
|
|
|
|
const tools::Rectangle& rControlRegion, const Point& aPos,
|
|
|
|
|
bool& rIsInside) override;
|
2018-08-06 17:22:29 +02:00
|
|
|
bool drawNativeControl(ControlType nType, ControlPart nPart,
|
|
|
|
|
const tools::Rectangle& rControlRegion, ControlState nState,
|
2020-08-24 17:18:03 +02:00
|
|
|
const ImplControlValue& aValue, const OUString& aCaption,
|
|
|
|
|
const Color& rBackgroundColor) override;
|
2019-06-16 14:19:09 +00:00
|
|
|
bool getNativeControlRegion(ControlType nType, ControlPart nPart,
|
|
|
|
|
const tools::Rectangle& rControlRegion, ControlState nState,
|
|
|
|
|
const ImplControlValue& aValue, const OUString& aCaption,
|
|
|
|
|
tools::Rectangle& rNativeBoundingRegion,
|
|
|
|
|
tools::Rectangle& rNativeContentRegion) override;
|
2020-02-29 12:43:32 +01:00
|
|
|
|
|
|
|
|
private:
|
tdf#150451 Fix borders in Editbox controls (kf5)
The bounding rectangle calculated for an Editbox in
QtGraphics_Controls::getNativeControlRegion was not
always enough to accommodate content and the borders.
The KDE Breeze does not draw any borders if the total
height of the bounding rectangle is smaller than the
minimum size needed for content + frame at top and bottom,
s. Style::drawFrameLineEditPrimitive in the Breeze
style [1].
Therefore, ensure a minimum height of that size.
The Breeze style also considers the type of the
passed widget when retrieving the frame width using
QStyle::pixelMetric [2], so pass a dummy `QLineEdit`
in order to get the actual frame width of 6
that the Breeze style uses for line edits, rather
than the default value of 2 that is returned when not
passing any widget.
Just do that for the minimum size calculation for now
and not everywhere, because the handling for edit boxes
here in the qt VCL plugins and in the calling code
currently does all kinds of "interesting" things like doing
extra size adjustments or passing the content rect where the
bounding rect would be expected,...
Ideally this should be cleaned up in the callers and all
platform integrations in a follow-up commit
to adhere to what the doc in vcl/inc/WidgetDrawInterface.hxx
says, but this here keeps it working with existing code for now.
(s.a. discussion in the Gerrit change for more details)
Tested using various scaling factors: 1, 1.25, 1.5, 1.75 and 2.0.
[1] https://invent.kde.org/plasma/breeze/-/blob/144ea45018d28758db07afd987d97318d56c4981/kstyle/breezestyle.cpp#L3527
[2] https://invent.kde.org/plasma/breeze/-/blob/144ea45018d28758db07afd987d97318d56c4981/kstyle/breezestyle.cpp#L555
Co-authored-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: If8cb4794c7f3ce1be4d1ee421c9c27ad5adf5da2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146516
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2023-02-02 15:27:37 +00:00
|
|
|
static int pixelMetric(QStyle::PixelMetric metric, const QStyleOption* option = nullptr,
|
|
|
|
|
const QWidget* pWidget = nullptr);
|
2020-02-29 12:43:32 +01:00
|
|
|
static QSize sizeFromContents(QStyle::ContentsType type, const QStyleOption* option,
|
|
|
|
|
const QSize& contentsSize);
|
|
|
|
|
static QRect subControlRect(QStyle::ComplexControl control, const QStyleOptionComplex* option,
|
|
|
|
|
QStyle::SubControl subControl);
|
tdf#127687 Qt5 introduce basic HiDPI scaling
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>
2020-02-29 13:39:29 +01:00
|
|
|
static QRect subElementRect(QStyle::SubElement element, const QStyleOption* option);
|
2020-02-29 12:43:32 +01:00
|
|
|
|
2020-09-17 11:45:45 +02:00
|
|
|
void draw(QStyle::ControlElement element, QStyleOption& rOption, QImage* image,
|
2020-09-17 09:42:38 +02:00
|
|
|
const Color& rBackgroundColor, QStyle::State const state = QStyle::State_None,
|
|
|
|
|
QRect rect = QRect());
|
2020-09-17 11:45:45 +02:00
|
|
|
void draw(QStyle::PrimitiveElement element, QStyleOption& rOption, QImage* image,
|
2020-09-17 09:42:38 +02:00
|
|
|
const Color& rBackgroundColor, QStyle::State const state = QStyle::State_None,
|
|
|
|
|
QRect rect = QRect());
|
2020-09-17 11:45:45 +02:00
|
|
|
void draw(QStyle::ComplexControl element, QStyleOptionComplex& rOption, QImage* image,
|
2020-09-17 09:42:38 +02:00
|
|
|
const Color& rBackgroundColor, QStyle::State const state = QStyle::State_None);
|
|
|
|
|
void drawFrame(QStyle::PrimitiveElement element, QImage* image, const Color& rBackGroundColor,
|
|
|
|
|
QStyle::State const& state, bool bClip = true,
|
tdf#127687 Qt5 introduce basic HiDPI scaling
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>
2020-02-29 13:39:29 +01:00
|
|
|
QStyle::PixelMetric eLineMetric = QStyle::PM_DefaultFrameWidth);
|
2020-02-29 12:43:32 +01:00
|
|
|
|
|
|
|
|
static void fillQStyleOptionTab(const ImplControlValue& value, QStyleOptionTab& sot);
|
tdf#127687 Qt5 introduce basic HiDPI scaling
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>
2020-02-29 13:39:29 +01:00
|
|
|
void fullQStyleOptionTabWidgetFrame(QStyleOptionTabWidgetFrame& option, bool bDownscale);
|
|
|
|
|
|
|
|
|
|
enum class Round
|
|
|
|
|
{
|
|
|
|
|
Floor,
|
|
|
|
|
Ceil,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int downscale(int value, Round eRound);
|
|
|
|
|
int upscale(int value, Round eRound);
|
|
|
|
|
QRect downscale(const QRect& rect);
|
|
|
|
|
QRect upscale(const QRect& rect);
|
|
|
|
|
QSize downscale(const QSize& size, Round eRound);
|
|
|
|
|
QSize upscale(const QSize& size, Round eRound);
|
|
|
|
|
QPoint upscale(const QPoint& point, Round eRound);
|
2018-08-06 17:22:29 +02:00
|
|
|
};
|
|
|
|
|
|
2024-11-18 09:33:05 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab cinoptions=b1,g0,N-s cinkeys+=0=break: */
|