Re: floating windows docking issue

Hi Maxim,

thanks a lot for your detailed response. I'm adding the dev list to get some more feedback.

Am 14.12.2017 um 01:04 schrieb Maxim Monastirsky:

Hi Samuel,

On Wed, 2017-12-13 at 14:03 +0000, Samuel Mehrbrodt wrote:


I discussed this on IRC and wanted to do the same as you suggested
(make floating windows use our own decoration, as our toolbars).

Are you already working on that? If not I would take this. This is
just to prevent duplicate work.


It's on my todo list, but I didn't start any actual work. So feel free
to take this bug now (but please keep me informed if you change your
mind).

I would like to mention here 2 things, that you should be aware of:

1. Situation around Wayland. Under Wayland there is no such thing as
global screen coordinates, so it isn't possible to move a window from
the code. That means that as soon as you convert docking windows to use
our own decorations, they will become unmovable under Wayland. For some
time Caolán had a solution for this, but he reverted this attempt, as
the lack of global screen coordinates also means that it's not possible
to detect whether a docking window is above the docking area of the
main window (which otherwise done by getting the global position of the
main window and of the docking window, and comparing them). So he ended
up with disabling the whole docking story under Wayland, so windows
that docked by default (like toolbars or the slide pane), can not be
undocked, because it won't be possible to dock them back.

Gimp solves this problem by having the docking windows in native windows, but then that native 
window can't be docked. Instead that window contains tabs which then can be dragged and dropped in 
the docking areas.
QDockWidget was also named as an example how to do things, I have yet to look how that behaves, 
especially under Wayland.


(A possible solution might be to use Wayland sub-surfaces, instead of
having docking windows as top level windows (follow the
SalFrameStyleFlags::OWNERDRAWDECORATION case in gtk3's
GtkSalFrame::Init). It still won't give us global coordinates, but it
should give us coordinates relative to the parent window, and also the
possibility to move them from the code (at least it worked for me in a
simple hello world level code that I tried two months ago). Fortunately
recent enough versions of gtk3, will create the window as a sub-surface
for you, if you only declare the window as a popup window.)

Hm so this means converting the docking windows to toolbar-style windows will break docking windows 
under Wayland?
I have to look into this sub-surface thing then.


Obviously, you don't have to fix Wayland problems while working on
KDE/Windows bugs, but at least you should make sure to not introduce
regressions, i.e. those docking windows that are undocked by default
should be at least movable. A minimal solution to this could be to keep
using system title bars when under Wayland.

2. We have 2 instances of (mostly) the same docking code in our
codebase:

- The "old" one in the DockingWindow class. This is used as the base of
the sfx2 docking code, and currently use system title bars.

- The "new" one in DockingManager. This is used for toolbars and
various toolbar popup controls, that use our own decorations.

I don't know how hard it would be, be it could be nice to kill this
copy-paste at some point...

Anyway, I wish you good luck in fixing the bug, and I'll be happy to
help whenever I can.

Best regards,
Maxim




Thanks for the hint with the two docking implementations. I have to read the code to see what is 
achievable.
There is also UNO API to create and move around docking windows, we obviously don't want to lose 
that.

Best regards
Samuel
--
Samuel Mehrbrodt
Softwareentwickler LibreOffice
–––
CIB software GmbH
Geschäftsstelle Hamburg
Flachsland 10
22083 Hamburg
–––
T +49 (40) / 28 48 42 -224
F +49 (40) / 28 48 42 -100

Samuel.Mehrbrodt@cib.de<mailto:Samuel.Mehrbrodt@cib.de>
www.cib.de<http://www.cib.de>
–––
Sitz: München
Registergericht München, HRB 123286
Geschäftsführer: Dipl.-Ing. Ulrich Brandner