Created attachment 181817 [details] Properties dialog (notice text boxes without borders) Open attachment 181815 [details] from bug 150448 and notice that the text box where the value "P" was entered does not have borders around it. Actually, without the value it is not even possible to know that a text box exists there. Also notice that the "Range" field at the bottom of the same dialog does not have borders as well, which is a visual glitch. This problem happens in various dialogs using dark mode, but only in text boxes. Another example is the "Properties" dialog under the "Description" tab (see image attached to this ticket). This problem seems to be Kf5-only, because using "SAL_USE_VCLPLUGIN=gtk3" even in KDE the text boxes have borders. BTW I am using stock KDE Plasma 5.24.6 without any themes applied. Just stock Breeze dark. System info Version: 7.3.5.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1 Calc: threaded Also repro in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 641d92a73e5b3d0e062e16ed4b42236e1a4796a5 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL
Created attachment 181822 [details] Screenshot on Debian testing with current master Can't reproduce on Debian testing (with plasma-desktop 4:5.25.4-1, breeze 4:5.25.4-1). Attached is a screenshot of what I see when opening the mentioned dialog in Calc via "Format" -> "Conditional" -> "Manage" -> "Add". (In reply to Rafael Lima from comment #0) > Another example is the "Properties" dialog under the "Description" > tab (see image attached to this ticket). That one ("File" -> "Properties") also shows borders for me.
This sounds similar to tdf#138010, but obviously the LO versions you're using already include the commits for that one. Does it still happen with a fresh user profile? Other than than, I currently have no idea to explain the difference other than that it might be related to the Plasma/KF5/Breeze versions used.
(In reply to Michael Weghorn from comment #1) > Can't reproduce on Debian testing (with plasma-desktop 4:5.25.4-1, breeze > 4:5.25.4-1). Version I used: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: f7e0493987f4d2d821d2724e9fef018676af5ddf CPU threads: 12; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Only bug I see is for dark mode, borders in File-Properties and Conditional Formatting have dark borders. Rafael, this bug is Needinfo. If you still experience, try fresh profile and see if that's only for specific file you didn't attach. Bug 150448 also doesn't have a file. I think this may be confirmed as "boxes in dialogs have dark borders in dark mode" but that's not KDE but Linux dark mode
I guess this issue affects light mode as well. See bug 152849. It seems to be related to kf5 only.
[Automated Action] NeedInfo-To-Unconfirmed
*** Bug 152849 has been marked as a duplicate of this bug. ***
Setting to NEW due to duplicate bug 152849.
(In reply to Rafael Lima from comment #0) > BTW I am using stock KDE Plasma 5.24.6 without any themes applied. Just > stock Breeze dark. Just to double-check: Is that fine for you with Breeze (non-dark mode)? Are the borders there when you try completely other Qt styles, e.g. by starting LO with these environment variables (and having the corresponding Qt styles installed) QT_STYLE_OVERRIDE="Adwaita" QT_STYLE_OVERRIDE="Adwaita-Dark" QT_STYLE_OVERRIDE="Fusion" ? (I see borders for all of them, but as written earlier, I also see them with Breeze.) Could you please also double-check with master/daily build and a fresh user profile?
(In reply to Michael Weghorn from comment #9) > Just to double-check: Is that fine for you with Breeze (non-dark mode)? The problem indeed happens both with light and dark themes (stock Breeze and Breeze Dark). Currently I'm using Plasma 5.26.4, which is a fresh install. The problem also happens on my laptop with Plasma as well. > Are the borders there when you try completely other Qt styles, e.g. by starting > LO with these environment variables (and having the corresponding Qt styles > installed) > QT_STYLE_OVERRIDE="Adwaita" I installed the package adwaita-qt in my system and tested using QT_STYLE_OVERRIDE="Adwaita" and the borders were there. I should note also that when I use SAL_USE_VCLPLUGIN=gtk3 the borders also appear fine. > Could you please also double-check with master/daily build and a fresh user > profile? I tested with a clean build and a fresh user profile. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8336c61ba059551cb74df5ec53d2b45a3cf41814 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
(In reply to Rafael Lima from comment #10) > I installed the package adwaita-qt in my system and tested using > QT_STYLE_OVERRIDE="Adwaita" and the borders were there. Looks like a Breeze-specfic issue then. (In reply to Rafael Lima from comment #10) > The problem indeed happens both with light and dark themes (stock Breeze and > Breeze Dark). Currently I'm using Plasma 5.26.4, which is a fresh install. > The problem also happens on my laptop with Plasma as well. Odd, that's the same version I was testing on Debian testing and it worked for me. Can you give the exact package version of package "kde-style-breeze" (command: "dpkg -l kde-style-breeze")? (Mine used to be 4:5.26.4-1 until it was upgraded to 4:5.26.5-1 this morning; both work fine here.)
(In reply to Michael Weghorn from comment #11) > Odd, that's the same version I was testing on Debian testing and it worked > for me. Can you give the exact package version of package "kde-style-breeze" > (command: "dpkg -l kde-style-breeze")? Mine is 4:5.26.5-0ubuntu1~ubuntu22.10~ppa1. My Plasma also updated to 5.26.5 and KDE Frameworks is 5.101.0.
FWIW, my dpkg returns an error... ;p HTH... Operating System: Mageia 9 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.1.4-server-2.mga9 (64-bit) $ rpm -qa | grep breeze breeze-icons-5.101.0-1.mga9 lib64breezecommon5_5-5.26.5-1.mga9 breeze-common-5.26.5-1.mga9 breeze-5.26.5-1.mga9 breeze-gtk-5.26.5-1.mga9
(In reply to Rafael Lima from comment #12) > My Plasma also updated to 5.26.5 and KDE Frameworks is 5.101.0. (In reply to Pierre Fortin from comment #13) > KDE Plasma Version: 5.26.5 > [...] > $ rpm -qa | grep breeze > breeze-icons-5.101.0-1.mga9 > lib64breezecommon5_5-5.26.5-1.mga9 > breeze-common-5.26.5-1.mga9 > breeze-5.26.5-1.mga9 > breeze-gtk-5.26.5-1.mga9 Thanks. Looks pretty much the same as I have, so unfortunately I'm running out of ideas on what may be causing the issue for you without being able to reproduce here, unless you have done any other theming/style-related changes in KDE settings.
Twilight Zone... now the borders are visible... OK... thinking about this logically... Last thing I did was blow away my user profile and start in safe mode. Today, this issue is no longer present... ;? However... there is a difference... the Conditional Formatting dialog currently has a white background in the Conditions box. I may be remembering wrong; but I think the background was previously light gray... If so, the border may have been there all along; just 'invisible' if its color was the same as the background...
(In reply to Michael Weghorn from comment #14) > Thanks. Looks pretty much the same as I have, so unfortunately I'm running > out of ideas on what may be causing the issue for you without being able to > reproduce here, unless you have done any other theming/style-related changes > in KDE settings. I'm running out of ideas as well... at first I thought it was because I'm using Ubuntu packages... but Pierre is using Mageia and it's packaging is completely different. So I have no clue whats going on. (In reply to Pierre Fortin from comment #15) > Twilight Zone... now the borders are visible... > OK... thinking about this logically... Last thing I did was blow away my > user profile and start in safe mode. Today, this issue is no longer > present... ;? I've just restarted LO in safe mode (again) and reset the entire user profile, but this did not fix the problem. > However... there is a difference... the Conditional Formatting dialog > currently has a white background in the Conditions box. I may be > remembering wrong; but I think the background was previously light gray... > If so, the border may have been there all along; just 'invisible' if its > color was the same as the background... The background is white. I personally don't like it very much, but it's the correct color. I guess it's to improve contrast with the rest of the dialog.
Created attachment 184937 [details] Hyperlink dialog (only Target has borders) Here's an interesting case study. Notice that the Insert Hyperlink dialog has one case where the textbox has borders (Target) while others in the same dialog do not have borders (Text and Name). This dialog is Insert - Hyperlink and then choose the "Document" option. The file defining this dialog is hyperlinkdocpage.ui
Created attachment 184939 [details] Hyperlink dialog (with dummy buttons - border appears) @Michael, I found something interesting that might help fix this bug. Let me explain, first: I figured that the borders in the "Target" screenshot (attachment 184937 [details]) are shown because there's a button to its right, whereas the others do not have buttons (and also no borders). In the hyperlinkdocpage.ui all of them are GtkEntry, so no difference here. So I created a new column to the right of the "Text" and "Name" textboxes and added a dummy button there, and the borders appeared (see this new attachment). So for some reason, when the textbox has nothing to its right side, then borders are not rendered. Do you see any reason why this might happen?
(In reply to Rafael Lima from comment #18) > So for some reason, when the textbox has nothing to its right side, then > borders are not rendered. Do you see any reason why this might happen? Nothing that comes to my mind immediately. The whole thing *might* somehow be related to the fact that Breeze defines a frame width of 2, but only has a border of 1 pixel and then a margin of another pixel around that. Maybe sth gets drawn over the actual border and only the margin is left? The commits and related commits/changes from tdf#140088, tdf#138010 and tdf#152073 might give some more ideas on where to potentially look. Don't know how a textbox would influence that, but...
I noticed that the issue is reproducible for me as well when I apply scaling, e.g. starting LO Calc with env var QT_SCALE_FACTOR=2.0 set and then open the conditional formatting dialog. No issue with the 100 % scaling I use otherwise. @Rafael: Do you have any scaling applied as well? `QtGraphics_Controls::getNativeControlRegion` and `QtGraphics_Controls::drawNativeControl` *might* be good places to start looking deeper into that, in particular looking into the upscale/downscale calls in there. (Maybe some rounding issue,...?) Would you be interested in looking further into that yourself?
(In reply to Michael Weghorn from comment #20) > @Rafael: Do you have any scaling applied as well? I have no scaling on my end. I'm using a 1080p display with 100% scaling. When I use QT_SCALE_FACTOR=2.0 I also get no borders. But in my case I get no borders regardless of QT_SCALE_FACTOR. BTW the best dialog to check these borders is Tools - Options - User Data, because it has a lot of text boxes and it makes it easier to see the results. > Would you be interested in looking further into that yourself? Yes... I'll take a look. If I can't fix it, I'll share my findings here.
(In reply to Rafael Lima from comment #21) > I have no scaling on my end. I'm using a 1080p display with 100% scaling. > When I use QT_SCALE_FACTOR=2.0 I also get no borders. > > But in my case I get no borders regardless of QT_SCALE_FACTOR. Interesting. So there must still be some other aspect that causes this. > BTW the best dialog to check these borders is Tools - Options - User Data, > because it has a lot of text boxes and it makes it easier to see the results. Here too, all textboxes have borders for me with QT_SCALE_FACTOR=1 or QT_SCALE_FACTOR=1.25, but no textbox has borders with QT_SCALE_FACTOR=1.5 or QT_SCALE_FACTOR=2. (The comboboxes have borders for all scale factors.) > Yes... I'll take a look. If I can't fix it, I'll share my findings here. Great, thanks!
Created attachment 185239 [details] Screenshots comparing the "Options" dialog These screenshots compare: 1) The current bug in LO 7.5 using the Tools - Options dialog 2) The result when applied the "loop" change proposed by MW Notice that in (2) there's an additional spacing being added between the LineEdits.
Created attachment 185241 [details] Terminal dump analysing the patch This is what gets logged to the terminal in 2 cases: 1) With the loop proposed by MW enabled (boundingRect have 34px height) 2) Without the loop (boundingRect have 30px height)
For future reference, all the discussion about attachment 185239 [details] and attachment 185241 [details] is documented in the proposed patch at: https://gerrit.libreoffice.org/c/core/+/146516
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.
Setting to VERIFIED since both Rafael and I tested this successfully.
Rafael Lima committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/43c1de9f68a589304f060d2e662dc37c842a2a67 tdf#150451 Fix borders in Editbox controls (kf5) It will be available in 7.5.2. 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.