Version: unspecified (using KDE 4.4.5) OS: Linux Application have no "close" event when set widget minimum size equal to maximum size (with using "Qt::FramelessWindowHint" flag). See code below: #include <QApplication> #include <QWidget> class Widget : public QWidget { public: explicit Widget(QWidget *parent = 0) : QWidget(parent) { setWindowFlags(Qt::FramelessWindowHint); setMinimumSize(800, 600); setMaximumSize(800, 600); // bug there } }; int main(int argc, char *argv[]) { QApplication app(argc, argv); Widget *widget = new Widget; widget->show(); return app.exec(); } When running application I found "close" event is absent ( like at this screenshot http://omploader.org/vNTQ2bg/%D1%81%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA3.png ). If maximum size of window not equal to minimum size -- there are no bugs. At first I knew this is a Qt bug, but under windows I don't saw this bug. Reproducible: Didn't try Steps to Reproduce: 1) Make application with window that have same minimum and maximum size 2) Run it and try to close 3) Make sure that application closed normally when minimum size of app window not equal to maximum size Expected Results: Application must closing fine when max and min size of window is same It's very "secretive" bug. You don't see it until you don't try to make window sizes like me. But it's very inconvenient when you have to make you window in way like I described ahead
Confirmed. Changing the MaximumSize to (800, 601) shows the Close entry in the taskbar menu. Could also be a KWin bug.
Seems like, kwin: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP openbox: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
it's because Client::isClosable() only relies on the motif hint and that is either wrong or wrong read in this flag combination... (mclose is false)
It might also be a Qt bug: setting wrong states? It works if I remove the FramelessWindowHint and it also works if I change the size and keep the FramelessWindowHint.
> Martin Gräßlin It does not seem a Qt bug. On Windows it's ok (I don't have Gnome and MacOS to test for this bug). I think I provide enough information to reproduce this bug and guys who wrote comments there provide enough information for developers to fix this bug. I don't have newest version KDE (I have only 4.4.5) to test this bug on it, but I think this bug still exist.
> It does not seem a Qt bug. On Windows it's ok (I don't have Gnome and MacOS > to test for this bug). I think I provide enough information to reproduce > this bug and guys who wrote comments there provide enough information for > developers to fix this bug. I don't have newest version KDE (I have only > 4.4.5) to test this bug on it, but I think this bug still exist. Erm Windows and Mac is rather irrelevant to this bug. This is X11 specific code and yes it is possible that Qt sets wrong or not all flags. Also that it works on other window managers does not say that it is a kwin bug in case other window managers work around it.
The reason why I think it's not a Qt bug - I firstly send bug-report to Qt bugtracker. It's here: http://bugreports.qt.nokia.com/browse/QTBUG-12568 Response that I receive from Qt developers is this not a Qt bug (you can read it on comments for that bug). Maybe I'm wrong. Maybe that developer wrong.
> The reason why I think it's not a Qt bug - I firstly send bug-report > to Qt bugtracker. It's here: > http://bugreports.qt.nokia.com/browse/QTBUG-12568 > > Response that I receive from Qt developers is this not a Qt bug (you can > read it on comments for that bug). Maybe I'm wrong. Maybe that developer > wrong. Looking at the comment it does not look like the developer did even think about what you wrote. He tells you that you don't have a decoration and therefore have to do your own close button (that's right as it's what CSD are) but does not consider at all that this has to be unrelated to the fact if a window is closable or not.
> Martin Gräßlin Hmm... You are right. But I cannot reopen that issue. If this bug really related with Qt - what do you think we need to do with it?
It's for sure a bug in Qt and the novell comment is bul... "wrong" :-) a) the bug is driven by the resizability (ie. the resize flag) and NOT by the fact you discarded the titlebar. b) It's Qt bug: The motif hint for your window (under every WM, this is unlike the NETWM hints not touched) is 0x4, ie. MWM_FUNC_MOVE. Without fixing the size it is (properly) 0x1 - "MWM_FUNC_ALL" Fixating the size should turn it either 0x2c - "MWM_FUNC_MOVE|MWM_FUNC_MINIMIZE|MWM_FUNC_CLOSE" or 0x3 (MWM_FUNC_ALL|MWM_FUNC_RESIZE - setting MWM_FUNC_ALL implies sustraction), but it becomes 0x4 - "MWM_FUNC_MOVE", ie. the ability to minimize or close the window are stripped with the attribute of a fixed size, what seems pretty unintended - at least makes few sense to me... This might be a restriction on some platforms, but it's an MWM bug nevertheless... And actually all WMs except KWin and maybe MWM are broken in this regard :-P