Bug #995330 “[Upstream] Libreoffice has no border on menus (KDE)...” : Bugs : libreoffice package : Ubuntu

Revision history for this message

In freedesktop.org Bugzilla #45935, Rafael Belmonte (eaglescreen) wrote on 2012-02-11:

#3

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.

Revision history for this message

Renato S. Yamane (renatoyamane) wrote on 2012-05-06:

#1

no_border.jpeg Edit (144.9 KiB, image/jpeg)
Dependencies.txt Edit (9.1 KiB, text/plain; charset="utf-8")

Revision history for this message

penalvch (penalvch) wrote on 2012-05-06:

#2

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

penalvch (penalvch) on 2012-05-06

summary:

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

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2012-05-06:

#4

Created attachment 61111
Screenshot to show the problem

Same problem on Libreoffice 3.5.2 (Kubuntu 12.04).

Bug Watch Updater (bug-watch-updater) on 2012-05-07

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

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2012-05-13:

#5

Confirmed on 3.5.3 too

Revision history for this message

ejan (ehsanullahjan) wrote on 2012-05-25:

#6

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?

Revision history for this message

ejan (ehsanullahjan) wrote on 2012-05-26:

#7

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.

Revision history for this message

In freedesktop.org Bugzilla #45935, ejan (ehsanullahjan) wrote on 2012-05-26:

#8

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!

Revision history for this message

ejan (ehsanullahjan) wrote on 2012-05-26:

#9

libreoffice-overlapping-menus.png Edit (72.6 KiB, image/png)

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.

Revision history for this message

In freedesktop.org Bugzilla #45935, R.Sato (bujin2006) wrote on 2012-07-25:

#10

On the new version is not fixed also, very sad. Whats the issue?

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2012-07-26:

#11

Confirmed on 3.5.5.3 (PPA on Kubuntu 12.04)

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2012-11-11:

#12

Confirmed on 3.6.6.2 on Kubuntu 12.10

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2012-11-11:

#13

(In reply to comment #5)
> Confirmed on 3.6.6.2 on Kubuntu 12.10

3.6.2.2

Revision history for this message

Julien Fouquet (julien-fouquet) wrote on 2012-12-10:

#14

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.

Revision history for this message

Julien Fouquet (julien-fouquet) wrote on 2012-12-10:

#15

Picture of menus in libreoffice working great with libreoffice-gtk instead of libreoffice-kde. Edit (57.9 KiB, image/png)

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

Revision history for this message

Renato S. Yamane (renatoyamane) wrote on 2013-01-05:

#16

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

Thanks,
Renato S. Yamane

Revision history for this message

In freedesktop.org Bugzilla #45935, Manabohzo7 (manabohzo7) wrote on 2013-03-28:

#17

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).

Revision history for this message

In freedesktop.org Bugzilla #45935, Manabohzo7 (manabohzo7) wrote on 2013-09-03:

#18

Still exists with version 4.1.1.2.

Revision history for this message

Renato S. Yamane (renatoyamane) wrote on 2013-10-19:

#19

Hello?
Anyone hear me?

Revision history for this message

In freedesktop.org Bugzilla #45935, Renato S. Yamane (renatoyamane) wrote on 2013-12-18:

#20

Still exists on 4.1.4
This bug is very annoying!

Revision history for this message

In freedesktop.org Bugzilla #45935, Jan-Marek Glogowski (jmglogow) wrote on 2014-02-17:

#21

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?