Re: floating windows docking issue

classic Classic list List threaded Threaded
4 messages Options
Samuel Mehrbrodt-3 Samuel Mehrbrodt-3
Reply | Threaded
Open this post in threaded view
|

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

[hidden email]
www.cib.de
–––
Sitz: München
Registergericht München, HRB 123286
Geschäftsführer: Dipl.-Ing. Ulrich Brandner

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view
|

Re: floating windows docking issue

Am 14.12.2017 um 10:00 schrieb Samuel Mehrbrodt:
> 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.

Interesting approach to handle non-modal dialog grouping in a unified
way. Would we want to do something like this, so we don't have duplicate
dialog + panel (like the navigator), or is this considered a feature,
that you can have multiple instances?

OTOH gimp doesn't have toolbars at all and all grouping windows provide
a combobox to switch between the images they refer to (normally switched
automatically by following the focus). And you can't dock anything to
the image window. The UI handling / experience is totally different.

And there is no way to have multiple instances of a dialog referring to
different images. At least if you select a dialog from the "dockable
dialogs" sub-menu in the "window" menu, it just switches to the existing
instance, highlighting it for a second, so the user can find it easier.

> QDockWidget was also named as an example how to do things, I have yet to
> look how that behaves, especially under Wayland.

There is a dockwidget example (on Ubuntu compiled in package
qtbase5-examples).

And then there is https://bugreports.qt.io/browse/QTBUG-64595
"Drag QDockWidgets between multiple QMainWindows".

>> 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...

I'm not sure there is much C'n'P here, as the approach is different.

> There is also UNO API to create and move around docking windows, we
> obviously don't want to lose that.

Didn't know that.

So if we already touch and unify this code, should we re-think use cases
and "usability pattern" (don't have a better name for it)? But probably
that should be a 2nd approach, after fixing the general docking window bug.

Jan-Marek
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Maxim Monastirsky Maxim Monastirsky
Reply | Threaded
Open this post in threaded view
|

Re: floating windows docking issue

In reply to this post by Samuel Mehrbrodt-3
On Thu, 2017-12-14 at 09:00 +0000, Samuel Mehrbrodt wrote:
> 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.
True. Drag & drop of tabs is a possible solution for docking panels,
but I don't know how well it will fit with the toolbars use-case.
Imagine a single-line floating toolbar with a system title bar + tab
bar to be able to dock it. It won't look good. (See tdf#113353 and
tdf#78188 for a similar problem that we had for years with gtk2 under
some WMs.)

> 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.
Do you mean XDockableWindow? As I doubt it has any use for 3rd-party
code in its current state.

Maxim
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Maxim Monastirsky Maxim Monastirsky
Reply | Threaded
Open this post in threaded view
|

Re: floating windows docking issue

In reply to this post by Jan-Marek Glogowski
Hi Jan-Marek,

> Interesting approach to handle non-modal dialog grouping in a unified
> way. Would we want to do something like this, so we don't have
> duplicate
> dialog + panel (like the navigator), or is this considered a feature,
> that you can have multiple instances?
I don't think it's a feature. Ideally we would like to be able to
undock individual sidebar decks, see tdf#85905.

> I'm not sure there is much C'n'P here, as the approach is different.
Not sure what you mean by "the approach is different", but even with
different approaches wouldn't it make sense to keep just one approach,
instead of maintaining two?

Anyway, DockingManager clearly started as a copy-paste from
DockingWindow. You can compare the ImplDockFloatWin and
ImplDockFloatWin2 classes, or methods like
DockingWindow::SetFloatingMode vs
ImplDockingWindowWrapper::SetFloatingMode. And a comment above the
ImplDockingWindowWrapper declaration clearly says that
"ImplDockingWindowWrapper obsoletes the DockingWindow class. It is
better because it can make a "normal window" dockable. All
DockingWindows should be converted the new class."

Maxim
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice