Summary: | Missing border of comboboxes in LO and spinboxes in spectacle | ||
---|---|---|---|
Product: | [Plasma] Breeze | Reporter: | Fabian Vogt <fabian> |
Component: | QStyle | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | kde, m.weghorn, noahadvs |
Priority: | NOR | ||
Version: | 5.20.90 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Fabian Vogt
2021-02-01 19:42:37 UTC
The issue is that Style::drawFrameLineEditPrimitive runs into the "not enough room" case. Instead of not drawing the double frame, it decides not to draw any frame at all. The LO issue can be explained by LO not taking frame margins into account (confirmed by adding 10px, but LO looked the same), so this might be fixed by https://github.com/LibreOffice/core/commit/771f1411c588a02ed276febc9a479323bf4232cd. I'm using 7.0.3.1 here, not sure whether that commit is included. Adding Michael Weghorn for info. The issue with Spectacle is that kImageAnnotator hardcodes a fixed size for the spin boxes: https://github.com/ksnip/kImageAnnotator/blob/e3bc6b067030a603158aad2e8e45b67ab7932fb3/src/common/constants/Constants.h#L34 So it ignores minimumSizeHint of the spin box, triggering the fallback. Adding a workaround in breeze seems to be quite complex, but so far the issues introduced by the change only hit a few applications (any other than LO and Spectacle?). It also appears to be caused by those applications not behaving properly, so IMO a workaround for this isn't necessary. Thanks for investigating. Did you make progress on the condition that seemed weird at https://invent.kde.org/plasma/breeze/-/blob/master/kstyle/breezestyle.cpp#L6407, Comparing the height() and widths? (In reply to David Redondo from comment #3) > Thanks for investigating. > Did you make progress on the condition that seemed weird at > https://invent.kde.org/plasma/breeze/-/blob/master/kstyle/breezestyle. > cpp#L6407, Comparing the height() and widths? I didn't have a close look at that as it's unrelated to this issue, but I assume it's just using square arrow button sizes. (In reply to Fabian Vogt from comment #1) > The issue is that Style::drawFrameLineEditPrimitive runs into the "not > enough room" case. Instead of not drawing the double frame, it decides not > to draw any frame at all. > > The LO issue can be explained by LO not taking frame margins into account > (confirmed by adding 10px, but LO looked the same), so this might be fixed > by > https://github.com/LibreOffice/core/commit/ > 771f1411c588a02ed276febc9a479323bf4232cd. I'm using 7.0.3.1 here, not sure > whether that commit is included. Adding Michael Weghorn for info. That commit (and the others in the series) are only contained from LO 7.1 on, but they do not fix the issue described here (which is still reproducible with LO from git master). I've created https://bugs.documentfoundation.org/show_bug.cgi?id=140088 to keep track of this on LO side. I've reported the bug to kimageAnnotator upstream: https://github.com/ksnip/kImageAnnotator/issues/207 Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! |