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 [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
