Download it now!
Bug 136094 - Background color doesn't work for all UNO controls (gtk3/kf5)
Summary: Background color doesn't work for all UNO controls (gtk3/kf5)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:7.1.0 target:7.0.2
Keywords:
: 128124 (view as bug list)
Depends on:
Blocks: KDE GTK3
  Show dependency treegraph
 
Reported: 2020-08-25 05:56 UTC by Michael Weghorn
Modified: 2020-09-18 08:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample doc containing dialog with form controls that have background color (9.36 KB, application/vnd.oasis.opendocument.text)
2020-08-25 05:57 UTC, Michael Weghorn
Details
Document with screenshot showing behaviour on different platforms/with different VCL plugins (112.28 KB, application/pdf)
2020-08-25 05:58 UTC, Michael Weghorn
Details
screenshot on macOS (46.28 KB, image/png)
2020-08-25 12:07 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2020-08-25 05:56:58 UTC
Description:
When setting a background color for UNO controls, it is not correctly shown for all types of controls when the gtk3 or kf5 VCL plugins are used on Linux, while it works correctly for the gen VCL plugin on Linux or on Windows.

Steps to Reproduce:
1. open attached sample document "formcontrol_colors.odt"
2. go to "Tools" -> "Macros" -> "Organize Dialogs"
3. open the test dialog contained in the document: "formcontrol_colors.odt" -> "Standard" -> "testdialog", click "Edit"
  -> a dialog with various controls shows up, some of which have a background color set
4. start the preview dialog (third icon in the toolbar at the bottom)
5. compare the colors shown in the preview dialog to those in the editable dialog shown before

Actual Results:
When using the gtk3 VCL plugin:

* background color missing for the combobox at the right
* background color missing for the edit at the bottom

When using the kf5 VCL plugin:

* background color missing for the combobox at the right
* background color missing for the multiline edit at the top
* background color missing for the edit at the bottom



Expected Results:
Background colors in the preview dialog should be the same as those shown/set in previously, regardless of the platform/VCL plugin.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.1.0.0.alpha0+
Build ID: bf3124cdf61b40c94ba117a76f1b63dabdfd528e
CPU threads: 12; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.0.0.alpha0+
Build ID: bf3124cdf61b40c94ba117a76f1b63dabdfd528e
CPU threads: 12; OS: Linux 5.7; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded


All colors are shown as expected when using the gen/x11 VCL plugin and on Windows (same result with Skia enabled and disabled):

Version: 7.1.0.0.alpha0+
Build ID: bf3124cdf61b40c94ba117a76f1b63dabdfd528e
CPU threads: 12; OS: Linux 5.7; UI render: default; VCL: x11
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8700bace8c0714d853f5df6918ab9c8bb3d81f77
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8700bace8c0714d853f5df6918ab9c8bb3d81f77
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 1 Michael Weghorn 2020-08-25 05:57:36 UTC
Created attachment 164654 [details]
Sample doc containing dialog with form controls that have background color
Comment 2 Michael Weghorn 2020-08-25 05:58:49 UTC
Created attachment 164655 [details]
Document with screenshot showing behaviour on different platforms/with different VCL plugins

This PDF file contains screenshots for Windows and the different VCL plugins on Linux.
Comment 3 Michael Weghorn 2020-08-25 06:01:36 UTC
This bug was initially reported to me by a WollMux [1] developer, since they are working on replacing a Java Swing based form GUI by using the LibreOffice sidebar and LO controls, and background color is used e.g. to indicate invalid input/values in a form.

WIP patch at https://gerrit.libreoffice.org/c/core/+/101284

[1] https://github.com/wollmux/wollmux
Comment 4 Michael Weghorn 2020-08-25 06:03:29 UTC
Other than the background color for the controls, setting font colors etc. worked as expected in a quick test.
Comment 5 Michael Weghorn 2020-08-25 12:07:07 UTC
Created attachment 164671 [details]
screenshot on macOS

This screenshot with master as of bf3124cdf61b40c94ba117a76f1b63dabdfd528e shows macOS, where more than just the background color is broken...

I don't intend to look into this myself, just double-checked my patch in Gerrit does not affect the behavior there.
Comment 6 Commit Notification 2020-08-25 12:17:34 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2c9052802ea411dffbf5906c4914611fcbfbc6a5

tdf#136094 Handle background color in drawNativeControl

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 7 Michael Weghorn 2020-08-25 12:32:52 UTC
Patch from comment 6 fixes the gtk3 case; kf5 needs to be handled separately.
Comment 8 Noel Grandin 2020-08-25 12:46:31 UTC
the macOS code in drawNativeControl uses a truly ancient mac API that does not expose the ability to override such things, so that is no surprise.
Comment 9 Michael Weghorn 2020-08-25 12:56:15 UTC
(In reply to Noel Grandin from comment #8)
> the macOS code in drawNativeControl uses a truly ancient mac API that does
> not expose the ability to override such things, so that is no surprise.

if anybody wants to take a look at this, please feel free :)

I plan to implement the qt5/kf5 part, but have ~zero macOS experience.
Comment 10 Commit Notification 2020-09-03 15:42:15 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/e944b2d62b499f4d9392cf5ce067b905bc2d67ab

tdf#136094 Handle background color in drawNativeControl

It will be available in 7.0.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.
Comment 11 Commit Notification 2020-09-17 15:15:55 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/391f17a5fbcf9cd918efa10321219f87409d2412

tdf#136094 qt5: Handle bg color in drawNativeControl

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 12 Michael Weghorn 2020-09-18 04:35:14 UTC
Closing as fixed, since background color handling for gtk3 and kf5 has been implemented.

There's still an issue with the multiline edit for the kf5 case; I've created a separate bug report for this: tdf#136866
Comment 13 Michael Weghorn 2020-09-18 08:33:14 UTC
*** Bug 128124 has been marked as a duplicate of this bug. ***