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