If I close the only docked toolbar in a particular row or column via the context menu, an empty row or column is left. This empty row/column disappears when other toolbars are docked or undocked.
Yes. e.g. open Writer, right click over the Format Toolbar > Close toolbar. An empty strip still visible in the UI.
Confirmed
*** Bug 37560 has been marked as a duplicate of this bug. ***
Confirmed in 3.4 Release LibreOffice 3.4.0 OOO340m1 (Build:12) Easy Workaround: Dbl-click twice on top frame of window or resize the window: the blank (extra) toolbar space disappears -> importance to low-minor
I agree that severity is low, but it gives to user a bad impression. LibO has many little UI problem, especially under Windows, that are not present in OpenOffice. Users "feel" the program less painstaking and less stable.
(In reply to comment #5) > I agree that severity is low, but it gives to user a bad impression. No problem with higher importance but has no effect on data or utility and goes away naturally I agree that the empty toolbar slot *is* fugly (seems bigger than it was/is 8-o) and it is possible to create a big pile of grey matter in this way ... The Find bar has interesting behavior in this regard: ***When closed with Esc the Find bar leaves no empty space, yet if it is closed with v menu->Close then empty space is left. Other menus have no hotkey close (that I know) and it seems they all leave empty space when closed via menu (as last toolbar in row and presumably as last-in-column). Marked as Easy Hack because Find toolbar Esc handler seems to know what to do - perhaps just code needing to be re-used (lcl_ function?) in *all* toolbar Close handlers (incl. Find). EasyHack clue: Kendy (Jan Holesovsky) wrote the Find bar.
Test grease script, complete EasyHack mark
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle.
*** Bug 42674 has been marked as a duplicate of this bug. ***
*** Bug 45128 has been marked as a duplicate of this bug. ***
In order this to be a proper Easy Hack, we need some code pointers ;-) So, the (some toolbar) -> Close toolbar functionality seems to be "MENUITEM_TOOLBAR_CLOSE", implemented here: http://opengrok.libreoffice.org/xref/core/framework/source/uielement/toolbarmanager.cxx#1969 It calls ToolBarManager's ExecuteHdl_Impl() method with information about the toolbar, which ends up here: http://opengrok.libreoffice.org/xref/core/framework/source/uielement/toolbarmanager.cxx#2165 The Esc handler of Findbar on the contrary does this: http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunosearchcontrollers.cxx#139 It turns out the ExecuteHdl_Impl() [toolbarmanager.cxx#2165] already has the xLayoutManager, so instead of the dynamic cast & calling Close, I'd try if we can do xLayoutManager->hideElement(pExecuteInfo->aToolbarResName) followed by xLayoutManager->destroyElement(pExecuteInfo->aToolbarResName) as in the findbar. If this gets more complicated, please ping me :-)
*** Bug 48945 has been marked as a duplicate of this bug. ***
Deleted "Easyhack" from summary.
Just fixed by Ivan Timofeev at another bug => duplicate. *** This bug has been marked as a duplicate of bug 50651 ***
Migrating Whiteboard tags to Keywords: (EasyHack) [NinjaEdit]