Description: As the sidebar occupies a lot of space, I usually have the decks closed (and usually the sidebar is even folded in). For me, the sidebar always resided on the right side of the screen next to the scrollbar. Recently, I have had the issue of mis-clicking the scrollbar and instead unfolding the sidebar (with no decks) several times. I have searched and it seemed like it is easy to move the sidebar from the vicinity of the scrollbar by dragging. To my surprise though, it is only possible to do if you drag the title of the deck (e.g., properties/page/styles etc.). As there is plenty of empty space on the sidebar it would be nice to have the option to drag it by just dragging from any empty part. I think this is a general UI problem as I have seen the same behaviour for Impress, Draw as well as for Writer. Steps to Reproduce: 1. Click the view menu, select the sidebar to be active. 2. Make sure the sidebar is docked. 3. Close all decks so only the deck icons remain. 4. If necessary customise the sidebar so there is enough space below the icons to grab the sidebar. 5. Try to grab the sidebar from any non-active parts (e.g., icons, top menu etc.) and drag it to the other side of the screen. Actual Results: The sidebar does not move. Expected Results: The sidebar should move to the other side. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.4.1 Build ID: 1:6.0.4~rc1-4 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
No, IMHO behavior is correct as implemented. The "Sidebar Settings" gear icon split button widget includes an Undock entry. Or, as noted, for an expanded Deck just the Deck Title object can receive a click-drag action to undock the SideBar. The GUI drag undock/dock (it goes both ways) is performed against the frame holding the entire Sidebar--so having just the Deck Title a target for the grab is enough given that we also provide the split button menu for the undock action. Linking the dock/undock action to each Content Panel held in a Deck would be a nuisance to implement, and to maintain, for each content panel. Keep the GUI implementation simple and continue to _only_ target the Deck Title for mouse drag. => WONTFIX
Agree with Stuart. Sidenote: you can hide the sidebar completely with View > [ ] Sidebar, assigned to ctrl+F5 by default in 6.1.
Created attachment 141997 [details] Drag possible with other toolbars by using the control of the circled area
Created attachment 141998 [details] Drag control is not available on the sidebar when there is no open deck
Please wait until one replies before closing the bug as won't fix. Neither of you follow the steps to reproduce the bug, so how can you actually decide before further input? For the first comment: you write as if the deck is open, but I wrote explicitly in my steps to reproduce part that you have to close all decks. For the second comment: I wrote explicitly that you want the sidebar to be not-hidden (referring to the exact menu item that you have said). Ok, I understand that it is not necessarily a good idea to allow the drag from a random place. So I attached a screenshot with two toolbars. One is a regular one and the other is the sidebar. On the regular toolbar there is a drag area: one can hover over the dotted line in the front and drag the toolbar wherever one pleases. On the sidebar (when there is no deck open) there is no control like the one on the regular toolbar in the attachment. So one cannot drag the sidebar unless a deck is opened to make sure the drag controls are available. I am advocating to allow the drag even if there is no deck open.
(In reply to dbtale from comment #5) Thanks, we're quite capable of reviewing UI proposals and response considered the Sidebar in docked, undocked, expanded and collapsed state(s). IMHO drag to undock from the Tab bar is not needed as an undock control is present from the settings split button. A grip was just added to the Deck title [1] to match other Tools bar objects, but the title bar still takes grab focus. Test a current daily of 6.1.0alpah1+ master. See no reason to add the grip onto the Tab bar in a collapsed state and it is not needed when the deck is expanded (present in the Deck title). IMHO it remains => WONTFIX @bubli -- any thoughts on need to also add a drag grip to the Tab bar? Or, maybe just when Deck is collapsed? =-ref-= [1] https://gerrit.libreoffice.org/#/c/53496/
(In reply to V Stuart Foote from comment #6) > =-ref-= > [1] https://gerrit.libreoffice.org/#/c/53496/ also these in setting up the grips... https://gerrit.libreoffice.org/53323 https://gerrit.libreoffice.org/53379
> @bubli -- any thoughts on need to also add a drag grip to the Tab bar? Or, > maybe just when Deck is collapsed? ... and then what would users expect to happen? A collapsed sidebar ( = only the column of deck icons) would become undocked/floating? That would look ... hm, odd. Or should this operation also expand the sidebar? /me ignorant developer, excuse my silly questions
(In reply to Katarina Behrens (CIB) from comment #8) > ... and then what would users expect to happen? A collapsed sidebar ( = only > the column of deck icons) would become undocked/floating? That would look > ... hm, odd. Or should this operation also expand the sidebar? I would expect it to expand as recorded to profile--just as the current Undock / Dock from the split button control [1]. But, would need to show or hide it depending on if the Deck is collapsed or not--seems like a lot of hoops for something that is already provided from the split settings button. > > /me ignorant developer, excuse my silly questions ;-) =-ref-= https://opengrok.libreoffice.org/xref/core/sfx2/source/sidebar/SidebarController.cxx#1004
(In reply to V Stuart Foote from comment #9) > (In reply to Katarina Behrens (CIB) from comment #8) > > ... and then what would users expect to happen? A collapsed sidebar ( = only > > the column of deck icons) would become undocked/floating? That would look > > ... hm, odd. Or should this operation also expand the sidebar? > > I would expect it to expand as recorded to profile--just as the current > Undock / Dock from the split button control [1]. > > But, would need to show or hide it depending on if the Deck is collapsed or > not--seems like a lot of hoops for something that is already provided from > the split settings button. Just to be clear, because I might have misunderstood something. If we are talking about the Sidebar's settings button which allows the sidebar to be completely undocked, then this is not what I intended to talk about. That button allows the complete sidebar to be moved into a separate window. What I was trying to explain is when you have the sidebar docked on one side of the main window and you want to move the docked position to the other side of the window.
(In reply to dbtale from comment #10) > (In reply to V Stuart Foote from comment #9) > > (In reply to Katarina Behrens (CIB) from comment #8) > > > ... and then what would users expect to happen? A collapsed sidebar ( = only > > > the column of deck icons) would become undocked/floating? That would look > > > ... hm, odd. Or should this operation also expand the sidebar? > > > > I would expect it to expand as recorded to profile--just as the current > > Undock / Dock from the split button control [1]. > > > > But, would need to show or hide it depending on if the Deck is collapsed or > > not--seems like a lot of hoops for something that is already provided from > > the split settings button. > > Just to be clear, because I might have misunderstood something. If we are > talking about the Sidebar's settings button which allows the sidebar to be > completely undocked, then this is not what I intended to talk about. That > button allows the complete sidebar to be moved into a separate window. What > I was trying to explain is when you have the sidebar docked on one side of > the main window and you want to move the docked position to the other side > of the window. It is not into a "separate window". Dragging Deck title bar to "move", now aided with addition of graphical grip, first performs an Undock (actually makes the frame floating)--normal frame controls then handled the Sidebar's movement. There are "drop" docking targets on Right edge (default) and Left edge of the application window--when on target there is a visual queue (outline of the frames placement) frame will snap to its docked position. Release of mouse will drop there, or if off target and anywhere on system DE space the frame will "float". In other words to move the Sidebar it must be undocked -> moved -> docked. The docking target--Left side or Right side--is stateful recorded to user profile.
(In reply to dbtale from comment #10) > ...What > I was trying to explain is when you have the sidebar docked on one side of > the main window and you want to move the docked position to the other side > of the window. Would be nice but there is no clear requirement. We have many tickets on more flexible UIs but unfortunately the current implementation lacks on flexibility.
Putting to NEW until the UX team decides how to handle this
(In reply to Xisco Faulí from comment #13) > Putting to NEW until the UX team decides how to handle this Verdict from design team members and devs: (In reply to V Stuart Foote from comment #1) > => WONTFIX (In reply to Heiko Tietze from comment #2) > Agree with Stuart. (In reply to Katarina Behrens (CIB) from comment #8) > ... and then what would users expect to happen?
Ok, thanks for the info! Closing as RESOLVED WONTFIX!