Bug 36475 - Toolbar space remains after close of last in row/column
Summary: Toolbar space remains after close of last in row/column
Status: RESOLVED DUPLICATE of bug 50651
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.4.0 release
Hardware: Other All
: low minor
Assignee: Not Assigned
Whiteboard: bibisected35 bibisected35older
Keywords: easyHack, regression
: 37560 42674 45128 48945 (view as bug list)
Depends on:
Reported: 2011-04-22 02:04 UTC by Ed
Modified: 2015-12-17 06:49 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Ed 2011-04-22 02:04:32 UTC
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.
Comment 1 vitriol 2011-04-22 02:28:30 UTC
Yes. e.g. open Writer, right click over the Format Toolbar > Close toolbar. An empty strip still visible in the UI.
Comment 2 Zack 2011-04-27 16:14:33 UTC
Comment 3 vitriol 2011-05-24 23:21:24 UTC
*** Bug 37560 has been marked as a duplicate of this bug. ***
Comment 4 LeMoyne Castle 2011-06-15 01:02:28 UTC
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
Comment 5 vitriol 2011-06-15 01:16:25 UTC
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.
Comment 6 LeMoyne Castle 2011-06-15 02:21:17 UTC
(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.
Comment 7 LeMoyne Castle 2011-06-16 17:58:09 UTC
Test grease script, complete EasyHack mark
Comment 8 Björn Michaelsen 2011-12-23 12:05:00 UTC
[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:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 9 Björn Michaelsen 2011-12-23 12:57:08 UTC
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.
Comment 10 Harald Koester 2012-02-03 09:30:28 UTC
*** Bug 42674 has been marked as a duplicate of this bug. ***
Comment 11 Harald Koester 2012-02-03 09:31:38 UTC
*** Bug 45128 has been marked as a duplicate of this bug. ***
Comment 12 Jan Holesovsky 2012-03-30 05:17:09 UTC
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:


It calls ToolBarManager's ExecuteHdl_Impl() method with information about the toolbar, which ends up here:


The Esc handler of Findbar on the contrary does this:


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 :-)
Comment 13 vitriol 2012-04-22 11:03:56 UTC
*** Bug 48945 has been marked as a duplicate of this bug. ***
Comment 14 Florian Reisinger 2012-05-18 09:33:52 UTC
Deleted "Easyhack" from summary.
Comment 15 Korrawit Pruegsanusak 2012-06-06 01:40:52 UTC
Just fixed by Ivan Timofeev at another bug => duplicate.

*** This bug has been marked as a duplicate of bug 50651 ***
Comment 16 Robinson Tryon (qubit) 2015-12-17 06:49:56 UTC
Migrating Whiteboard tags to Keywords: (EasyHack)