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
@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.
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.
*** Bug 85076 has been marked as a duplicate of this bug. ***
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
... and add it to mab4.4 since these menus disfunctions related to the sidebar status may look confusing and annoying for users
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
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
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.
*** Bug 89562 has been marked as a duplicate of this bug. ***
*** Bug 91435 has been marked as a duplicate of this bug. ***
*** Bug 92823 has been marked as a duplicate of this bug. ***
*** Bug 93721 has been marked as a duplicate of this bug. ***
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.
*** Bug 93729 has been marked as a duplicate of this bug. ***
(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.
*** Bug 93763 has been marked as a duplicate of this bug. ***
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.
@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!
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.
*** Bug 94877 has been marked as a duplicate of this bug. ***
*** Bug 95142 has been marked as a duplicate of this bug. ***
*** Bug 96148 has been marked as a duplicate of this bug. ***
*** Bug 97047 has been marked as a duplicate of this bug. ***