Bug 45935 - libreoffice-kde: Oxygen dropdown menu has no border
Summary: libreoffice-kde: Oxygen dropdown menu has no border
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Extensions (show other bugs)
Version:
(earliest affected)
4.1.3.2 release
Hardware: All Linux (All)
: high normal
Assignee: Luboš Luňák
URL:
Whiteboard: target:4.3.0 target:4.1.0.5 target:4.2.3
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-11 10:27 UTC by Rafael Belmonte
Modified: 2015-02-20 13:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot (79.50 KB, image/png)
2012-02-11 10:27 UTC, Rafael Belmonte
Details
Screenshot to show the problem (144.87 KB, image/jpeg)
2012-05-06 16:56 UTC, Renato S. Yamane
Details
Oxygen rendered background - top highlighting (24.34 KB, image/png)
2014-02-19 12:39 UTC, Jan-Marek Glogowski
Details
Oxygen rendered background - bottom highlighting (24.65 KB, image/png)
2014-02-19 12:39 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Belmonte 2012-02-11 10:27:32 UTC
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.
Comment 1 Renato S. Yamane 2012-05-06 16:56:09 UTC
Created attachment 61111 [details]
Screenshot to show the problem

Same problem on Libreoffice 3.5.2 (Kubuntu 12.04).
Comment 2 Renato S. Yamane 2012-05-13 07:10:01 UTC
Confirmed on 3.5.3 too
Comment 3 sato-san 2012-07-25 13:08:10 UTC
On the new version is not fixed also, very sad. Whats the issue?
Comment 4 Renato S. Yamane 2012-07-26 12:52:39 UTC
Confirmed on 3.5.5.3 (PPA on Kubuntu 12.04)
Comment 5 Renato S. Yamane 2012-11-11 19:46:38 UTC
Confirmed on 3.6.6.2 on Kubuntu 12.10
Comment 6 Renato S. Yamane 2012-11-11 19:47:19 UTC
(In reply to comment #5)
> Confirmed on 3.6.6.2 on Kubuntu 12.10

3.6.2.2
Comment 7 manabohzo7 2013-03-28 18:10:44 UTC
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).
Comment 8 manabohzo7 2013-09-03 18:05:26 UTC
Still exists with version 4.1.1.2.
Comment 9 Renato S. Yamane 2013-12-18 21:35:20 UTC
Still exists on 4.1.4
This bug is very annoying!
Comment 10 Jan-Marek Glogowski 2014-02-17 12:24:30 UTC
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?
Comment 11 Jan-Marek Glogowski 2014-02-19 12:39:02 UTC
Created attachment 94350 [details]
Oxygen rendered background - top highlighting
Comment 12 Jan-Marek Glogowski 2014-02-19 12:39:28 UTC
Created attachment 94351 [details]
Oxygen rendered background - bottom highlighting
Comment 13 Jan-Marek Glogowski 2014-02-19 12:44:02 UTC
I just added two images of the Qxygen themed menu to show the highlighting problem. Additionally the disabled menu entries are almost unreadable.
Comment 14 Commit Notification 2014-03-03 10:51:21 UTC
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.
Comment 15 Commit Notification 2014-03-03 11:34:58 UTC
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.
Comment 16 Commit Notification 2014-03-05 14:28:46 UTC
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.