I like to have the sidebar floating outside the window so that it doesn't interfere with the page I'm writing), but both Command-W and clicking the "close" button don't *close* the Sidebar. Instead, they pop the sidebar back onto the side of the window. I have created a custom command to bring it up and remove it, but Command-W and the close button seem like they ought to close it, not reduce it.
Interesting find: Confirmed: Ubuntu 14.04 x64 LibreOffice 4.3.4.1 release Setting to: New Trivial - not going to impact work much at all, just a small detail. Easy workaround to go to view -> sidebar to make it go away. Might have a very minor impact on speed of work but unlikely to impact many people. Lowest - default for trivial issues.
While it is easy enough to work around, this behavior is unexpected, inconsistent, and rather annoying. And with 4.4's efforts to reduce redundant dialogs, it looks like there will be no more avoiding the sidebar, since it'll be the new sole location for "styles and formatting." As minor as this bug seems, I think it'd go a long way towards making my transition to using the sidebar smoother. I prefer to have the sidebar disabled, or at least floating, since using a docked sidebar causes constant redraws and view adjustments. Also, another potential workaround is to choose "Close Sidebar" in the sidebar's menu to dismiss the sidebar properly.
It appears that there is specific code in the SidebarDockingWindow::Close function in sfx2/source/sidebar/SidebarDockingWindow.cxx that is commented: // Do not close the floating window. // Dock it and close just the deck instead. It then has specific code to return the sidebar to normal docked mode with a closed deck. If you comment out all of that code and only leave the following line, things appear to behave as I expect they should: return SfxDockingWindow::Close(); So, that change seems to be how to "fix" the sidebar, but the real issue now is that this behavior was intentional. Is there any chance we could have ux-advise look at this one?
Closing as Resolved Fixed. A "Close Sidebar" button has been added to Sidebar's tab bar menu for 4.4.0 release. With Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: en_US An undocked Sidebar closes when the "Close" button on its is clicked or its accelerator is selected, or when main menu View -> Sidebar is deselected. Unlike StartCenter, Sidebar behavior is stateful per LO Module, per user-profile. If you enable/disable and dock/undock--the settings will stick and are completely consistent across sessions. Sidebar Deck state, Size and position are retained. But for now, active module on opening of Sidebar will always be Properties. We are looking at allowing that to be selected. Nothing else here to "fix".
(In reply to V Stuart Foote from comment #4) > Closing as Resolved Fixed. > > A "Close Sidebar" button has been added to Sidebar's tab bar menu for 4.4.0 > release. > > With Version: 4.4.0.2 > Build ID: a3603970151a6ae2596acd62b70112f4d376b990 > Locale: en_US > > An undocked Sidebar closes when the "Close" button on its is clicked or its > accelerator is selected, or when main menu View -> Sidebar is deselected. I just tested this behavior again in the version you mentioned: Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: en_US and the sidebar suffers from the same behavior as originally reported. The sidebar closes properly when you use "Close Sidebar" from the sidebar's menu button or by using View->Sidebar. But clicking the "X" in the sidebar's window decoration does not close the sidebar. It still just docks the sidebar, leaves it enabled, and leaves you in a docked sidebar state for future sidebar calls.
(In reply to tmacalp from comment #5) > The sidebar closes properly when you use "Close Sidebar" from the sidebar's > menu button or by using View->Sidebar. But clicking the "X" in the > sidebar's window decoration does not close the sidebar. It still just docks > the sidebar, leaves it enabled, and leaves you in a docked sidebar state for > future sidebar calls. And...? Using an OS widget to close a dialog that way is done outside program control. LibreOffice just recovers the sidebar to the docked, deck-closed state. Nothing wrong there. If you want the Sidebar disabled from an undocked position, at that point use the Close Sidebar button or the View -> Sidebar deselect.
(In reply to V Stuart Foote from comment #6) > And...? > > Using an OS widget to close a dialog that way is done outside program > control. LibreOffice just recovers the sidebar to the docked, deck-closed > state. Nothing wrong there. > > If you want the Sidebar disabled from an undocked position, at that point > use the Close Sidebar button or the View -> Sidebar deselect. My only problem with that is that it makes it MUCH more difficult to keep the sidebar in an undocked state. The most intuitive way of dismissing a dialog is by using the window decorations. Instead of closing the dialog as I would rationally expect, it now reenables the sidebar and in a state that I'm trying to avoid. In 4.4.0+, I will be FORCED to use the sidebar for the "Styles and formatting" dialog. I would like to be able to use the sidebar to mimick the same behavior of the old dialog. With a few changes, I could use this new sidbar in a way that I'm use to. If you want an example, the proposed change would make the sidebar behave exactly like dismissing an undocked page pane in Draw. Clicking on the "X" window decorator for an undocked page pane in Draw does not reenable a docked page pane. It disables the page pane. When you use View->page pane, it reenables the undocked page pane.
The issue is that even if you deselect from view, when you close a dialog it re-enables the sidebar (go to view and see that sidebar is checked again...). Closing a dock should not reenable the dock if it was previously deselected in view
(In reply to Joel Madero from comment #8) > The issue is that even if you deselect from view, when you close a dialog it > re-enables the sidebar (go to view and see that sidebar is checked > again...). Closing a dock should not reenable the dock if it was previously > deselected in view I completely agree. If the user doesn't want the sidebar, he should not have to keep turning it off over and over again. tmacalp's examples are perfectly valid- nowhere else in LO does dismissing an undocked dialog window make it appear docked again. This new behavior in LO 4.4 is very irritating. It is imperative the design is as friendly as possible and allows the user the ability to keep it dismissed or undocked to as closely imitate the old behavior as possible. Some people are going to be very upset at the sidebar getting in the way. I do not believe this should be marked "Resolved/Fixed".
This needs further discussion in UX - please bring it up in the next UX chat meeting. Setting to NEW again for now - if you guys collectively decide not to do anything about it, so be it, but I hope you discuss it thoroughly.
It bears emphasizing that this behaviour is unlike all other toolbars, which leads me to suspect that it's specifically been programmed with the assumption that you're never going to want to dismiss it; that's why it doesn't fully go away unless you turn it right off. If that's the case, then it's actually very important to be able to call it up and dismiss it *without interrupting your work-flow*: e.g., by resizing the text every time you open or close it (which is highly irritating). Make it a slide-out menu or make it floating, but keeping it as a pseudo-toolbar would seem to be counter to its intended purpose (if I've read the intention correctly).
(In reply to Joel Madero from comment #8) > The issue is that even if you deselect from view, when you close a dialog it > re-enables the sidebar (go to view and see that sidebar is checked > again...). Closing a dock should not reenable the dock if it was previously > deselected in view Huh? Deselecting from View -> Sidebar closes the undocked Sidebar...
(In reply to tmacalp from comment #7) > In 4.4.0+, I will be FORCED to use the sidebar for the "Styles and > formatting" dialog. I would like to be able to use the sidebar to mimick > the same behavior of the old dialog. With a few changes, I could use this > new sidbar in a way that I'm use to. Yup, and you'll be especially "happy" to find that the Sidebar will only allow one dialog at a time. The Navigator can be up concurrently, but currently only one content panel in the Sidebar deck. Suggest you follow bug 85905 and bug 86016 (or the generic Meta for Sidebar bug 65138)
Steps to Reproduce: 1. Open writer; 2. View -> Sidebar (uncheck) Observed: Sidebar goes away (good) 3. Press F11 Observed: Styles Dialog opens (good) 4. Close styles dialog by pushing F11 or by pushing the X on the dialog Observed: Sidebar becomes reenabled Expected: Sidebar stays disabled as that was the last state that it was in prior to enabling the styles dialog.
Dangit sorry I missed a step - another round: Steps to Reproduce: 1. Open writer; 2. Undock sidebar 2. View -> Sidebar (uncheck) Observed: Sidebar goes away (good) 3. Press F11 Observed: Styles Dialog opens (good) 4. Close styles dialog by pushing F11 or by pushing the X on the dialog Observed: Sidebar becomes reenabled but docked to the right again Expected: Sidebar stays disabled as that was the last state that it was in prior to enabling the styles dialog.
(In reply to Joel Madero from comment #15) > 4. Close styles dialog by pushing F11 or by pushing the X on the dialog Sorry, but here's a slight correction to Joel's steps. Pressing F11 again when you have an active undocked sidebar with "Styles and Formatting" enabled does not currently close the sidebar due to bug 88241. The step should be changed to just: 4. Close styles dialog by pushing the X on the dialog You could also close the sidebar in a manner that triggers this bug by using any window-manager related close call (Right-click titlebar -> Close, Click titlebar icon -> close, etc...). But all of those options depend on your window manager. The rest of the steps are still valid.
Based on the minutes from last week's UX chat meeting, I'll set the status back to NEW. https://wiki.documentfoundation.org/Design/Meetings/2015-01-14 "conclusion: The Window's closing button should indeed close the window, not dock the sidebar" I also submitted a simple patch to gerrit that should take care of this behavior, but it feels a bit hacky. I guess we'll see what happens when it's reviewed. https://gerrit.libreoffice.org/#/c/13979/
Trent MacAlpine committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=304e2002a053e9eb54e36462165eca831da8aeb2 fdo#87217 Inconsistent floating sidebar close behavior It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It has also been merged into 4.4.0 and 4.4 daily. https://gerrit.libreoffice.org/14022/ https://gerrit.libreoffice.org/14024/
(In reply to Jay Philips from comment #19) > It has also been merged into 4.4.0 and 4.4 daily. > > https://gerrit.libreoffice.org/14022/ > https://gerrit.libreoffice.org/14024/ Huh? Those commits are for an issue with calc...
Yep, those links are for another bug I was working on (bug 88339). I've just committed a backport to 4.4: https://gerrit.libreoffice.org/14025 But I guess it still needs to go to 4.4.0?
Sorry about that. :D Here is the patch for going into 4.4.0. https://gerrit.libreoffice.org/#/c/14037/
Trent MacAlpine committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=915469e5f70b179f4219d8f981802fcc9d5e6959&h=libreoffice-4-4 fdo#87217 Inconsistent floating sidebar close behavior It will be available in 4.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.