Created attachment 62464 [details] Toolbar before close There is a repaint issue after closing a toolbar with "Close Toolbar" from the context menu. Steps to reproduce: 1. Right click on any toolbar (i.e. Formatting Toolbar or List Toolbar) and select "Close Toolbar" from the context menu. If it is the last toolbar in this "row" there is a repaint issue. See attachments. Specs: Linux, 32 bit, master (27cd9157ac0e824197aa40c67fe6a4bfab3b2e38)
Created attachment 62465 [details] Toolbar after closing with issue
Also affects Libo 3.5.4 release (not checked earlier releases).
I am not 100% sure whether I understand the problem. If the problem is that the place for the toolbar remains I can reproduce the problem with "LibreOffice 3.5.4.2 German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit): 1. Open a new empty WRITER document 2. Arrange toolbars so that only docked Find Bar remains at the bottom. 3. <control+f> will make the Find Bar appear (as expected 4. <esc> will make the Find Bar disappear, and as expected also the room for the toolbar disappears 5. <control+f> will make the Find Bar appear 6. right click on find Bar 7. Context menu 'Close Toolbar' Expected: as on step 4 Actual: unexpectedly the room for the toolbar remains Room also disappears when I close toolbar from Menu 'View'. The inconsistence I observed was not in 3.3.3 (I tested with DRAWING toolbar in WRITER), but already in 3.4.1RC @Thomas: Did I describe the correct problem? Please feel free to revert my changes if I am wrong.
Rainer: Yes, absolutely correct. This issue remains with all toolbars, if they are the one and only in one "row" like the Findbar. For example: Right click on the standard toolbar and close it within the context menu. The room will remain until the window gets resized.
@Ivan: Willing to do some more UI cleanup?
Hmm... I am not an expert in this area, but... commit a81b5347 [1] fixed "Bug 67769 - Toolbar closed with toolbar menu "Close ..." reappears unexpectedly"[2] using DockingWindow::Close (toolbar is a subclass of DockingWindow) instead of LayoutManager::destroyElement, claiming that LayoutManager is a listener, so it will react on toolbar closing. And the fix was verified, so it worked at that time (2007). But now it does not work, it seems LayoutManager does not aware of toolbar closing. No idea of why and how it was broken between 3.3 and 3.4 (I wonder why it worked before). If I place back the old destroyElement call, this bug is not reproducible and the old Bug 67769 is... still not reproducible! :) So, probably that is what I will do. [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=a81b5347 [2] https://issues.apache.org/ooo/show_bug.cgi?id=67769 P.S. Reproducible also with AOO 3.4, I did not test 3.3...
> If I place back the old destroyElement call, this bug is not reproducible and > the old Bug 67769 is... still not reproducible! No, it is reproducible, with the "Form Controls" toolbar... Actually there was a huge refactoring, and now ToolbarLayoutManager is a listener for toolbar closing, not LayoutManager.
Ivan Timofeev committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=04ffb240d904d04875f91efae333efa605233ad5&g=libreoffice-3-6 fdo#50651: update layout after toolbar destruction It will be available in LibreOffice 3.6.
Ivan Timofeev committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca9967344682a0d3e25d7ebcc9df2c679cb082f8 fdo#50651: update layout after toolbar destruction
*** Bug 36475 has been marked as a duplicate of this bug. ***
We need exact and correct target information for automated lists in Wiki and LibO Web Site.
*** Bug 52466 has been marked as a duplicate of this bug. ***