Description of problem: The menu for controlling the recording and display of changes in a text document is incorrectly displayed: - not all checkbuttons are displayed - as you move the pointer over the menu, some - so far - not displayed checkbuttons become visible, other disappear - selecting a checkbutton (probably / apprently) modifies the corresponding variable in lo., but the display of the checkbutton is not correspondingly updated, This is rather messy - difficult to formulate a clearer bug description Version-Release number of selected component (if applicable): libreoffice-writer-3.3.2.2-12.mga1 How reproducible: always Steps to Reproduce: 1. open an existing .odt document (same problem is the document is .doc) and select some text zone 2. do Edit->Changes 3. try to select (check) a checkbutton (say the "Record" or the "Show" button) The checkbutton display is not modified in consequence, but l.o. apparently reacts to the modification - difficult to see what happens, lacking visible feedback. As a consequence, the "Changes" features in libreoffice are practically un-usable. This is a show stopper if you work in a group that jointly produces/edits a document.
I can reproduce this bug, with libreoffice-kde installed _and_ with the KDE widget style set to IaOra-kde. Setting the KDE widget style to Oxygen or Plastique makes the check marks appear correctly. FWIW, I think libreoffice-kde is more trouble than gain, with it: - there's no visual feed back when hovering over a button on the toolbars in LO - anomalies such as that check mark bug (in this report) appear oxygen-gtk gives a much more Oxygen-ised look to LO, but without libreoffice-kde you lose the KDE file chooser in LO, i.e. without it LO uses its own file picker/chooser dialogue/widget. (IMHO, libreoffice-kde shouldn't be shipped, or if shipped should be dubbed with "experimental" or something like that in the summary).
CC: (none) => ennael1Assignee: bugsquad => dmorganecSource RPM: libreoffice-writer => libreoffice-kde
P.S. if my assessment about the cause of the bug is wrong, please revert the the report summary changes I did.
Summary: Libreoffice Edit->Change menu display is faulty => Libreoffice Edit->Change menu display is faulty under KDE4 with libreoffice-kde installed
Your modification to the report summary is OK. I had not tried with other KDE styles (in fact I normally use Oxygen - but so far kept what comes out of the box to economize time on KDE setup while testing). Changing the style to Oxygen is a good workaround. Suggestions if the bug persists until the official becomes released: - ship KDE with Oxygen installed by default (hopefully Oxygen does not introduce other problems - I will use it as off now and see) - and/or put a note with the workaround into the release notes (release errors) That might justify lowering the severity to normal
Or libreoffice-kde shouldn't be installed by default, then only caveat is losing the kde file picker integration, but given that one usually spends more on working/editing a document than saving it, I think that's a good trade off.
That is a fair alternative. The L.O file picker is intuitive enough not to shock somebody who expects "KDE behaviour". Just testing how L.O works without libreoffice-KDE, I realised that the L.O user interface has quite some other glitches that disappear when that module is un-installed. Assuming that L.O will fix this problem some time: how is the way back? - or should there be no way back since the KDE interface yet adds heaviness to something that is already overweight?
With all due respect to L.O. upstream devs who worked on the -kde integration, they got the file picker integration right, but the widget style "Oxygen"isation was bad from the word go, IMHO. OTOH, upstream KDE devs who created oxygen-gtk got all the theme'ing right in the oxygen-gtk engine... I think L.O. and oxygen-gtk devs should communicate, maybe upstream L.O. can drop the widget styling from libreoffice-kde and keep only the KDE file picker integration, and if users was Oxygen looks under KDE they can use oxygen-gtk (which is mature enough now that most of the major distros are planning on shipping it by default).
libreoffice-kde also caused other problems. Please see bug 815: Some chinese characters in the ui displayed as unreadable squares.
CC: (none) => yochenhsieh
Added to the Errata http://www.mageia.org/wiki/doku.php?id=mageia1:errata#libreoffice-kde_issues .
Any news on this bug?
CC: (none) => marja11
Whiteboard: (none) => Errata
what about this on latest cauldron ? with LO 3.5
(In reply to comment #10) > what about this on latest cauldron ? with LO 3.5 @ Juergen Can you reply please, is this bug still there? (I don't have time to read what this bug is about, nor to try to reproduce it)
Whiteboard: Errata => Errata NEEDINFO
Looks OK now, I think the bug can be closed
(In reply to comment #12) > Looks OK now, I think the bug can be closed Ok great, Thanks
Status: NEW => RESOLVEDResolution: (none) => FIXEDWhiteboard: Errata NEEDINFO => Errata