Bug 393076

Created attachment 111984 [details]
Widget Style & Behavior setting for which Oxygen has no decorations

I'm running Kubuntu (18.x) right now, but the same behavior applies to Mint KDE and Mageia latest versions.

We,ve been struggling with a bug in the Octave application in which the reparenting of the Qt window, a QDockWidget, to 0 does not create a top level window with decorations.  For background, details are here

https://savannah.gnu.org/bugs/?53276

but I think that link discussion is too much to absorb, so I will try to summarize here.

According to Qt documentation

http://doc.qt.io/qt-5/qwidget.html#details
http://doc.qt.io/qt-5/qwidget.html#top-level-and-child-widgets
http://doc.qt.io/qt-5/qdockwidget.html#setTitleBarWidget

a toplevel window for which

    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
               Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);

or even

    setWindowFlags (Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
                    Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);

should display a full array of decorations, buttons, borders, drag-movement.  For Oxygen theme, we've found that no decorations appear.  I'll summarize: A QDockWidget in a docked state that is floated and assigned the above window attributes is not acquiring window decorations in Oxygen.

One might argue that semantically Qt doesn't exactly say such a thing, but there is enough inference.  Also, I've tested the above Qt behavior in all the non-Oxygen KDE frameworks on Kubuntu 18.x and those show decorations nicely.  To be more specific, I'm attaching a screenshot of the exact KDE setting that matters,  Widget Style & Behavior.  Furthermore, the decorations rule Qt describes also works for non-KDE frameworks.

I was perplexed by how this could come about, but having looked at some KDE code from the git repository, I think I have a better understanding.  Oxygen is unique in that it, along with the KDE Window Manager, is written in Qt.  The decorations are written in Qt, the buttons, signals/slots, etc.  All fine.  Of course, Oxygen / Window Manager can't, say, call member functions associated with Qt QDockWidget and so on, without being very careful.  So, it looks to me, where QDockWidget is used by Oxygen, it is more for the sake of settings and not calling member functions.  Again, all fine, but I'm wondering if those who developed Oxygen may have not considered the above "rules", because it isn't obvious that one should check such things when they're in fact using the Qt framework.  In some sense, Oxygen is rolling its own implementation of Qt, using Qt, if you follow.

In any case, I've looked around in the source code without identifying exactly where the problem is, but I have a hunch that I think narrows things down slightly.  The important parameter in the KDE Window Manager client appears to be the setting "noborder".  That is, from kwin/client.cp:

bool Client::noBorder() const
{
    return decorationPlugin()->isDisabled() || noborder || isFullScreen();
}

I take it the plugin is enabled (in this case Qxygen), as there are plenty of elements of the Octave graphical application that have full decorations: dialog boxes, the main app, etc.  It's not full-screen, but it makes sense that isFullScreen() appears above.  So "noborder" is it.

Now, noBorder() member function is used in the following routine:

void Client::updateDecoration(bool check_workspace_pos, bool force)
{
    if (!force &&
            ((decoration == NULL && noBorder()) || (decoration != NULL && !noBorder())))
        return;
    QRect oldgeom = geometry();
    blockGeometryUpdates(true);
    if (force)
        destroyDecoration();
    if (!noBorder()) {
        createDecoration(oldgeom);
    } else
        destroyDecoration();
    if (check_workspace_pos)
        checkWorkspacePosition(oldgeom);
    updateInputWindow();
    blockGeometryUpdates(false);
    if (!noBorder())
        decoration->show();
    updateFrameExtents();
}

and it is clear if noBorder() is true, then the window decoration->show() doesn't happen.

Lastly, the following is where "noborder" is set:

void Client::detectNoBorder()
{
    if (shape()) {
        noborder = true;
        app_noborder = true;
        return;
    }
    switch(windowType()) {
    case NET::Desktop :
    case NET::Dock :
    case NET::TopMenu :
    case NET::Splash :
    case NET::Notification :
        noborder = true;
        app_noborder = true;
        break;
    case NET::Unknown :
    case NET::Normal :
    case NET::Toolbar :
    case NET::Menu :
    case NET::Dialog :
    case NET::Utility :
        noborder = false;
        break;
    default:
        abort();
    }
    // NET::Override is some strange beast without clear definition, usually
    // just meaning "noborder", so let's treat it only as such flag, and ignore it as
    // a window type otherwise (SUPPORTED_WINDOW_TYPES_MASK doesn't include it)
    if (info->windowType(SUPPORTED_MANAGED_WINDOW_TYPES_MASK | NET::OverrideMask) == NET::Override) {
        noborder = true;
        app_noborder = true;
    }
}

It's pretty clear what the above routine is doing.  Those windows which are dialogs, menus, normal, etc can have decorations, while things like splash-screens and notifications can't have decorations.  I suspect the important entry in the latter category is the NET::Dock.  I'll make a guess that Oxygen logically sets up a QDockWidget to be in the NET::Dock category and *perhaps* Oxygen is not setting the class to be something like NET::Normal when the QDockWidget becomes floated... something along that category I suspect.  Whereas, the Breeze, Fusion and Windows 9x themes have likely been following such rules for a long time with legacy KDE Window Manager and Qt-based KDE Window Manager

Octave is a big program, and probably too much for KDE developers to test, but if you'd like me to, I could probably use qtcreator to build some simple QMainWindow application that will immediately float a QDockWidget and turn it into a top-level window.