Bug 128581 (Panel-Docking) - [Meta] Panel docking
Summary: [Meta] Panel docking
Status: NEW
Alias: Panel-Docking
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 64438 92122 113416 114983 134704 148830 152088 154983 155115 155116 157660 42695 104299 113330 128543 151504
Blocks: UI
  Show dependency treegraph
 
Reported: 2019-11-04 09:07 UTC by Heiko Tietze
Modified: 2023-10-22 21:01 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 Heiko Tietze 2019-11-04 09:07:27 UTC
(In reply to V Stuart Foote from comment #8)
> Issue is valid, bug 92122 (Windows) -- bug 64438 (Linux, KDE for sure) --
> and recently bug 128543 (macOS)
> 
> Maxim had some ideas on refactoring the docking frames for Windows
> specifically but maybe in general which may resolve the issue on KDE. Not
> clear what --if anything-- is happening with compositing the frames for qt5
> and gtk3
> 
> =-ref-=
> 
> [1] https://bugs.documentfoundation.org/show_bug.cgi?id=92122#c14

I got bug 104299 as "I cannot dock the (left-side) Navigator once it's undocked". And Jim kindly provided code pointers

(In reply to Jim Raykowski from comment #5)
> (In reply to Heiko Tietze from comment #2)
> > (you can always press shift+ctrl+F10
> > to dock/undock the focused sidebar or Navigator, which is relevant on
> > Linux). It would be a good idea to show the shortcut in the context menu
> > with the undock/dock entry.
> > 
> > Setting as easyHack (just add the text to the context menu) and needsDevEval
> > for the code pointers.
> 
> Code pointers:
> /sfx2/source/sidebar/SidebarController.cxx:CreatePopupMenu
> SetAccelKey for docking and un-docking menu items

What are the requirements in addition to the docking of the Navigator? Is it bug 85905 "Allow undocking of Sidebar decks"?
Comment 1 V Stuart Foote 2019-11-04 14:01:46 UTC
Applies to _dockable panels_ as opposed to simply floating frames/dialogs (i.e. all application frames with LibreOffice as a parent). Issue is the ability to redock the panel--either by drag-n-drop, or by UNO button action.  

A dock/undock toggle button is present on the Sidebar's button bar, but is not provided with other undockable panels (e.g. the F5 Navigator all modules, the Elements panel in Math, the Page/Slide Pane in Draw/Impress).

The panels can be torn away to undock, but absent a dock button action, they need a GUI action to redock. Also GUI drag-n-drop action is the only way now to change docking location (currently limited to left or right)

Seems that for GUI drag-n-drop the for docking os/DE has to recognize the window movement of the detached panel, and  provide for interaction with the parent application to then be able to dock. And that this varies by os/DE.

Situation is that GUI movement works, or not, depending on os/DE and its settings. 

https://bugs.documentfoundation.org/show_bug.cgi?id=64438#c12

https://bugs.documentfoundation.org/show_bug.cgi?id=92122#c14

So, agree a button action is needed for each undockable panel we want to redock--but where does the control get placed? We probably don't want to do CSD (bug 113388), so the main menu--Window or View entry? Or the 'Hamburger'/'elipsis' in the Notebookbar?

Otherwise, the GUI ability to drag and redock requires dev input as to why it works or does not depending on the os/DE and compositor in use--and is there expectation that UI should be the same cross platform?
Comment 2 Heiko Tietze 2019-11-04 19:09:06 UTC
(In reply to V Stuart Foote from comment #1)
> So, agree a button action is needed for each undockable panel we want to
> redock--but where does the control get placed?

Docking should be possible at any dock, that will remain an issue. Meanwhile (and additionally) we add the UI interaction and my proposal was to do this similar to the sidebar at the context menu. And IIRC there was also a shortcut, ctrl+shift+F10?
Comment 3 V Stuart Foote 2019-11-04 22:21:46 UTC
(In reply to Heiko Tietze from comment #2)
> And IIRC there was also a shortcut, ctrl+shift+F10?

Hmm, yes you're right--the <ctrl>+<shift>+F10 [1], or <Ctrl>+ double-mouse-click [2], will dock/undock any of these panels as floating windows.

But those particular VCL shortcuts are 'hard' to find (they do not appear in Customize dialog).

And while they will toggle to dock/undock state, ones ability to drag the panels to alternate docking site is not so clear--it works sometimes but not others.

And for Wayland in general, Caolán had to disable the undocked state [3]--setting a bDockingSupportCrippled value.


=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/vcl/source/window/event.cxx?r=55402d82#149

{2] https://opengrok.libreoffice.org/xref/core/vcl/source/window/event.cxx?r=55402d82#101

[3] https://gerrit.libreoffice.org/#/c/30752/
Comment 4 Maxim Monastirsky 2019-11-05 00:24:42 UTC
(In reply to V Stuart Foote from comment #1)
> Seems that for GUI drag-n-drop the for docking os/DE has to recognize the
> window movement of the detached panel, and  provide for interaction with the
> parent application to then be able to dock. And that this varies by os/DE.
> 
> Situation is that GUI movement works, or not, depending on os/DE and its
> settings. 
This was discussed in the past, and the conclusion was that using our own window decorations is a way to solve this cross-platform. See https://lists.freedesktop.org/archives/libreoffice/2017-December/079108.html and https://gerrit.libreoffice.org/53551/.

Another idea was to use drag & drop of tabs like in GIMP, instead of dragging the whole window.

> So, agree a button action is needed for each undockable panel we want to
> redock--but where does the control get placed? We probably don't want to do
> CSD (bug 113388)
We might not use CSD for the main window, yet have own decorations for dockable windows, like we already do for floating toolbars, and place the button there.

(In reply to V Stuart Foote from comment #3)
> And for Wayland in general, Caolán had to disable the undocked state
> [3]--setting a bDockingSupportCrippled value.
Docking of floating windows by dragging is possible under Wayland in principle, if only they're created as subsurfaces (can be easily tested with toolbars, by using GTK_WINDOW_POPUP window type for the SalFrameStyleFlags::OWNERDRAWDECORATION case inside GtkSalFrame::Init, and removing the mbCanDetermineWindowPosition = false assignment from GtkSalData::initNWF). But this brings its own set of problems. One problem is that such windows don't get the focus, so it isn't possible to type anything there, or navigate them with the keyboard (maybe this can be solved with explicit grabs, I don't know).
Comment 5 Heiko Tietze 2019-11-06 11:29:05 UTC
(In reply to Maxim Monastirsky from comment #4)
> We might not use CSD for the main window, yet have own decorations for
> dockable windows, like we already do for floating toolbars, and place the
> button there.

Actually I wouldn't expect the ordinary window menu to change. On KDE I get "Move to desktop, Maximize, Minimize...". But with toolbar style decoration like when the color picker is detached it's clear where this widget belongs to. You cannot double-click the title bar to maximize the window, not minimize, neither move to another virtual desktop - all rather benefits than drawbacks.