<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Segoe UI">Hi Maxim,</font></p>
<p><font face="Segoe UI"><font face="Segoe UI">thanks<font face="Segoe UI"> a lot for your detailed
<font face="Segoe UI">respo<font face="Segoe UI">nse. I<font face="Segoe UI">'m <font face="Segoe UI">
adding the dev list<font face="Segoe UI"></font> <font face="Segoe UI"></font>to get some more feedback.</font></font></font></font></font></font></font><br>
</p>
<br>
<div class="moz-cite-prefix">Am 14.12.2017 um 01:04 schrieb Maxim Monastirsky:<br>
</div>
<blockquote type="cite" cite="mid:1513209851.7947.63.camel@gmail.com">
<pre wrap="">Hi Samuel,

On Wed, 2017-12-13 at 14:03 +0000, Samuel Mehrbrodt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.</pre>
</blockquote>
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.<br>
QDockWidget was also named as an example how to do things, I have yet to look how that behaves, especially under Wayland.<br>
<blockquote type="cite" cite="mid:1513209851.7947.63.camel@gmail.com">
<pre wrap="">
(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.)</pre>
</blockquote>
Hm so this means converting the docking windows to toolbar-style windows will break docking windows under Wayland?<br>
I have to look into this sub-surface thing then.
<blockquote type="cite" cite="mid:1513209851.7947.63.camel@gmail.com">
<pre wrap="">
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


</pre>
</blockquote>
Thanks for the hint with the two docking implementations. I have to read the code to see what is achievable.<br>
There is also UNO API to create and move around docking windows, we obviously don't want to lose that.<br>
<br>
Best regards<br>
Samuel<br>
<div class="moz-signature">-- <br>
<small>Samuel Mehrbrodt<br>
Softwareentwickler LibreOffice<br>
–––<br>
CIB software GmbH<br>
Geschäftsstelle Hamburg<br>
Flachsland 10<br>
22083 Hamburg<br>
–––<br>
T +49 (40) / 28 48 42 -224<br>
F +49 (40) / 28 48 42 -100<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Samuel.Mehrbrodt@cib.de">Samuel.Mehrbrodt@cib.de</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.cib.de">www.cib.de</a><br>
–––<br>
Sitz: München<br>
Registergericht München, HRB 123286<br>
Geschäftsführer: Dipl.-Ing. Ulrich Brandner</small></div>
</body>
</html>