https://bugs.documentfoundation.org/show_bug.cgi?id=128581

Maxim Monastirsky <momonas...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=11
                   |                            |4983
         Depends on|                            |113416

--- Comment #4 from Maxim Monastirsky <momonas...@gmail.com> ---
(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).


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=113416
[Bug 113416] Include a button to dock the F5 Navigator opposite the sidebar
deck
-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to