Created attachment 56900 [details] Screenshot Using LibreOffice in KDE desktop on Linux, with the libreoffice-kde package installed, I find that dropdown menus in applications like writer or calc hasn't border, this makes them ugly and confusing for the user because they seem to fade into the rest of the application gui.
Created attachment 61111 [details] Screenshot to show the problem Same problem on Libreoffice 3.5.2 (Kubuntu 12.04).
Confirmed on 3.5.3 too
On the new version is not fixed also, very sad. Whats the issue?
Confirmed on 3.5.5.3 (PPA on Kubuntu 12.04)
Confirmed on 3.6.6.2 on Kubuntu 12.10
(In reply to comment #5) > Confirmed on 3.6.6.2 on Kubuntu 12.10 3.6.2.2
Still exists with version 4.0.1.2. This is unforunately a highly visible bug that doesn't seem to get much attention. This is probably a result of the removal of default shadows from KDE: http://blog.martin-graesslin.com/blog/2011/08/shadow-and-no-oxygen/ A workaround is to install libreoffice-gtk plugins instead and let oxygen-gtk handle the shadow. This causes several new issues of its own though (such as the gnome file dialog instead of KDE's).
Still exists with version 4.1.1.2.
Still exists on 4.1.4 This bug is very annoying!
I did some research on this bug while thinking of a resolution for #74416. Currently the KDE4 backend works like this: * Get a control request * Generate a QImage with the requested size * Fill image with the QPalette::Window color * Draw the control with the theme style to the QImage * Blit / copy the image to the actual target This results in this - actually unstyled - dropdown menus. So for a test I changed the menu generation to a more Gtk+ backend approach: * Get the control request from vcl * Create a QMenu object * Resize the menu to the requested size * Copy the QMenu to a QImage using QImage(QPixmap::grabWidget(...).toImage()) * Draw the control with the theme style to the QImage * Blit / copy the image to the actual target This generates the correct background (yeah); but now I realized (to my increasing frustration), that the highlighting is actually drawn based on the background image with a different color. Probably just the opaque value is adapted - I didn't actually check the Oxygen code. To make the KDE theming using VCL even harder, Oxygen uses some kind of animation to fade the highlighting to the correct color, which won't work using the QImage based copy approach (and I also don't know how this actually works in the Oxygen Qt style engine). Additionally the QPixmap::toImage() call has additional drawbacks: "Note that for the moment, alpha masks on monochrome images are ignored." (http://qt-project.org/doc/qt-4.8/qpixmap.html#toImage) From my current point of understanding of all the interaction, the only realistic way to fix the styling problems is to draw LO native widgets using a real Qt widgets stack and let LO draw it's specific objects. I guess this will result in a complete rewrite of the KDE4 backend based on a new architecture - if this is possible using VCL. And there is already an abstraction for (popup) menus, which uses the same approach (SalMenu). Now I need to get some feedback, if this approach is implementable at all. I would start a kde4v2 backend, but this is a lot more work then I have currently time for: GSoC 2014 anyone?
Created attachment 94350 [details] Oxygen rendered background - top highlighting
Created attachment 94351 [details] Oxygen rendered background - bottom highlighting
I just added two images of the Qxygen themed menu to show the highlighting problem. Additionally the disabled menu entries are almost unreadable.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e72849cd435cc50a744dcbcfb422f5600dd0cce9 fdo#45935: try hard to paint a frame for menus The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "private/jmux/libreoffice-4-1+fixes": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c00aeced3c69f28ff02edee2813d58bd8c7f5c43&h=private/jmux/libreoffice-4-1+fixes fdo#45935: try hard to paint a frame for menus It will be available in LibreOffice 4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b6398b72401b35dc0d01de70ee2124a0a4072a8&h=libreoffice-4-2 fdo#45935: try hard to paint a frame for menus It will be available in LibreOffice 4.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.