The "work-around" for this one is in the patch for Bug #53276, i.e., https://savannah.gnu.org/support/download.php?file_id=44067

We could separate the code if this bug fix should be separate.  In any case, I'll give the bulk changes just to give an idea of the concept.  Basically, the code additions recognize when a drag-and-drop float occurs then immediately turns that window into a direct-floated window by docking and refloating.  The affect on appearance isn't too bad--just a momentary flash of the window.  (The title-bar-double-click and undock-button-press floats have no flash effect.)

Here are the main components:

From variable-editor.cc:

// See  Octave bug #53807 and https://bugreports.qt.io/browse/QTBUG-44813
#if (QT_VERSION >= 0x050302) && (QT_VERSION <= QTBUG_44813_FIX_VERSION)

  bool
  variable_dock_widget::event (QEvent *event)
  {
    // low-level check of whether docked-widget became a window via
    // via drag-and-drop
    if (event->type () == QEvent::MouseButtonPress)
      m_waiting_for_mouse_move = false;
    if (event->type () == QEvent::MouseMove && m_waiting_for_mouse_move)
      {
        m_waiting_for_mouse_move = false;
        m_waiting_for_mouse_button_release = true;
      }
    if (event->type () == QEvent::MouseButtonRelease && m_waiting_for_mouse_button_release)
      {
        m_waiting_for_mouse_button_release = false;
        m_waiting_for_activation_change = true;
      }
    if (event->type () == QEvent::ActivationChange && m_waiting_for_activation_change)
      {
        m_waiting_for_activation_change = false;
        bool retval = QDockWidget::event (event);
        if (isFloating ())
          {
            emit queue_unfloat_float ();
          }
        return retval;
      }

    return QDockWidget::event (event);
  }

  void
  variable_dock_widget::unfloat_float (void)
  {
    setFloating (false);
    setFloating (true);
  }
#else

and from variable-editor.h:

// See Octave bug #53807 and https://bugreports.qt.io/browse/QTBUG-44813
#define QTBUG_44813_FIX_VERSION 0x999999
  signals:

    void queue_unfloat_float (void);

  protected slots:

    void unfloat_float (void);

#if (QT_VERSION >= 0x050302) && (QT_VERSION <= QTBUG_44813_FIX_VERSION)
  protected:

    bool event (QEvent *event);

  private:

    bool m_waiting_for_mouse_move;

    bool m_waiting_for_mouse_button_release;

    bool m_waiting_for_activation_change;
#endif

The idea with this define:

#define QTBUG_44813_FIX_VERSION 0x999999

is to replace 0x999999 by the Qt version that fixes the problem.  In fact, I'm not sure the developers know exactly when the bug started, so even the lower limit of 0x050302 could have had its own definition.  Nonetheless, that's the point of it.

I'm posting this bug report as a reference point to refer to in the C++ code.  I will have the workaround as part of the code associated with Bug #53276.  The code there is too fluid to be able to coordinate two separate changesets.

In debugging that Bug #53276 code on KDE, I ran into a puzzling issue in which only if I dragged a panel (QDockWidget) from the QMainWindow to float it did the focus behavior become corrupt.  Pressing on the title bar of the floated window would show the variable name in highlighted text and background for a fraction of a second and the focus would jump back to the main window.  Keep pressing the title bar and it was only momentary focus.  In other words, couldn't focus the floated window when floated by mouse drag.

With the QDockWidget in that state, I could click the tabs to make the Variable Editor and its floated dock widget hide.  Showing again would then have a correctly function focus behavior.  So, the fix appears to be hiding-then-showing the QDockWidget in that situation.  I had to do the hide and show as queued-connections in order to make the program flow go back to the system inbetween the hide and show.

I searched a long time for this bug, but then when I took away the custom title bar and used the default title bar, I knew straight away is was a Qt/KDE bug.  Searching the Internet I found a Qt bug report that is extremely close to what I described.  The Qt bug report is here:

https://bugreports.qt.io/browse/QTBUG-44813

That will at least give us another Qt bug in which we can use a version range to isolate the added kludge.

Can close as fixed since there isn't anything to discuss or code to patch, but I will post a code hunk to this report to illustrate the solution.