[Libreoffice-ux-advise] [Bug 138979] Dark-colored style previews lack contrast when using dark theme
https://bugs.documentfoundation.org/show_bug.cgi?id=138979 Stéphane Guillou (stragu) changed: What|Removed |Added CC||stephane.guillou@libreoffic ||e.org Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=13 | |7705| --- Comment #8 from Stéphane Guillou (stragu) --- *** This bug has been marked as a duplicate of bug 137705 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 152264] Installing the Windows 32-bit version in parallel by SI-GUI, No starting if the ExperimentalMode is enabled.
https://bugs.documentfoundation.org/show_bug.cgi?id=152264 nobu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from nobu --- *** This bug has been marked as a duplicate of bug 151540 *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137705] Stylist not using document colors making it hard to read fonts not using automatic color
https://bugs.documentfoundation.org/show_bug.cgi?id=137705 Stéphane Guillou (stragu) changed: What|Removed |Added See Also|https://bugs.documentfounda | |tion.org/show_bug.cgi?id=13 | |8979| CC||octa...@alvarezp.org --- Comment #19 from Stéphane Guillou (stragu) --- *** Bug 138979 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152346] 7.5 Windows 32-bit crashes on startup
https://bugs.documentfoundation.org/show_bug.cgi?id=152346 --- Comment #18 from David --- (In reply to Stéphane Guillou (stragu) from comment #17) > The fix is already merged in 7.5: > https://gerrit.libreoffice.org/c/core/+/146507 > Hopefully that's it! > David, could you see the UI at all before it crashed? Jim says some > interaction between mouse pointer and the navigator was needed: > > "To reproduce the crash, move the mouse pointer from a position outside of > > content tree, to an empty position in the content tree, then move it to a > > position over an entry." The logo window would display briefly before it crashed. It never got to the point of opening an application window. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 143344] [META] Linux Dark Mode bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=143344 Bug 143344 depends on bug 138979, which changed state. Bug 138979 Summary: Dark-colored style previews lack contrast when using dark theme https://bugs.documentfoundation.org/show_bug.cgi?id=138979 What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151540] x86 version crashes on Windows 7 with experimental features enabled
https://bugs.documentfoundation.org/show_bug.cgi?id=151540 nobu changed: What|Removed |Added CC||tac...@hotmail.co.jp --- Comment #6 from nobu --- *** Bug 152264 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153106] Revert commit of Bug 91415 - Scale Calc's comment indicator with zoom level (please, do not)
https://bugs.documentfoundation.org/show_bug.cgi?id=153106 --- Comment #11 from ady --- (In reply to Cor Nouws from comment #10) > Do I understand that the commit, that is asked to be reverted, does not make > things worse or better for your use It makes things worse, not better. And this is not just my use case; it is that those users with the original request as in Bug 91415 are simply unaware of the usage or existence of the zoom feature. The zoom feature's whole purpose is to allow changing the clearance distance between screen artifacts. If you cannot read clearly, if the lines that form a character are "too-crowded", if two independent items on screen are "too-close" to each-other, use a higher zoom factor: the lines and other items look more distant between each-other and you can distinguish between them. Being visually challenged, I don't have a choice but to be aware of this feature, and I'm thankful for it. This is one of the things that can be seen in attachment 185187. Using a higher zoom factor, the cell's content grows, while the traditional comment indicator remains as it was (i.e. relatively smaller). This is a good thing. The other thing that can be seen in attachment 185187 is that the comment indicator newly introduced (for LO 7.6alpha+) is not better than the traditional one. I can argue, based on those screenshots, that it takes more screen area, not less, and by scaling it, users are less able to distinguish things apart, since the clearance distance is not higher/better (precisely because of the new scaling). The comment indicator will no longer be relatively smaller when zooming in (or at least not as much), so the main purpose of the zoom feature is lost for this item, while the original problem is not completely gone. Additionally, IIUC this change requires more graphic resources. Please someone clarify this for me: What exactly is the positive consequence or advantage of scaling the comment indicator? Isn't the built-in zoom feature already available and already solving the original problem? > > And that better use of zoom will help people with the use of the old version > of the indicator? Yes. In LO. In AOo. In any spreadsheet program since they use GUIs including zoom features, it has been this way. For those users that are aware of this feature, there is no reason to request to solve this non-issue. > > You know that explaining features in documentation, has it's limitation in > effect.. ;) As an example, we see complaints about Cal's accuracy of calculations several times a year, every year. The typical reply is "read this or that wiki page, or help page, or...". For almost every little thing that users don't know yet, we are instructed/hinted/pointed to some document, or to some ask.lo.org, or to some email, or... Nothing new. As another example, there have been many requests to allow changing the font type and font size in/of the formula bar, or even of the whole UI in LO. The formula bar can be a _real_ permanent problem (I know it is for me). Yet, since the time the built-in option to scale the UI was gone, the answer has been "use your OS's scaling and zoom features". In the case of the comment indicator, with a minor and temporal issue for some user in some circumstance, users will be happy to know that there is a simple solution already available (in addition to being able to hide all the comment indicators, also already available). Having an adequate documentation about the built-in zoom features in Calc – bug 153108, although it is a bit vague ATM – and use-cases for it, will help users be aware of it. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 153106] Revert commit of Bug 91415 - Scale Calc's comment indicator with zoom level (please, do not)
https://bugs.documentfoundation.org/show_bug.cgi?id=153106 --- Comment #11 from ady --- (In reply to Cor Nouws from comment #10) > Do I understand that the commit, that is asked to be reverted, does not make > things worse or better for your use It makes things worse, not better. And this is not just my use case; it is that those users with the original request as in Bug 91415 are simply unaware of the usage or existence of the zoom feature. The zoom feature's whole purpose is to allow changing the clearance distance between screen artifacts. If you cannot read clearly, if the lines that form a character are "too-crowded", if two independent items on screen are "too-close" to each-other, use a higher zoom factor: the lines and other items look more distant between each-other and you can distinguish between them. Being visually challenged, I don't have a choice but to be aware of this feature, and I'm thankful for it. This is one of the things that can be seen in attachment 185187. Using a higher zoom factor, the cell's content grows, while the traditional comment indicator remains as it was (i.e. relatively smaller). This is a good thing. The other thing that can be seen in attachment 185187 is that the comment indicator newly introduced (for LO 7.6alpha+) is not better than the traditional one. I can argue, based on those screenshots, that it takes more screen area, not less, and by scaling it, users are less able to distinguish things apart, since the clearance distance is not higher/better (precisely because of the new scaling). The comment indicator will no longer be relatively smaller when zooming in (or at least not as much), so the main purpose of the zoom feature is lost for this item, while the original problem is not completely gone. Additionally, IIUC this change requires more graphic resources. Please someone clarify this for me: What exactly is the positive consequence or advantage of scaling the comment indicator? Isn't the built-in zoom feature already available and already solving the original problem? > > And that better use of zoom will help people with the use of the old version > of the indicator? Yes. In LO. In AOo. In any spreadsheet program since they use GUIs including zoom features, it has been this way. For those users that are aware of this feature, there is no reason to request to solve this non-issue. > > You know that explaining features in documentation, has it's limitation in > effect.. ;) As an example, we see complaints about Cal's accuracy of calculations several times a year, every year. The typical reply is "read this or that wiki page, or help page, or...". For almost every little thing that users don't know yet, we are instructed/hinted/pointed to some document, or to some ask.lo.org, or to some email, or... Nothing new. As another example, there have been many requests to allow changing the font type and font size in/of the formula bar, or even of the whole UI in LO. The formula bar can be a _real_ permanent problem (I know it is for me). Yet, since the time the built-in option to scale the UI was gone, the answer has been "use your OS's scaling and zoom features". In the case of the comment indicator, with a minor and temporal issue for some user in some circumstance, users will be happy to know that there is a simple solution already available (in addition to being able to hide all the comment indicators, also already available). Having an adequate documentation about the built-in zoom features in Calc – bug 153108, although it is a bit vague ATM – and use-cases for it, will help users be aware of it. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 153504] macOS dark-mode: Styles tab hard to read with certain document open
https://bugs.documentfoundation.org/show_bug.cgi?id=153504 Stéphane Guillou (stragu) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Stéphane Guillou (stragu) --- Same on Windows 10 and Ubuntu 20.04. Issue is that if the style font colour is not Automatic, it won't automatically switch for better contrast. I think that the recent improvements in macOS and Windows dark mode support mean that bug 137705 does not apply to Linux only, and that it can be generalised and this bug marked as a duplicate. *** This bug has been marked as a duplicate of bug 137705 *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 137705] Stylist not using document colors making it hard to read fonts not using automatic color
https://bugs.documentfoundation.org/show_bug.cgi?id=137705 Stéphane Guillou (stragu) changed: What|Removed |Added CC||tele...@surfxs.nl --- Comment #20 from Stéphane Guillou (stragu) --- *** Bug 153504 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150960] Use platform look and feel (plaf) and scaling for Java windows
https://bugs.documentfoundation.org/show_bug.cgi?id=150960 --- Comment #1 from Hossein --- Using the below parameter, one can change the scaling for a Java application via JRE startup parameters: java -Dsun.java2d.uiScale=2.0 App Java 9 might be required for this option. https://openjdk.org/jeps/263 I have tested the above parameter by adding it to the LibreOffice settings. I went to "Tools > Options > Advanced > Parameters", then added "-Dsun.java2d.uiScale=2.0" as the parameter. After that, I opened the "Macros > Organize Macros > BeanShell", selected a macro from the tree, then clicked "Edit". In this way, the window was shown with 2x scaling. To fix the issue and achieve automatic scaling, one can detect the scaling via GDK_SCALE or other means in other platforms, and then apply the scaling factor using the uiScale parameter, which also accepts fractional values for the scaling. On the other hand, it would be possible to implement the scaling inside our application too. For example, IntelliJ IDEA has internal scaling capabilities: https://youtrack.jetbrains.com/issue/JBR-3757 Increasing the font size would be part of this approach. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153515] New: LibreOffice does not remember the window position in fullscreen with more than one Screen
https://bugs.documentfoundation.org/show_bug.cgi?id=153515 Bug ID: 153515 Summary: LibreOffice does not remember the window position in fullscreen with more than one Screen Product: LibreOffice Version: 7.5.0.3 release Hardware: x86-64 (AMD64) OS: Windows (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Writer Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: a.b...@berg-kommunikation.de Description: The phenomenon appeared a few versions earlier. If Libreoffice exited in fullscreen on the second screen, it will start again on the first screen next time. If it was not ended in full screen, it remembers the last window position. Steps to Reproduce: 1. Starting Writer. 2. Move the program window to the second screen and fullsize the window. 3. Close the program. 4. Restart Writer. Actual Results: Restarting opens the program on the first screen in fullsize-mode. Expected Results: Writer should open on the last postion: on the second screen. Reproducible: Always User Profile Reset: No Additional Info: Not needed. The phenomenon appeared a few versions earlier, too. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: Branch 'libreoffice-7-5' - vcl/inc vcl/qt5
vcl/inc/qt5/QtGraphics_Controls.hxx |3 ++-
vcl/qt5/QtGraphics_Controls.cxx | 30 --
2 files changed, 30 insertions(+), 3 deletions(-)
New commits:
commit 43c1de9f68a589304f060d2e662dc37c842a2a67
Author: Rafael Lima
AuthorDate: Thu Feb 2 15:27:37 2023 +
Commit: Caolán McNamara
CommitDate: Fri Feb 10 09:03:39 2023 +
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
Change-Id: If8cb4794c7f3ce1be4d1ee421c9c27ad5adf5da2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146516
Tested-by: Jenkins
Reviewed-by: Michael Weghorn
(cherry picked from commit 5c96e813bed3293605f8d746f188cc051d1e5949)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146706
Reviewed-by: Caolán McNamara
diff --git a/vcl/inc/qt5/QtGraphics_Controls.hxx
b/vcl/inc/qt5/QtGraphics_Controls.hxx
index 17039f9d6038..dd1865e34008 100644
--- a/vcl/inc/qt5/QtGraphics_Controls.hxx
+++ b/vcl/inc/qt5/QtGraphics_Controls.hxx
@@ -59,7 +59,8 @@ public:
tools::Rectangle& rNativeContentRegion)
override;
private:
-static int pixelMetric(QStyle::PixelMetric metric, const QStyleOption*
option = nullptr);
+static int pixelMetric(QStyle::PixelMetric metric, const QStyleOption*
option = nullptr,
+ const QWidget* pWidget = nullptr);
static QSize sizeFromContents(QStyle::ContentsType type, const
QStyleOption* option,
const QSize& contentsSize);
static QRect subControlRect(QStyle::ComplexControl control, const
QStyleOptionComplex* option,
diff --git a/vcl/qt5/QtGraphics_Controls.cxx b/vcl/qt5/QtGraphics_Controls.cxx
index e08b84719e61..f2e48f655149 100644
--- a/vcl/qt5/QtGraphics_Controls.cxx
+++ b/vcl/qt5/QtGraphics_Controls.cxx
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -129,9 +130,10 @@ bool
QtGraphics_Controls::isNativeControlSupported(ControlType type, ControlPart
return false;
}
-inline int QtGraphics_Controls::pixelMetric(QStyle::PixelMetric metric, const
QStyleOption* option)
+inline int QtGraphics_Controls::pixelMetric(QStyle::PixelMetric metric, const
QStyleOption* option,
+const QWidget* pWidget)
{
-return QApplication::style()->pixelMetric(metric, option);
+return QApplication::style()->pixelMetric(metric, option, pWidget);
}
inline QSize QtGraphics_Controls::sizeFromContents(QStyle::ContentsType type,
@@ -759,6 +761,30 @@ bool
QtGraphics_Controls::getNativeControlRegion(ControlType type, ControlPart p
int nRight = qMax(nLine, upscale(fo.rect.right() -
aSubRect.right(), Round::Ceil));
int nBottom = qMax(nLine, upscale(fo.rect.bottom() -
aSubRect.bottom(), Round::Ceil));
boundingRect.adjust(nLeft, nTop, nRight, nBottom);
+
+// tdf#150451: ensure a minimium size that fits text content +
frame at top and bottom.
+// Themes may use the widget type for determining the actual frame
width to use,
+// so pass a dummy
[Libreoffice-commits] core.git: vcl/unx
vcl/unx/gtk3/gtkinst.cxx |4
1 file changed, 4 insertions(+)
New commits:
commit 72959cc2b36749a779b56522f27e290731187043
Author: Caolán McNamara
AuthorDate: Thu Feb 9 20:57:45 2023 +
Commit: Caolán McNamara
CommitDate: Fri Feb 10 09:03:02 2023 +
gtk4: occasional crash at exit
Change-Id: I2008d44f5dae0f22e9213f46a740146d6eb85666
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146727
Tested-by: Jenkins
Reviewed-by: Caolán McNamara
diff --git a/vcl/unx/gtk3/gtkinst.cxx b/vcl/unx/gtk3/gtkinst.cxx
index 16945ee85dd7..f0923cff2ccd 100644
--- a/vcl/unx/gtk3/gtkinst.cxx
+++ b/vcl/unx/gtk3/gtkinst.cxx
@@ -18571,7 +18571,11 @@ public:
virtual ~GtkInstanceDrawingArea() override
{
+#if GTK_CHECK_VERSION(4,0,0)
+gtk_widget_remove_controller(m_pMouseEventBox,
GTK_EVENT_CONTROLLER(m_pZoomGesture));
+#else
g_clear_object(_pZoomGesture);
+#endif
ImplGetDefaultWindow()->RemoveEventListener(LINK(this,
GtkInstanceDrawingArea, SettingsChangedHdl));
[Libreoffice-commits] core.git: vcl/win
vcl/win/gdi/salnativewidgets-luna.cxx |2 +-
vcl/win/window/salframe.cxx |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
New commits:
commit 86cfb4da4fdca63d92060bcfa65e808f579260f4
Author: Stephan Bergmann
AuthorDate: Fri Feb 10 08:18:04 2023 +0100
Commit: Stephan Bergmann
CommitDate: Fri Feb 10 08:59:38 2023 +
loplugin:staticaccess
Change-Id: If0a2032bede27af3176951dabaab4a165efb144d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146738
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/vcl/win/gdi/salnativewidgets-luna.cxx
b/vcl/win/gdi/salnativewidgets-luna.cxx
index a0379baa7c6c..c837cb7a1c82 100644
--- a/vcl/win/gdi/salnativewidgets-luna.cxx
+++ b/vcl/win/gdi/salnativewidgets-luna.cxx
@@ -403,7 +403,7 @@ bool UseDarkMode()
return false;
bool bRet(false);
-switch (Application::GetSettings().GetMiscSettings().GetDarkMode())
+switch (MiscSettings::GetDarkMode())
{
case 0: // auto
default:
diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index b12fdfffbabe..5bccf6707700 100644
--- a/vcl/win/window/salframe.cxx
+++ b/vcl/win/window/salframe.cxx
@@ -286,7 +286,7 @@ static void UpdateDarkMode(HWND hWnd)
auto SetPreferredAppMode =
reinterpret_cast(GetProcAddress(hUxthemeLib,
MAKEINTRESOURCEA(135)));
if (SetPreferredAppMode)
{
-switch (Application::GetSettings().GetMiscSettings().GetDarkMode())
+switch (MiscSettings::GetDarkMode())
{
case 0:
SetPreferredAppMode(AllowDark);
[Libreoffice-bugs] [Bug 153514] New: STYLE finds wrong style with different case
https://bugs.documentfoundation.org/show_bug.cgi?id=153514
Bug ID: 153514
Summary: STYLE finds wrong style with different case
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: mikekagan...@hotmail.com
1. In a spreadsheet, see that it has a style named "Bad" (note the uppercase
"B").
2. Add a style named "bad" (all lowercase), with different properties.
3. In a cell, enter the formula
=STYLE("bad")
Expected: the cell gets the manually added "bad" style.
Actual: it gets "Bad" style.
The same in OOo 1.0.3 from 2002.
It only should work case-insensitively, when there's no exact match.
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153259] Enhancement Request: Exclude some pages from field "Page Count"
https://bugs.documentfoundation.org/show_bug.cgi?id=153259 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||5288 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-ux-advise] [Bug 153259] Enhancement Request: Exclude some pages from field "Page Count"
https://bugs.documentfoundation.org/show_bug.cgi?id=153259 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=11 ||5288 -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-bugs] [Bug 115288] Page numbers without hidden slides
https://bugs.documentfoundation.org/show_bug.cgi?id=115288 Heiko Tietze changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||3259 --- Comment #14 from Heiko Tietze --- Similar topic is discussed in bug 153259 for Writer with the idea to introduce an attribute on the page style that adds it to the total number of pages, or not. Same could be done for slides / master slides (effectively the same as adding an option to not count a particular slide). -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153491] Create entry in menu /Help to submit MOX-documents that convert faulty to odf.
https://bugs.documentfoundation.org/show_bug.cgi?id=153491 --- Comment #3 from Cor Nouws --- And, under Help you'll find Send Feedback, leading to e.g. this page https://www.libreoffice.org/get-help/feedback/?LOversion=7.6.0.0.alpha0=en-US=StartModule where Create a Bug report is mentioned clearly. Maybe the QA team can think about if that website can hint more specific at reporting rendering bugs? Maybe a link to a wiki, where say three links are provided that are for rendering bugs in Writer, Calc, Impress? OTHO, for filing a bug you need to have an account, and .. So all in all, I doubt if that will make it really easier for 'the broader QA-community' to get the important stuff visible and clearly reported. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152346] 7.5 Windows 32-bit crashes on startup
https://bugs.documentfoundation.org/show_bug.cgi?id=152346 --- Comment #17 from Stéphane Guillou (stragu) --- The fix is already merged in 7.5: https://gerrit.libreoffice.org/c/core/+/146507 Hopefully that's it! David, could you see the UI at all before it crashed? Jim says some interaction between mouse pointer and the navigator was needed: > "To reproduce the crash, move the mouse pointer from a position outside of > content tree, to an empty position in the content tree, then move it to a > position over an entry." -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: svx/source
svx/source/svdraw/svdomedia.cxx |2 ++
1 file changed, 2 insertions(+)
New commits:
commit 5025a56db91bb3cf337659c0f8a77d36f49974ad
Author: Tor Lillqvist
AuthorDate: Tue Oct 25 11:37:42 2022 +0300
Commit: Tor Lillqvist
CommitDate: Fri Feb 10 08:49:01 2023 +
Guard against no HAVE_FEATURE_AVMEDIA in one more place
This was said to fix build of the iOS app some years ago in a vendor
branch, but unclear about that now, it seems to build from master at
the moment anyway? Anyway, this still probably makes sense.
Change-Id: I4a9e6f18e7b17664e5aed36233d5ccde44cf1194
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141796
Tested-by: Tor Lillqvist
Reviewed-by: Tor Lillqvist
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146742
Tested-by: Jenkins
diff --git a/svx/source/svdraw/svdomedia.cxx b/svx/source/svdraw/svdomedia.cxx
index 9b17b7bf278a..c63df5d8b69e 100644
--- a/svx/source/svdraw/svdomedia.cxx
+++ b/svx/source/svdraw/svdomedia.cxx
@@ -474,6 +474,7 @@ void SdrMediaObj::mediaPropertiesChanged( const
::avmedia::MediaItem& rNewProper
void SdrMediaObj::notifyPropertiesForLOKit()
{
+#if HAVE_FEATURE_AVMEDIA
if (!m_xImpl->m_MediaProperties.getTempURL().isEmpty())
{
const auto mediaId = reinterpret_cast(this);
@@ -491,6 +492,7 @@ void SdrMediaObj::notifyPropertiesForLOKit()
SfxLokHelper::notifyMediaUpdate(json);
}
+#endif
}
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
[Libreoffice-commits] core.git: solenv/bin
solenv/bin/ooinstall |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
New commits:
commit cbac6b9d8f1319fffc66b397dfa20588e35c24fb
Author: Tor Lillqvist
AuthorDate: Wed Nov 22 21:05:48 2017 +0200
Commit: Tor Lillqvist
CommitDate: Fri Feb 10 08:48:39 2023 +
Pass product name and not hardcoded "LibreOffice" to make_installer.pl -p
Change-Id: I9b2d84bcc18e21b325960f7057e259daa37234a5
Reviewed-on: https://gerrit.libreoffice.org/55640
Reviewed-by: Andras Timar
Tested-by: Andras Timar
(cherry picked from commit 12d1b08aac8cc8c3176040efc7290377e380f0c4)
Reviewed-on: https://gerrit.libreoffice.org/79128
Reviewed-by: Tor Lillqvist
Tested-by: Tor Lillqvist
(cherry picked from commit 0069417b55c99166aec5489ccef803eba25d2b4f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136842
Tested-by: Jenkins CollaboraOffice
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146741
Tested-by: Jenkins
diff --git a/solenv/bin/ooinstall b/solenv/bin/ooinstall
index efb1f28de824..71f10c739036 100755
--- a/solenv/bin/ooinstall
+++ b/solenv/bin/ooinstall
@@ -88,11 +88,14 @@ if ($destdir && "$ENV{DESTDIR}" ne "/" && -d
"$ENV{DESTDIR}") {
print "Running LibreOffice installer\n";
+my $PRODUCTNAME_no_spaces = $ENV{PRODUCTNAME};
+$PRODUCTNAME_no_spaces =~ s/ //g;
+
system ("cd $ENV{SRC_ROOT}/instsetoo_native/util ; " .
"perl " .
(scalar keys(%DB::sub) ? "-d " : "") .
"-w $ENV{SRCDIR}/solenv/bin/make_installer.pl " .
-"-f $ENV{BUILDDIR}/instsetoo_native/util/openoffice.lst -l $langs -p
LibreOffice " .
+"-f $ENV{BUILDDIR}/instsetoo_native/util/openoffice.lst -l $langs -p
$PRODUCTNAME_no_spaces " .
"-u $tmp_dir " .
"-buildid $BUILD $destdir $strip $msi " .
"-simple $path") && die "Failed to install: $!";
[Libreoffice-bugs] [Bug 153491] Create entry in menu /Help to submit MOX-documents that convert faulty to odf.
https://bugs.documentfoundation.org/show_bug.cgi?id=153491 Cor Nouws changed: What|Removed |Added Resolution|--- |INVALID CC||c...@nouenoff.nl Status|UNCONFIRMED |RESOLVED --- Comment #2 from Cor Nouws --- Hi Pieter, (In reply to pieter kristensen from comment #0) > I was testing the MOX-conversion with the new version 7.5 in writer. > Chapeau! > What unbelievable progress has been made! Thanks - and I think you are right :) > Only, there are very few documents that convert still bad. > I remember, in the olden days, firefox had functionality to report websites > that didn't render correctly. I think that was smart. The average user > doesn't make a bug-rapport. And imho one couldn't ask him to do so. I agree that filing a proper bug report is not easy for many users. Luckily, there are also many with more understanding of the office suite and the files they use. > But perhaps they would submit their documents in this way. That could be of > use to the developers. If a document is provided with the message "it does not show correct", then someone needs to find out what. We - the community as a whole - try to prevent that developers need to do too much of that work. So we ask a description of "what does not correct" - thus how it should be. Screen prints.. And then people helping with CA - volunteers and staff - will ask questions, do some tests, to find more specific what the problem is. Maybe the bug is already reported, maybe it is new information to an existing bug. So I understand and respect that you ask for an easy way to .. but in practice it is often some work, with difficult elements. And if users (reporters) try to work together with the more active members in the CA-community, that works best. Thus: reporting of bugs is handled by the QA-community in TDF. There is information on the wiki: https://wiki.documentfoundation.org/QA/ https://wiki.documentfoundation.org/QA/BugReport To get an idea of e.g. reports around DOCX, pick some from this query: https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=Writer=short_desc=short_desc_top=OR=docx_type=allwords_id=1558883=LibreOffice_format=advanced And sorry that I was busy and didn't yet respond to the discussion on the Dutch mailing list. Will do know. Your suggestion does not really belong here - so I close the 'bug' as invalid :) But let's talk more at another place! Cheers - Cor -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153513] New: It's impossible to zoom in and out with the keyboard in any of the apps
https://bugs.documentfoundation.org/show_bug.cgi?id=153513 Bug ID: 153513 Summary: It's impossible to zoom in and out with the keyboard in any of the apps Product: LibreOffice Version: 7.5.0.3 release Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: framework Assignee: libreoffice-bugs@lists.freedesktop.org Reporter: leftcr...@tutanota.com Description: I would like to use to control+- to zoom in and out and I suspect so does virtually every other user. Very strange that this big standard functionality is not included. Steps to Reproduce: try zooming in and out of documents with the standard shortcuts Actual Results: doesn't work Expected Results: ctrl+- should zoom in and out like in every other application people use. I don't think there is even any shortcut assigned to this standard feature (ctrl+scroll or mouse click on tiny symbol in the corner don't qualify as shortcuts) Reproducible: Always User Profile Reset: No Additional Info: none -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 115288] Page numbers without hidden slides
https://bugs.documentfoundation.org/show_bug.cgi?id=115288 --- Comment #13 from sschwar...@sschwarzer.net --- I also ran into this limitation. My use case is that it's not yet clear how long the time slot for my talk will be (20 or 30 minutes). I have slides that I only want to show for the 30-minute talk. If I give the 20-minute talk, I obviously don't want gaps in the shown page numbers. Even if I have the shorter time slot, I ideally don't want to delete the hidden slides completely already. Generally, I don't think it's unusual to prepare a talk with "too many" slides and want to decide later which ones to actually use. At the moment, my workaround is to move the hidden pages to the end of the slides. This is inconvenient because if I end up using the slide, I need to find the place again where the slide belongs. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: vcl/win
vcl/win/window/salframe.cxx |4
1 file changed, 4 insertions(+)
New commits:
commit b8a3d1b7577adce9e4844f6f8915820b98b6d2d8
Author: Stephan Bergmann
AuthorDate: Fri Feb 10 08:17:23 2023 +0100
Commit: Stephan Bergmann
CommitDate: Fri Feb 10 08:18:06 2023 +
loplugin:external
Change-Id: Idde40e44254a6c545185470a1db36ab684504bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146737
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index 847156f5b2df..b12fdfffbabe 100644
--- a/vcl/win/window/salframe.cxx
+++ b/vcl/win/window/salframe.cxx
@@ -261,6 +261,8 @@ void ImplSalGetWorkArea( HWND hWnd, RECT *pRect, const RECT
*pParentRect )
}
}
+namespace {
+
enum PreferredAppMode
{
AllowDark = 1,
@@ -268,6 +270,8 @@ enum PreferredAppMode
ForceLight = 3
};
+}
+
static void UpdateDarkMode(HWND hWnd)
{
static bool bOSSupportsDarkMode = OSSupportsDarkMode();
[Libreoffice-commits] core.git: Branch 'libreoffice-7-5-1' - configure.ac vcl/inc vcl/source
configure.ac|3 ++-
vcl/inc/font/LogicalFontInstance.hxx|2 --
vcl/source/font/LogicalFontInstance.cxx | 13 +
vcl/source/gdi/CommonSalLayout.cxx |9 ++---
4 files changed, 5 insertions(+), 22 deletions(-)
New commits:
commit 6a006674c2cf62742ae0653f397aea1166fb43d8
Author: Khaled Hosny
AuthorDate: Wed Feb 8 21:27:50 2023 +0200
Commit: خالد حسني
CommitDate: Fri Feb 10 08:16:39 2023 +
Require HarfBuzz 5.1.0
This is the minimal version to provide the functionality we currently
check for. Some important LO functionality currently depend on idfdef'd
HarfBuzz code, and some distributions build against old system HarfBuzz
leading to user bug reports that are tricky to track down, e.g:
tdf#153048 and tdf#153470.
Change-Id: I7d58ec46f8fd340d2592887c0088876d71351771
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146674
Tested-by: Jenkins
Reviewed-by: خالد حسني
(cherry picked from commit 8c1e91444c78db1093c3db54d98efb16294f82ea)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146700
Reviewed-by: Adolfo Jayme Barrientos
Tested-by: René Engelhard
diff --git a/configure.ac b/configure.ac
index 734149364bbd..2fc55c588ac3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10848,6 +10848,7 @@ AC_SUBST(SYSTEM_LIBORCUS)
dnl ===
dnl HarfBuzz
dnl ===
+harfbuzz_required_version=5.1.0
GRAPHITE_CFLAGS_internal="-I${WORKDIR}/UnpackedTarball/graphite/include
-DGRAPHITE2_STATIC"
GRAPHITE_LIBS_internal="-L${WORKDIR}/LinkTarget/StaticLibrary -lgraphite"
@@ -10855,7 +10856,7 @@
libo_CHECK_SYSTEM_MODULE([graphite],[GRAPHITE],[graphite2 >= 0.9.3])
HARFBUZZ_CFLAGS_internal="-I${WORKDIR}/UnpackedTarball/harfbuzz/src"
HARFBUZZ_LIBS_internal="-L${WORKDIR}/UnpackedTarball/harfbuzz/src/.libs
-lharfbuzz"
-libo_CHECK_SYSTEM_MODULE([harfbuzz],[HARFBUZZ],[harfbuzz-icu >= 2.6.8])
+libo_CHECK_SYSTEM_MODULE([harfbuzz],[HARFBUZZ],[harfbuzz-icu >=
$harfbuzz_required_version])
if test "$COM" = "MSC"; then # override the above
GRAPHITE_LIBS="${WORKDIR}/LinkTarget/StaticLibrary/graphite.lib"
diff --git a/vcl/inc/font/LogicalFontInstance.hxx
b/vcl/inc/font/LogicalFontInstance.hxx
index 6f4645c82c0c..c9e837d540f1 100644
--- a/vcl/inc/font/LogicalFontInstance.hxx
+++ b/vcl/inc/font/LogicalFontInstance.hxx
@@ -156,10 +156,8 @@ private:
// The value is initialized and used in NeedOffsetCorrection().
std::optional m_xeFontFamilyEnum;
-#if HB_VERSION_ATLEAST(4, 0, 0)
mutable hb_draw_funcs_t* m_pHbDrawFuncs = nullptr;
basegfx::B2DPolygon m_aDrawPolygon;
-#endif
};
inline hb_font_t* LogicalFontInstance::GetHbFont()
diff --git a/vcl/source/font/LogicalFontInstance.cxx
b/vcl/source/font/LogicalFontInstance.cxx
index 277edec2d96c..58b291d04bdf 100644
--- a/vcl/source/font/LogicalFontInstance.cxx
+++ b/vcl/source/font/LogicalFontInstance.cxx
@@ -54,10 +54,8 @@ LogicalFontInstance::~LogicalFontInstance()
if (m_pHbFontUntransformed)
hb_font_destroy(m_pHbFontUntransformed);
-#if HB_VERSION_ATLEAST(4, 0, 0)
if (m_pHbDrawFuncs)
hb_draw_funcs_destroy(m_pHbDrawFuncs);
-#endif
}
hb_font_t* LogicalFontInstance::InitHbFont()
@@ -75,12 +73,10 @@ hb_font_t* LogicalFontInstance::InitHbFont()
if (!aVariations.empty())
hb_font_set_variations(pHbFont, aVariations.data(),
aVariations.size());
-#if HB_VERSION_ATLEAST(3, 3, 0)
// If we are applying artificial italic, instruct HarfBuzz to do the same
// so that mark positioning is also transformed.
if (NeedsArtificialItalic())
hb_font_set_synthetic_slant(pHbFont, ARTIFICIAL_ITALIC_SKEW);
-#endif
ImplInitHbFont(pHbFont);
@@ -91,7 +87,6 @@ hb_font_t* LogicalFontInstance::GetHbFontUntransformed() const
{
auto* pHbFont = const_cast(this)->GetHbFont();
-#if HB_VERSION_ATLEAST(3, 3, 0)
if (NeedsArtificialItalic()) // || NeedsArtificialBold()
{
if (!m_pHbFontUntransformed)
@@ -103,7 +98,7 @@ hb_font_t* LogicalFontInstance::GetHbFontUntransformed()
const
}
return m_pHbFontUntransformed;
}
-#endif
+
return pHbFont;
}
@@ -259,7 +254,6 @@ bool LogicalFontInstance::NeedsArtificialItalic() const
return m_aFontSelData.GetItalic() != ITALIC_NONE &&
m_pFontFace->GetItalic() == ITALIC_NONE;
}
-#if HB_VERSION_ATLEAST(4, 0, 0)
namespace
{
void move_to_func(hb_draw_funcs_t*, void* /*pDrawData*/, hb_draw_state_t*,
float to_x, float to_y,
@@ -294,12 +288,10 @@ void close_path_func(hb_draw_funcs_t*, void* pDrawData,
hb_draw_state_t*, void*
pPoly->clear();
}
}
-#endif
bool LogicalFontInstance::GetGlyphOutlineUntransformed(sal_GlyphId nGlyph,
basegfx::B2DPolyPolygon& rPolyPoly) const
{
-#if
[Libreoffice-commits] core.git: solenv/clang-format
solenv/clang-format/check-last-commit |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
New commits:
commit 0fcc2f933e588f5a9fa19f3decf91874d935ecfa
Author: Ilmari Lauhakangas
AuthorDate: Fri Feb 10 08:12:16 2023 +
Commit: Ilmari Lauhakangas
CommitDate: Fri Feb 10 08:12:26 2023 +
Revert "check-last-commit: more detailed advice on using clang-format"
This reverts commit f59d449ecfc078765dfaa2e150a21a7e4b330932.
Reason for revert: confusing
Change-Id: If5924ff3952f344f7a418e80d4ceb774dea94430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146707
Tested-by: Ilmari Lauhakangas
Reviewed-by: Ilmari Lauhakangas
diff --git a/solenv/clang-format/check-last-commit
b/solenv/clang-format/check-last-commit
index bd26258c5ad4..0de5ac4b0783 100755
--- a/solenv/clang-format/check-last-commit
+++ b/solenv/clang-format/check-last-commit
@@ -65,11 +65,7 @@ sub check_style()
{
print("\nERROR: The above differences were found between the code to
commit \n");
print("and the clang-format rules. Tips:\n");
-print("\n- On your local machine you may check how clang-format would
modify the problematic file by saying\n");
-print(" diff --unified <(/opt/lo/bin/clang-format
)\n");
-print("- NOTE: you should only correct the lines that you changed. Do
not add unrelated formatting to your patch.\n");
-print("- If the suggested corrections only apply to the lines you
changed, you may run\n");
-print(" '/opt/lo/bin/clang-format -i ' to fix up
style automatically.\n");
+print("\n- You may run '/opt/lo/bin/clang-format -i ' to fix up style automatically.\n");
print("- See solenv/clang-format/README on where to get the required
version of clang-format binaries.\n");
print("- If you renamed an excluded file, update
solenv/clang-format/excludelist accordingly to keep it excluded.\n");
print("\nsolenv/clang-format/check-last-commit: KO\n");
[Libreoffice-bugs] [Bug 102495] [META] KDE VCL backend bugs and enhancements
https://bugs.documentfoundation.org/show_bug.cgi?id=102495 Bug 102495 depends on bug 150451, which changed state. Bug 150451 Summary: Some text boxes in dialogs do not have borders in dark mode (kf5) https://bugs.documentfoundation.org/show_bug.cgi?id=150451 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150451] Some text boxes in dialogs do not have borders in dark mode (kf5)
https://bugs.documentfoundation.org/show_bug.cgi?id=150451 Michael Weghorn changed: What|Removed |Added Assignee|libreoffice-b...@lists.free |rafael.palma.l...@gmail.com |desktop.org | Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150451] Some text boxes in dialogs do not have borders in dark mode (kf5)
https://bugs.documentfoundation.org/show_bug.cgi?id=150451 --- Comment #26 from Commit Notification --- Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5c96e813bed3293605f8d746f188cc051d1e5949 tdf#150451 Fix borders in Editbox controls (kf5) It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 150451] Some text boxes in dialogs do not have borders in dark mode (kf5)
https://bugs.documentfoundation.org/show_bug.cgi?id=150451 Commit Notification changed: What|Removed |Added Whiteboard||target:7.6.0 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-commits] core.git: vcl/inc vcl/qt5
vcl/inc/qt5/QtGraphics_Controls.hxx |3 ++-
vcl/qt5/QtGraphics_Controls.cxx | 30 --
2 files changed, 30 insertions(+), 3 deletions(-)
New commits:
commit 5c96e813bed3293605f8d746f188cc051d1e5949
Author: Rafael Lima
AuthorDate: Thu Feb 2 15:27:37 2023 +
Commit: Michael Weghorn
CommitDate: Fri Feb 10 08:04:40 2023 +
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
Change-Id: If8cb4794c7f3ce1be4d1ee421c9c27ad5adf5da2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146516
Tested-by: Jenkins
Reviewed-by: Michael Weghorn
diff --git a/vcl/inc/qt5/QtGraphics_Controls.hxx
b/vcl/inc/qt5/QtGraphics_Controls.hxx
index 17039f9d6038..dd1865e34008 100644
--- a/vcl/inc/qt5/QtGraphics_Controls.hxx
+++ b/vcl/inc/qt5/QtGraphics_Controls.hxx
@@ -59,7 +59,8 @@ public:
tools::Rectangle& rNativeContentRegion)
override;
private:
-static int pixelMetric(QStyle::PixelMetric metric, const QStyleOption*
option = nullptr);
+static int pixelMetric(QStyle::PixelMetric metric, const QStyleOption*
option = nullptr,
+ const QWidget* pWidget = nullptr);
static QSize sizeFromContents(QStyle::ContentsType type, const
QStyleOption* option,
const QSize& contentsSize);
static QRect subControlRect(QStyle::ComplexControl control, const
QStyleOptionComplex* option,
diff --git a/vcl/qt5/QtGraphics_Controls.cxx b/vcl/qt5/QtGraphics_Controls.cxx
index e08b84719e61..f2e48f655149 100644
--- a/vcl/qt5/QtGraphics_Controls.cxx
+++ b/vcl/qt5/QtGraphics_Controls.cxx
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -129,9 +130,10 @@ bool
QtGraphics_Controls::isNativeControlSupported(ControlType type, ControlPart
return false;
}
-inline int QtGraphics_Controls::pixelMetric(QStyle::PixelMetric metric, const
QStyleOption* option)
+inline int QtGraphics_Controls::pixelMetric(QStyle::PixelMetric metric, const
QStyleOption* option,
+const QWidget* pWidget)
{
-return QApplication::style()->pixelMetric(metric, option);
+return QApplication::style()->pixelMetric(metric, option, pWidget);
}
inline QSize QtGraphics_Controls::sizeFromContents(QStyle::ContentsType type,
@@ -759,6 +761,30 @@ bool
QtGraphics_Controls::getNativeControlRegion(ControlType type, ControlPart p
int nRight = qMax(nLine, upscale(fo.rect.right() -
aSubRect.right(), Round::Ceil));
int nBottom = qMax(nLine, upscale(fo.rect.bottom() -
aSubRect.bottom(), Round::Ceil));
boundingRect.adjust(nLeft, nTop, nRight, nBottom);
+
+// tdf#150451: ensure a minimium size that fits text content +
frame at top and bottom.
+// Themes may use the widget type for determining the actual frame
width to use,
+// so pass a dummy QLineEdit
+//
+// NOTE: This is currently only done here for the minimum size
calculation and
+// not above because the handling for edit
