Bug 87217 - the floating Sidebar moves back onto the side of the window at "closing"
Summary: the floating Sidebar moves back onto the side of the window at "closing"
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ux-advise (show other bugs)
Version:
(earliest affected)
4.3.4.1 release
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard: target:4.5.0 target:4.4.1
Keywords:
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2014-12-11 05:53 UTC by Orion
Modified: 2016-10-24 15:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Orion 2014-12-11 05:53:34 UTC
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.
Comment 1 Joel Madero 2014-12-12 05:35:01 UTC
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.
Comment 2 tmacalp 2015-01-05 21:46:37 UTC
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.
Comment 3 tmacalp 2015-01-11 21:08:42 UTC
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?
Comment 4 V Stuart Foote 2015-01-11 22:04:04 UTC
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".
Comment 5 tmacalp 2015-01-11 22:31:59 UTC
(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.
Comment 6 V Stuart Foote 2015-01-11 22:57:56 UTC
(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.
Comment 7 tmacalp 2015-01-11 23:15:41 UTC
(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.
Comment 8 Joel Madero 2015-01-11 23:17:17 UTC
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
Comment 9 crxssi 2015-01-11 23:39:53 UTC
(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".
Comment 10 Joel Madero 2015-01-11 23:46:49 UTC
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.
Comment 11 Orion 2015-01-12 00:02:25 UTC
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).
Comment 12 V Stuart Foote 2015-01-12 00:15:38 UTC
(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...
Comment 13 V Stuart Foote 2015-01-12 00:22:14 UTC
(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)
Comment 14 Joel Madero 2015-01-12 00:43:44 UTC
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.
Comment 15 Joel Madero 2015-01-12 00:44:47 UTC
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.
Comment 16 tmacalp 2015-01-12 02:28:09 UTC
(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.
Comment 17 tmacalp 2015-01-18 19:28:05 UTC
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/
Comment 18 Commit Notification 2015-01-19 09:03:56 UTC
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.
Comment 19 Yousuf Philips (jay) (retired) 2015-01-19 20:35:17 UTC
It has also been merged into 4.4.0 and 4.4 daily.

https://gerrit.libreoffice.org/14022/
https://gerrit.libreoffice.org/14024/
Comment 20 V Stuart Foote 2015-01-19 20:53:20 UTC
(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...
Comment 21 tmacalp 2015-01-19 21:06:47 UTC
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?
Comment 22 Yousuf Philips (jay) (retired) 2015-01-20 12:15:03 UTC
Sorry about that. :D

Here is the patch for going into 4.4.0.

https://gerrit.libreoffice.org/#/c/14037/
Comment 23 Commit Notification 2015-01-20 13:50:40 UTC
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.