[IDE] Fix detached docklet visibility bug

[gusano]

Fix #3287

This fixes what seems to be a weird race condition: when starting the IDE, a detached (and closed) docklet container can be raised just after it has been hidden, leading into a ghost unresponsive window (see linked issue).

I'm not sure this is the most elegant fix so I'm open to any hint if this needs to be done differently.

cc @jamshark70

[gusano]

This is not directly related but it was missing.. Let me know if I should revert that one.

[mossheim]

if you included it for qDebug(), it's not really necessary as qDebug is a global feature: http://doc.qt.io/qt-5/qtglobal.html#qDebug

[mossheim]

thanks for this! i can confirm the behavior is OK on macOS. i never was able to reproduce this bug though, so take it with a grain of salt.

[mossheim]

consider renaming this function; a call to "setDetached( bool, bool )" is opaque. suggestion - setDetachedWithVisibility. i don't think a default value for the second argument is a good idea, it will make calling code harder to understand.

[jamshark70]

I've just launched the IDE five times in a row, without a single ghost help browser appearing.

I'm crying.

Thank you @gusano !!!

I don't have much to say about code review. Sometime later I might suggest including some of the changes I was testing, specifically to defer MainWindow initialization by a QTimer. The bulk of it is here -- jamshark70@1cd6643 -- but I would have to check if I added something functionally different in another branch.

The reason is: I also notice that the main IDE window "drifts" to the left when launching. I usually have the IDE window flush left on the screen, but often when I launch the IDE, the window's left margin is slightly offscreen. I found, when I was testing the suggestion from the Qt forum, that the window position was more accurate.

Using this PR as is, I still get the window-position problem.

I cherry picked the above commit and tested, but then it always shows the help browser. I think it's because of help_browser.hpp:

    void onInterpreterStart() {
        if (isVisible() && mHelpBrowser->url().isEmpty())
            mHelpBrowser->goHome();
    }

... where isVisible() is true, even if the window is supposed to be hidden.

But, come to think of it, window drift is another issue to log later.

I'd like to see this fix in 3.9 (currently based on develop).

[jamshark70]

FWIW ecd59e1 cherry-picks cleanly onto 3.9, tested locally and it's good.

[mossheim]

@jamshark70 - we aren't planning to do any more 3.9 releases (this has been mentioned a few times on the ML). if 3.10 takes longer than expected maybe we can do another patch release and backport some of the fixes

[gusano]

@brianlheim thanks! Force pushed with your suggestions.
@jamshark70 actually the first reason that made me have a look at this issue was that using QTimer sounded wrong to me :) Let's fix one bug at a time 👹

[jamshark70]

I agree this PR should fix just the one bug.

If QTimer is wrong, then I'm not clear why the IDE window is positioned incorrectly without it ;) but that's a question for another thread.

[mossheim]

I can confirm this doesn't have any strange effects on Windows (at least none I can observe). I see no reason not to merge this.