[Upstream] Libreoffice has no border on menus (KDE)

Bug #995330 reported by Renato S. Yamane on 2012-05-06
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
LibreOffice
In Progress
Medium
libreoffice (Ubuntu)
Wishlist
Unassigned

Bug Description

Libreoffice has no border on menus, with a bad appearance.
Image attached to show the problem.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libreoffice-kde 1:3.5.2-2ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Sat May 5 23:37:27 2012
InstallationMedia: Kubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120228.1)
ProcEnviron:
 LANGUAGE=pt_BR:pt:en
 LANG=pt_BR.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

Created attachment 56900
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.

Renato S. Yamane (renatoyamane) wrote :

Renato S. Yamane, thank you for reporting this and helping make Ubuntu better. However, this is:
- a clearcut upstream issue.
Resolving as Won't Fix in libreoffice (Ubuntu) and LibreOffice Packaging. This does not mean the issue will not be cared about, but if it is cared about (even by Ubuntu/Canonical contributors), it is done upstream at LibreOffice.

Changed in libreoffice (Ubuntu):
importance: Undecided → Wishlist
status: New → Won't Fix
summary: - Libreoffice has no border on menus (KDE)
+ [Upstream] Libreoffice has no border on menus (KDE)

Created attachment 61111
Screenshot to show the problem

Same problem on Libreoffice 3.5.2 (Kubuntu 12.04).

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → In Progress

Confirmed on 3.5.3 too

ejan (ehsanullahjan) wrote :

I also have the exact same issue (and I believe it's universal). I'm running Kubuntu 12.04 with all updates installed. Any chance it might get fixed anytime soon?

ejan (ehsanullahjan) wrote :

I've found a workaround that works on my machine...

1. Uninstall LibreOffice (I did a purge as shown below)
$ sudo apt-get --purge remove mozilla-libreoffice libreoffice*

2. Install OpenOffice (relax, that's a transitional package so you'll end up with LibreOffice only)
$ sudo apt-get install openoffice.org

That's it! Now when you open Calc or other LibreOffice programs, their menus should have normal look and the no-border issue should be gone.

Optionally, if you want to have additional UI styles available in LibreOffice, you can install the style packages as shown below:

$ sudo apt-get install openoffice.org-style-*

This will add a bunch of styles that you can choose from for your office programs from Tools | Options... menu and then navigating to the LibreOffice | View section.

Finally, if you prefer enabling opening LibreOffice documents directly in Firefox, you can install the mozilla-openoffice.org package:

$ sudo apt-get install mozilla-openoffice.org

Hope this helps.

Here's link to my comment on this bug with a workaround:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/995330/comments/7

And here's link to my blog post about the work around in a little more detail with screen shots:
http://soopertux.blogspot.com/2012/05/border-less-libreoffice-menus-in.html

Hope that helps!

ejan (ehsanullahjan) wrote :

OK, unfortunately there's one problem that you'll encounter after following what I've outlined in comment #7. Now, while the menus are perfect in how they look, sub-menus render on top of the parent menu itself. This issue doesn't affect all menus. In addition, when not running the program maximized, top-level menus render right-aligned in relation to the mouse-click (the norm is left-aligned).

I think this is not as annoying a problem as the no-border bug but still (the bug) needs to be fixed. I hope this bug gets fixed soon as it has a very high visibility.

I've attached a snap of how the sub-menus render on top of menus.

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

I also have this problem. I think I found an easy work-around. Just uninstall libreoffice-kde (purge it), and install libreoffice-gtk instead. Well, I said I *thought* I found a work-around since I tried to "fix" the problem in many different ways and when, after reinstalling from the Muon Software Center (Using Kubuntu 12.10) instead of the command line, I checked libreoffice and all was fine, nice look and all, menus working great. I noticed that libreoffice-kde was not installed, whereas libreoffice-gtk was.

I don't have a spare computer just to check it, and I don't want it broken again, so maybe someone can try that and tell us if that's an ok work-around.

Picture of menus in libreoffice working great with libreoffice-gtk instead of libreoffice-kde.

Yes, removing libreoffice-kde and installing libreoffice-gtk the border appears.

Thanks,
Renato S. Yamane

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.

Hello?
Anyone hear me?

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
Oxygen rendered background - top highlighting

Created attachment 94351
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.

Wow!
After 2 years, finally a developer take care of this issue!

Thank you so much Jan-Marek Glogowski!!

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.