Bug 138010 - Borderless Calc's formula bar (kf5 VCL only)
Summary: Borderless Calc's formula bar (kf5 VCL only)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:7.1.0
Keywords:
: 137956 (view as bug list)
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2020-11-05 11:09 UTC by Rizal Muttaqin
Modified: 2020-11-23 09:38 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Borderless? (44.05 KB, image/png)
2020-11-05 11:09 UTC, Rizal Muttaqin
Details
Screenshot with the Fusion theme, where borders are shown (34.38 KB, image/png)
2020-11-06 13:53 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rizal Muttaqin 2020-11-05 11:09:56 UTC
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
Comment 1 Ming Hua 2020-11-05 17:57:34 UTC
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.
Comment 2 Michael Weghorn 2020-11-06 13:50:38 UTC
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
Comment 3 Michael Weghorn 2020-11-06 13:53:02 UTC
Created attachment 167063 [details]
Screenshot with the Fusion theme, where borders are shown
Comment 4 Michael Weghorn 2020-11-06 13:53:45 UTC
(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).
Comment 5 Ming Hua 2020-11-06 22:24:44 UTC
(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.
Comment 6 Xisco Faulí 2020-11-09 09:28:05 UTC
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
Comment 7 Ming Hua 2020-11-09 13:47:07 UTC
(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
Comment 8 Heiko Tietze 2020-11-10 12:42:46 UTC
*** Bug 137956 has been marked as a duplicate of this bug. ***
Comment 9 Kevin Suo 2020-11-10 14:38:29 UTC
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
Comment 10 Heiko Tietze 2020-11-10 14:43:28 UTC
(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.
Comment 11 Michael Weghorn 2020-11-10 14:49:43 UTC
(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.
Comment 12 Jan-Marek Glogowski 2020-11-10 16:24:08 UTC
(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.
Comment 13 Michael Weghorn 2020-11-11 13:23:45 UTC
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.
Comment 14 Michael Weghorn 2020-11-11 19:59:18 UTC
(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.
Comment 15 Michael Weghorn 2020-11-19 11:35:17 UTC
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
Comment 16 Jan-Marek Glogowski 2020-11-19 11:59:25 UTC
(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 :-)
Comment 17 Michael Weghorn 2020-11-19 12:03:45 UTC
(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. :-)
Comment 18 Commit Notification 2020-11-19 17:11:18 UTC
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.
Comment 19 Commit Notification 2020-11-19 17:11:29 UTC
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.
Comment 20 Commit Notification 2020-11-19 17:11:39 UTC
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.
Comment 21 Commit Notification 2020-11-19 17:12:50 UTC
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.
Comment 22 Michael Weghorn 2020-11-19 17:16:09 UTC
Fixed in master, currently no backport for 7-0 planned (since welded Calc input bar is master-only as well, s. comment 2).
Comment 23 Rizal Muttaqin 2020-11-23 09:28:57 UTC
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
Comment 24 Michael Weghorn 2020-11-23 09:38:18 UTC
(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).