After using LibreOffice for a while, most users end up with different placement for its toolbars. View > Toolbars > Reset would imply such menu option resets the toolbars placement and customization, but it's always greyed out - I tried this only in Writer and Impress. As a workaround, going to Tools > Customize > Toolbars > Reset has the intended effect.
I tested this in Ubuntu Natty (11.04). Filed in Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/771542
No idea how to test that systematically, but effect seems to be NOT reproducible with "LibreOffice 3.3.2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]". for my steps to get it active please see attached demo @Fabian Rodriguez: Currently I can't see any bug, do you still see reasons to leave this report open?
Created attachment 46107 [details] Demo, see Comment 1
Created attachment 46108 [details] New demo, see Comment 1. There was a Mistake in first demo
Closing Bug due to reporter's inactivity as WFM. @reporter: Please feel free to reopen this bug if you find out that the problem still exists with the current stable LibreOffice version and if you can contribute requested additional information due to <http://wiki.documentfoundation.org/BugReport> (especially BugReport Details)!
Screencast verifying problem in Ubuntu 11.04, LibreOffice Writer: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/771542/+attachment/2124775/+files/out.ogv.bz2 lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 apt-cache policy libreoffice-writer libreoffice-writer: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-proposed/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
(In reply to comment #6) > Screencast verifying problem in Ubuntu 11.04, LibreOffice Writer: @Christopher M. Penalver To be honest: your screencast without any comments did not tell me anything, but it was a motive for me to recheck my results. I found out that my demo2 still contains a distorting mistake (I wrote "Drawing Toolbar" Instead of "Drawing Object Prperties", so I will create a new ans more simple one. The new demo is concerning an other Toolbar, because I was not able to reproduce my results with D O P Toolbar. The main result is that there really seems to be a problem, but not with the Reset Item, but with the behavior of select / unselect toolbars.
Created attachment 46623 [details] New demo, see Comment 7. There also was a mistake in second demo
Possibly a sideeffect of: https://bugs.launchpad.net/df-libreoffice/+bug/709778 https://bugs.freedesktop.org/show_bug.cgi?id=36684 ? Could you recheck if this is still an issue with the fix applied?
Björn Michaelsen, as per comment #6 this was reproduced in Natty LO proposed.
(In reply to comment #10) > Björn Michaelsen, as per comment #6 this was reproduced in Natty LO proposed. But is it gone in the 3.4 branch?
(In reply to comment #11) > (In reply to comment #10) > > Björn Michaelsen, as per comment #6 this was reproduced in Natty LO proposed. > > But is it gone in the 3.4 branch? Reproducible in 3.4 branch. lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 LibreOffice 3.4.0 DEV300m103(Build:5)
Cannot reproduce this anymore on current 3-4 branch build. Resolving as WORKSFORME. ===== main repo ===== * libreoffice-3-4 6fe966b lo-pack-sources: do not pack fetched stuff into the source tarball ===== artwork ===== * libreoffice-3-4 f65839c Fix wrong-sized toolbar mimetype icons. ===== base ===== * libreoffice-3-4 2f36518 Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== calc ===== * libreoffice-3-4 10feb42 fdo#37458: Prevent crash on named range deletion. ===== components ===== * libreoffice-3-4 b41854c 3rd update to Mac dmg background. ===== extensions ===== * libreoffice-3-4 a22d8e9 Removed GNUism in makefile ===== extras ===== * libreoffice-3-4 a2ed323 Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== filters ===== * libreoffice-3-4 2215258 fix config for pptx filter - thanks to Bubli ===== help ===== * libreoffice-3-4 4fff103 Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== impress ===== * libreoffice-3-4 e46599a fix sdfilt component generation ===== libs-core ===== * libreoffice-3-4 9558424 fdo#37001 - updated license information ===== libs-extern ===== * libreoffice-3-4 cfcc2de Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== libs-extern-sys ===== * libreoffice-3-4 e256384 remove added license header that caused parse error (fdo#37433) ===== libs-gui ===== * libreoffice-3-4 125a64c revert previous patch for now. ===== postprocess ===== * libreoffice-3-4 e6be5b9 add sdfilt component ===== sdk ===== * libreoffice-3-4 77a19d3 Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== testing ===== * libreoffice-3-4 4a57e4b fdo#37325: make toolkit.UnoScrollBarControl not fail headless ===== ure ===== * libreoffice-3-4 8088ce0 Version 3.4.0.1, tag libreoffice-3.4.0.1 (3.4.0-rc1) ===== writer ===== * libreoffice-3-4 87c6a67 fix for ww8 export of relative hyperlinks: i#115297
closing
Reopening, I can reproduce this on 3.5.3. Toolbar is not greyed out at start, but is greyed out after adding a toolbar. So it the wrong way around.
Never confirmed by QA team - moving to UNCONFIRMED.
Yes, the reset is always greyed out even though I add toolbars. Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Confirming that this bug is still present in LibreOffice 5.1.1.3 on Arch Linux (tested in Impress).
@Maxim - I thought this one might interest you.
I'll quote the help for this item: Choose View - Toolbars - Reset to reset the toolbars to their default context sensitive behavior. Now some toolbars will be shown automatically, dependent on the context. ---- i.e. what this menu item is supposed to do is to reset the visibility flag of context toolbars. "Context" toolbar is a toolbar that bound to a specific context, and usually shows/hides when the context changes. One example is the Formatting toolbar that visible when inside paragraph text, and hidden when a shape is selected. Such toolbars have the "ContextSensitive" property set to true in *WindowState.xcu files. This is *not* supposed to be the same as the "Reset" button in the customization dialog. I looked at the code, and that exactly what it does, so closing as NOTABUG.
Maxim Monastirsky, thank you for your efforts investigating this. To clarify, would there be a documentation improvement opportunity here? I ask given how the wording of the documentation in its present form would lead some to believe that the originally reported issue is still a live one, despite the code is doing what it is designed to do.
> To clarify, would there be a documentation improvement opportunity here? Yes, of course! If you (or anybody else) can propose amendments to the current text, I’m happy to prepare a patch.
Adolfo Jayme, thanks for the offer. Perhaps this would need to be taken to an appropriate mailing list (feel free to propose one as applicable). However, speaking to the following URL (and applicable in-program documentation): https://help.libreoffice.org/Common/Toolbars_3 changing it from: [START] Choose View - Toolbars - Reset to reset the toolbars to their default context sensitive behavior. Now some toolbars will be shown automatically, dependent on the context. [END] to something like: [START] Choose View - Toolbars - Reset to reset those toolbars with the ContextSensitive property set to true in *WindowState.xcu files. This will not reset all toolbars. An example of this is the Formatting toolbar that is visible when inside paragraph text, and hidden when a shape is selected. To reset other toolbars, one may choose View - Toolbars - Customize... - Toolbars - Reset [END] I would certainly advise additional input on this as I'm not nearly as familiar with this functionality to certify this is correct. However, from my vantage point it makes sense, and presents the mechanism as it truly is (versus what it implies today).
(In reply to Christopher M. Penalver from comment #24) > reset those toolbars with the > ContextSensitive property set to true in *WindowState.xcu files. I'm pretty sure that most users would have no idea what this means. *WindowState.xcu files don't even exist in the final build. Something like "context sensitive toolbars" could be much better here. > To reset other toolbars, one may choose View - Toolbars - Customize... - > Toolbars - Reset This isn't correct AFAIK. Customize... -> Toolbars -> Reset only resets the _customization_ of toolbars, not the visibility or position. On the other hand View -> Toolbars -> Reset only resets _visibility_ (and only of context sensitive toolbars).