Bug Hunting Session
Bug 83546 - SIDEBAR: content panels in tray don't open with accelerators when sidebar is enabled but fully hidden
Summary: SIDEBAR: content panels in tray don't open with accelerators when sidebar is ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:5.1.0 target:5.0.2
Keywords:
: 85076 89562 91435 92823 93721 93729 93763 94877 95142 96148 97047 (view as bug list)
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2014-09-05 19:44 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-10-24 14:41 UTC (History)
19 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 Yousuf Philips (jay) (retired) 2014-09-05 19:44:07 UTC
Steps:
1) Open Writer
2) With sidebar open, click the arrows at the edge of the sidebar, next to the scrollbar, to hide the sidebar
3) Goto Tools > Gallery
4) Sidebar wont expand to show the gallery
Comment 1 V Stuart Foote 2014-09-06 02:49:04 UTC
@Jay, *,

By design.

As is now, for bug 73151, we've set the Tools --> Gallery to only open in the Sidebar ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=b4558b508141af16d335f45a0f12bdd34521e944 ) And when the Sidebar deck is closed--the gallery is closed.

But, this would be reasonable UI/UX to open the closed Sidebar Deck and switch to the Gallery Content Panel when the Tools --> Gallery menu item is selected.

Setting new enhancement.
Comment 2 Yousuf Philips (jay) (retired) 2014-09-06 10:57:09 UTC
One possible workaround would be to disable the sidebar (View->Sidebar) and then enable it again, as this would expand the sidebar from its hidden position, and then switch to the gallery. Only potential problem i see is that the sidebar would likely flicker from these changes.
Comment 3 Samuel Mehrbrodt (CIB) 2014-10-16 13:12:02 UTC
*** Bug 85076 has been marked as a duplicate of this bug. ***
Comment 4 tommy27 2014-10-16 13:15:54 UTC
same issues with F11 "Styles and Formatting" which doesn't working when sidebar hidden like in duplicate Bug 85076

let's consider rewording the summary notes
Comment 5 tommy27 2014-10-16 13:34:03 UTC
... and add it to mab4.4 since these menus disfunctions related to the sidebar status may look confusing and annoying for users
Comment 6 Samuel Mehrbrodt (CIB) 2014-10-17 09:08:09 UTC
Making an EasyHack out of this.
We need to make sure that the DockingArea that contains the DockingWindow is expanded when the DockingWindow (Sidebar in this case) is shown.

You need to play with this method to figure that out: http://opengrok.libreoffice.org/xref/core/sfx2/source/appl/workwin.cxx#2256
Comment 7 Björn Michaelsen 2014-12-02 10:53:05 UTC
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 8 Renato Ferreira 2015-01-01 22:38:32 UTC
Hi,

I've been trying to work on this bug, but I'm having a hard time figuring out what to do in the method pointed out by Samuel.

Does SfwWorkWindow represent the sidebar as a whole, and then the nId parameter received by SfxWorkWindow::ShowChildWindow_Impl refers to the child gallery? Or did I get this wrong? I concluded this since the member pParent is NULL when the method is called to show the gallery, but I don't know if this reasoning is correct.

I tried calling methods such as MakeVisible_Impl and GetWindow()->Show(true, 0), but those didn't help. I tried to track the sidebar visibility change using the debugger and found calls to SfxSplitWindow::FadeIn, but I can't find the connection between that and the method I'm working on.

Could somebody point me in the right direction here, maybe by explaining what the classes stand for? I explored SfxWorkWindow, SfxDockingWindow, SfxChildWindow and vcl::Window, but I'm still clueless as to what controls the visibility of the sidebar itself.

Thanks in advance,
Renato.
Comment 9 Yousuf Philips (jay) (retired) 2015-02-23 10:11:30 UTC
*** Bug 89562 has been marked as a duplicate of this bug. ***
Comment 10 V Stuart Foote 2015-08-14 16:29:08 UTC
*** Bug 91435 has been marked as a duplicate of this bug. ***
Comment 11 V Stuart Foote 2015-08-17 04:54:10 UTC
*** Bug 92823 has been marked as a duplicate of this bug. ***
Comment 12 Maxim Monastirsky 2015-08-27 21:31:12 UTC
*** Bug 93721 has been marked as a duplicate of this bug. ***
Comment 13 Samuel Mehrbrodt (CIB) 2015-08-28 05:41:57 UTC
It seems to be not that easy to fix this one, I also tried it but couldn't get it working.

I wonder whether we really need this arrows to hide the docking areas. The same functionality is available if you use the "View->Sidebar" menu.

Could we just remove this feature to hide the docking areas with the "arrow" button? That would be an easy fix for this bug.
Comment 14 Samuel Mehrbrodt (CIB) 2015-08-28 08:27:28 UTC
*** Bug 93729 has been marked as a duplicate of this bug. ***
Comment 15 V Stuart Foote 2015-08-28 12:53:20 UTC
(In reply to Samuel Mehrbrodt from comment #13)
> It seems to be not that easy to fix this one, I also tried it but couldn't
> get it working.
> 
> I wonder whether we really need this arrows to hide the docking areas. The
> same functionality is available if you use the "View->Sidebar" menu.
> 
> Could we just remove this feature to hide the docking areas with the "arrow"
> button? That would be an easy fix for this bug.

I hope not. Having the ability to hide the full Deck & Tab bar, or when just the Tab bar is showing, with the Hide/Show widget grips is a really nice function of the Sidebar GUI. 

Function is not the same manipulating from the View menu.

Currently, when collapsed or hidden the Sidebar remains loaded with the content panel selected, and is simply unhidden by the grip action. 

Also while hidden it responds to changes in content panel, meaning you can reopen it showing a content panel not active when it was hidden. 

And when manipulated from the View -> Sidebar it currently is being closed. And is reloaded and set back to its default, i.e. opens the Properties panel.

So yes some of the function can be duplicated, but it is not as clean as with the Hide/Show grip widgets.
Comment 16 Maxim Monastirsky 2015-08-29 20:27:48 UTC
*** Bug 93763 has been marked as a duplicate of this bug. ***
Comment 17 Commit Notification 2015-08-30 20:09:27 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e38c4105077b396b0b53e0296ae9cf142f51dd52

tdf#83546 Expand the sidebar if it's hidden

It will be available in 5.1.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 18 V Stuart Foote 2015-09-01 13:11:49 UTC
@Maxim,

That works great now, opens with accelerators (where defined), but retains the progressive Deck & Tabbar, Tabbar, or hidden states.  Kind of a weird interplay of accelerator, tabbar button click, Hide/Show widget--but it seems consistent now.

Thanks!
Comment 19 Commit Notification 2015-09-02 11:19:41 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6390640fcce39eaf7612bcbd8f61e2570c3e50e7&h=libreoffice-5-0

tdf#83546 Expand the sidebar if it's hidden

It will be available in 5.0.2.

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 20 Maxim Monastirsky 2015-10-08 11:41:29 UTC
*** Bug 94877 has been marked as a duplicate of this bug. ***
Comment 21 Maxim Monastirsky 2015-10-17 21:25:45 UTC
*** Bug 95142 has been marked as a duplicate of this bug. ***
Comment 22 Maxim Monastirsky 2015-11-30 08:13:04 UTC
*** Bug 96148 has been marked as a duplicate of this bug. ***
Comment 23 Maxim Monastirsky 2016-01-11 17:23:29 UTC
*** Bug 97047 has been marked as a duplicate of this bug. ***