https://bugs.documentfoundation.org/show_bug.cgi?id=159358
--- Comment #4 from Michael Weghorn <[email protected]> --- This is similar on Windows, s. attachment 192151 (with additional annotations for below). (In reply to Heiko Tietze from comment #0) > The render context using GetDialogColor() is supposed to blend into the > dialog window. That works for gtk3 and gen but not qt5/qt6. An example is > the DialControl (Shape: Properties > Rotation). > > For better illustration I changed the Window Background via System Setting > > Appearance > Color. Earlier related discussion in Gerrit: https://gerrit.libreoffice.org/c/core/+/160460/comments/fd492d75_aaddd02b As mentioned there, I'm not sure that the dialog color is meant to be the same here. The control is actually within a tab page, which has a different background from the dialog color. It seems to me like it might be necessary to distinguish between two different colors, e.g.: * the one used for dialogs in general * the one used for tab pages/panes attachment 192151 shows what I mean. For Qt-based VCL plugins, the background color of the tab page is drawn in QtGraphics_Controls::drawNativeControl , the `type == ControlType::TabPane && part == ControlPart::Entire`case, probably similar for Windows. So if it's necessary to explicitly draw a background using a specific color, maybe it would be necessary to use/introduce a specific color for that, and not just use the dialog color? (Or define more clearly what DialogColor is meant to be, maybe Qt and Win should set it differently, if it's not needed for what my screenshot labels dialog color or anything else.) As mentioned in the discussion in the Gerrit change the existing, `GetActiveTabColor` sounds like it might be the right color, but at least currently doesn't behave as expected either for misc cases. Having a way to avoid having to explicitly draw any background seems like it might be the most elegant solution to me if reasonably possible, not sure whether/how that already works. One control that seems to do this right in a quick test is `SvxPageWindow`, s. `SvxPageWindow::DrawPage`, which seems to have some smart handling using `bResetBackground` to decide whether or not the background needs to be drawn explicitly. In Writer: "Format" -> "Page Style" -> "Headers" tab (the preview of the page) `TabPage::ImplInit` also has something that sounds like some approach along that line has been implemented for some case at least: https://git.libreoffice.org/core/+/863a4cde77a5045d44b1da583f00c0a72762f19a/vcl/source/window/tabpage.cxx#67 // if the tabpage is drawn (ie filled) by a native widget, make sure all controls will have transparent background // otherwise they will paint with a wrong background The `IsNativeControlSupported` call there currently doesn't return `true` for the qt case, but doing so in a quick hack doesn't make any difference for the case of the specific widget mentioned here that explicitly draws a background. -- You are receiving this mail because: You are the assignee for the bug.
