undocking/detaching toolviews to regular windows instead of tool windows

[Kevin Funk]

On Thursday, 12 October 2017 16:19:33 CEST René J.V. Bertin wrote:
> On Thursday October 12 2017 15:43:16 Kevin Funk wrote:
> >Makes sense. Patches welcome.
> >
> >Should be easy enough, you need to reparent the widget contained in the
> >QDockWidget, set the Qt::Window flag and show it again. Work from there.
> 
> Hmm, I can try this too. For now I've tinkered with changing the window
> flags back to Qt::Window when the floating state changes. That also works
> but it's tricky (because apparently platform-dependent). But reparenting
> could have more side-effects, have you tried re-docking the window for
> instance?

No, as I expected you to try this out if you'd like to have the feature.

> This is something that can probably much better be done upstream: a
> QDockWidget::setFloatAsRegularWindow(bool) could modify how
> QDockWidget::setFloating(true) "tears off" windows.
> 
> Normally I'm all for giving the user choice, but wouldn't it be sufficient
> (better) in this case to let the toolview decide rather than adding a menu
> to obtain a different kind of floating window? That would give 2 menu
> actions to detach the window, which comes with having to handle transitions
> between those modes and will probably also lead to surprises when the
> floating windows are restored as Qt::Tool instead of Qt::Window.

Agreed. Could be an option in the application's setting.

> FWIW, automatic restore is tricky to get right with my approach too. There
> is no state change notification of course, and apparently
> QDockWidget::isFloating() cannot yet be queried reliably in the ctor. I've
> been trying to work around this by re-attaching the windows on exit using
> QCoreApplication::aboutToQuit, but that only works on Mac. On Linux I
> simply don't get the signal.

State change about what? Which signal do you not get? aboutToQuit()? Did 
KDevelop crash?

Please don't start adding work-arounds (we won't accept them upstream) before 
having understood the actual problem.

> Another thing that makes restore tricky is the
> fact that the (documentation) toolview is restored multiple times; when
> it's being restored in detached mode I can see the window open and close
> multiple time while the session loads (possibly once per project).

Then please fix/investigate this first(?)

> >FWIW, René also cross-posted basically the same question to:
> >  http://lists.qt-project.org/pipermail/interest/2017-October/028275.html
> 
> That was a general how-to.

https://stackoverflow.com/questions/46699115/qdockwidgets-how-to-get-regular-windows-in-detached-floating-mode

^ That, too? Same question, 1:1 copy from mail on the Qt interest list, fired 
off almost at the same time.

Please have a read: 
  https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Cross_posting


I'd recommend you to spend more time digging through code, studying it, trying 
things out, polishing things, adding unit tests, *then* come up with a review 
request and trigger discussions --  instead of bombarding everyone with mails 
asking how to implement this and that. (It's not just us (KDevelop), and I 
just see the fraction of your mails on mailing lists I'm tracking... (Qt, 
KDE))

I'm sorry this may come off a bit harsh, but it's not like there's no 
precedent here.

PS: And I just received another mail of you, 40 minutes after the last one, 
posting yet another incomplete patch. That doesn't help anyone. 


Regards,
Kevin


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20171012/b03af3e9/attachment.sig>