Created attachment 167032 [details] Borderless? The formula bar in Calc with kf5 backend has no border. This is so bad that users can think of the area as a mere empty area. This is not happen in GTK3 backend nor gen Version: 7.1.0.0.alpha1+ Build ID: d4892e5452bff155da6c34063ffe8c331284d8e9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: id-ID (id_ID.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-02_12:38:23 Calc: threaded
I remember hearing complaints about a very similar issue in the Chinese LO user chat group. That user was also using kf5 vcl, and didn't realize that in the conditional format dialog (Format > Conditional > Condition... menu), there is an input box after "Cell value is" and "equal to" dropdown box, and values can be entered there, for the same reason that the input box has no border in kf5, and is seen as just blank space. (The user instead tried hard to find a place to enter input in the third line after "Enter a value:", to no avail.) That was just mentioned in passing and the user was using a version with rather old kf5 (6.3.x version, IIRC), so I didn't follow up. It would probably be worthwhile to check if that input box is still borderless for master, and if this is a bigger problem than just the formula bar.
I can reproduce on Debian testing when using the "Breeze" Qt theme. The border went missing with this commit: commit e087e25f05e689091cbf1c4f91b6e93878ac17ec Author: Caolán McNamara Date: Mon Oct 5 14:19:05 2020 +0100 weld InputBar this also restores that DnD of a selection from the inputbar is pasted as plain text not rich text formatted with the happenstance formatting of the inputbar's EditEngine Change-Id: If4934f83c14357afec2e0a7e1d51c8a1aea1d292 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104037 Tested-by: Caolán McNamara Reviewed-by: Caolán McNamara However, from what I can tell, whether the border is drawn or not depends on the Qt theme in use. This Gerrit patch meant for demonstration purposes contains a some more information: https://gerrit.libreoffice.org/c/core/+/105408 The border is shown just fine when I use e.g. the Fusion theme, i.e. start LibreOffice like this: QT_STYLE_OVERRIDE=Fusion ./instdir/program/soffice --calc I'm wondering whether this more or less already "works as designed" and it's up to the theme to decide whether or not the border is shown, or there should be some tweaks on LO side to make more themes show the border (as e.g. the demo Gerrit patch does at least for Breeze, but there may be better ways)... Version: 7.1.0.0.alpha1+ Build ID: 9f3b85dc29326e779ccc6be3b649b7fb24571ee0 CPU threads: 12; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 167063 [details] Screenshot with the Fusion theme, where borders are shown
(In reply to Ming Hua from comment #1) > I remember hearing complaints about a very similar issue in the Chinese LO > user chat group. That user was also using kf5 vcl, and didn't realize that > in the conditional format dialog (Format > Conditional > Condition... menu), > there is an input box after "Cell value is" and "equal to" dropdown box, and > values can be entered there, for the same reason that the input box has no > border in kf5, and is seen as just blank space. (The user instead tried > hard to find a place to enter input in the third line after "Enter a > value:", to no avail.) > > That was just mentioned in passing and the user was using a version with > rather old kf5 (6.3.x version, IIRC), so I didn't follow up. It would > probably be worthwhile to check if that input box is still borderless for > master, and if this is a bigger problem than just the formula bar. I don't reproduce this case, the borders are shown for me there (also with Breeze theme, with which borders are missing for the Calc input bar).
(In reply to Michael Weghorn from comment #4) > (In reply to Ming Hua from comment #1) > > I remember hearing complaints about a very similar issue [...] > > I don't reproduce this case, the borders are shown for me there (also with > Breeze theme, with which borders are missing for the Calc input bar). Good to know. Thanks for taking time to check this issue, and sorry for the noise.
Not reproducible in Version: 7.1.0.0.alpha1+ Build ID: 9c8ed8c8526b9b696d0bf592eb7d963950f3cef4 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded using Breeze
(In reply to Xisco Faulí from comment #6) > Not reproducible in > > Version: 7.1.0.0.alpha1+ > Build ID: 9c8ed8c8526b9b696d0bf592eb7d963950f3cef4 > CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded According to Rizal this bug is kf5 only: (In reply to Rizal Muttaqin from comment #0) > This is not happen in GTK3 backend nor gen
*** Bug 137956 has been marked as a duplicate of this bug. ***
Mark to NEW as there is a duplicate. Heiko Tietze: If you are working on this maybe you can set as ASSIGNED? https://gerrit.libreoffice.org/c/core/+/105237
(In reply to Kevin Suo from comment #9) > https://gerrit.libreoffice.org/c/core/+/105237 Abandoned this patch as the bevel is not a solution. Michael is working on another solution.
(In reply to Heiko Tietze from comment #10) > (In reply to Kevin Suo from comment #9) > > https://gerrit.libreoffice.org/c/core/+/105237 > > Abandoned this patch as the bevel is not a solution. Michael is working on > another solution. Yes, I'm looking at this, currently debugging into the Breeze theme. It DOES draw borders, but it seems those are off by one pixel and therefore not visible. Need to investigate further whether that's actually a bug in the Breeze theme or LO needs to do sth differently.
(In reply to Michael Weghorn from comment #11) > Yes, I'm looking at this, currently debugging into the Breeze theme. It DOES > draw borders, but it seems those are off by one pixel and therefore not > visible. > Need to investigate further whether that's actually a bug in the Breeze > theme or LO needs to do sth differently. Nice finding. This is a long standing problem. It always confused me, that border were working for some, but not all frames. While it was originally working for the Calc Input / Formular bar, the font preview of the "Format cells > Font" was always without a border, but ok in gtk+ breeze.
From how I understand it, this is a bug in the Breeze style. I have submitted a bug report and merge request for it: https://bugs.kde.org/show_bug.cgi?id=428973 https://invent.kde.org/plasma/breeze/-/merge_requests/51 Closing as RESOLVED NOTOURBUG for now. Will reopen if discussion there yields a different result.
(In reply to Michael Weghorn from comment #13) > From how I understand it, this is a bug in the Breeze style. > > I have submitted a bug report and merge request for it: > > https://bugs.kde.org/show_bug.cgi?id=428973 > https://invent.kde.org/plasma/breeze/-/merge_requests/51 > > Closing as RESOLVED NOTOURBUG for now. Will reopen if discussion there > yields a different result. The MR was just merged, i.e. it's fixed in the current development version of the Breeze style.
Further discussion with KDE developers revealed that the root cause is in fact a LO issue, VclScrolledWindow doesn't correctly handle frame widths other than 1. (And the Breeze styles has a 2 pixel frame, the inner row of pixels being a border and the outer row being padding, and we just ended up with the invisible padding.) More details here: https://invent.kde.org/plasma/breeze/-/merge_requests/52 Reopening. Patches pending here: https://gerrit.libreoffice.org/c/core/+/106154 https://gerrit.libreoffice.org/c/core/+/106155 https://gerrit.libreoffice.org/c/core/+/106156 https://gerrit.libreoffice.org/c/core/+/106157
(In reply to Michael Weghorn from comment #15) > Further discussion with KDE developers revealed that the root cause is in > fact a LO issue, VclScrolledWindow doesn't correctly handle frame widths > other than 1. (And the Breeze styles has a 2 pixel frame, the inner row of > pixels being a border and the outer row being padding, and we just ended up > with the invisible padding.) > > More details here: > https://invent.kde.org/plasma/breeze/-/merge_requests/52 > > Reopening. Patches pending here: > > https://gerrit.libreoffice.org/c/core/+/106154 > https://gerrit.libreoffice.org/c/core/+/106155 > https://gerrit.libreoffice.org/c/core/+/106156 > https://gerrit.libreoffice.org/c/core/+/106157 And here I was hoping this would also fix the "Format cells > Font" preview border problem. Might be a similar bug in the implementation of that preview. I guess that doesn't involve a VclScrolledWindow, so no such luck. Thanks for the whole investigation :-)
(In reply to Jan-Marek Glogowski from comment #16) > And here I was hoping this would also fix the "Format cells > Font" preview > border problem. Might be a similar bug in the implementation of that > preview. I guess that doesn't involve a VclScrolledWindow, so no such luck. That works fine for me with the patches as well. :-)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/70d2d1945a06dc6ec4f605e7462369a2f4937975 tdf#138010 (I) Pass bounding rect when natively drawing frame It will be available in 7.1.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/771f1411c588a02ed276febc9a479323bf4232cd tdf#138010 (II) getNativeControlRegion (gtk3/kf5): Consider frame's border It will be available in 7.1.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/411063bc99f7339afae2c2a25a146c7c5efeb2da tdf#138010 (III) Extract VclScrolledWindow border width to var It will be available in 7.1.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f39f21d92ec83c3a5062f29dd26214fc83012c06 tdf#138010 (IV) VclScrolledWindow: Use actual border width It will be available in 7.1.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.
Fixed in master, currently no backport for 7-0 planned (since welded Calc input bar is master-only as well, s. comment 2).
Verified fixed in Version: 7.2.0.0.alpha0+ Build ID: 736b0709796d96325542b624ce27a7dc83419cfb CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 Locale: id-ID (id_ID.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-22_18:03:44 Calc: threaded Where is 7.1 branch? The commit message tell us the patch was againts 7.1.0 branch
(In reply to Rizal Muttaqin from comment #23) > Where is 7.1 branch? The commit message tell us the patch was againts 7.1.0 > branch The patches were merged to master shortly before the libreoffice-7-1 branchoff, i.e. they are still contained in libreoffice-7-1 as well "automatically". You can run 'git log origin/libreoffice-7-1' to verify this (replace 'origin' by whatever your remote is called if necessary).