[SOLVED] Strange main window behaviour
-
After window maximization, if I switch to another application or press any button or control on the window, window restores its size to original state and size. Have somebody met such strangeness? Why it may appear? Wrong window flags, styles, etc? Reproducible in Windows and Linux, does not exist in Mac.
Main window implementation example:
@KMainWindow::KMainWindow(QWidget * parent, Qt::WindowFlags f)
: QMainWindow(parent, f | Qt::CustomizeWindowHint)
{
}KAppMainWindow::KAppMainWindow(QWidget *parent, Qt::WFlags flags)
: KMainWindow(parent, flags | Qt::WindowCloseButtonHint | Qt::WindowMinMaxButtonsHint)
{
#ifdef Q_WS_X11
setWindowFlags(windowFlags() & ~Qt::WindowMinimizeButtonHint);
#endif
}@
-
which window manager you're using? generally, i suggest debugging internals
-
In Linux - KDE. As I said reproducible also in Windows. Internals? What do You mean? System libraries?
-
no, Qt's
-
X server sends XEvent with type=22 which means ConfigureNotify, why Qt interprets it like resize event (in translateConfigEvent) and restores window size??? Think similar situation is in Windows, need to see stack there also.
Stack:
@0 KMyWindow::resizeEvent KMyWindow.cpp 82 0x4a6649
1 QWidget::event qwidget.cpp 8449 0x7ffff4e82d82
2 QMainWindow::event qmainwindow.cpp 1478 0x7ffff524cb5b
3 QApplicationPrivate::notify_helper qapplication.cpp 4481 0x7ffff4e31234
4 QApplication::notify qapplication.cpp 4360 0x7ffff4e397ca
5 QCoreApplication::notifyInternal qcoreapplication.cpp 787 0x7ffff45fd99c
6 sendSpontaneousEvent qcoreapplication.h 218 0x7ffff4ea1233
7 QETWidget::translateConfigEvent qapplication_x11.cpp 5338 0x7ffff4ea1233
8 QApplication::x11ProcessEvent qapplication_x11.cpp 3492 0x7ffff4eafa3b
9 x11EventSourceDispatch qguieventdispatcher_glib.cpp 146 0x7ffff4ed75c2
10 g_main_context_dispatch /usr/lib64/libglib-2.0.so.0 0 0x7ffff31c0a93
11 ?? /usr/lib64/libglib-2.0.so.0 0 0x7ffff31c1270
12 g_main_context_iteration /usr/lib64/libglib-2.0.so.0 0 0x7ffff31c1510
13 QEventDispatcherGlib::processEvents qeventdispatcher_glib.cpp 422 0x7ffff46286ef
14 QGuiEventDispatcherGlib::processEvents qguieventdispatcher_glib.cpp 204 0x7ffff4ed725e
15 QEventLoop::processEvents qeventloop.cpp 149 0x7ffff45fcdd2
16 QEventLoop::exec qeventloop.cpp 201 0x7ffff45fcfe5
17 QCoreApplication::exec qcoreapplication.cpp 1064 0x7ffff460144b
18 KMyApplication::exec timedoctor_application.h 89 0x4df871
19 main main.cpp 48 0x4df556@
-
AlekseyK, nice investigation!
-
:) What to do with this investigation next? ;) I still do not know what code causes this, not able to reproduce in some test sample application to send to Qt Bug report.
-
Hmm.. If you can't reproduce that with a simple test app, then could it be caused by your app/code?
-
Not sure. Tried to find wrong posted events, memory leaks, memory errors, test sample application to reproduce the problem, no luck for now. May be Qt bug, or may be our code causes this in some indirect way. Do not have idea how to localize the problem for now.
-
If you're sure, that your app is fine, then I suggest debugging Qt. Starting from the point when it receives the event from X server (or Windows).
As a cheap thing you could try running the app under another X server
-
LOL. Was just wrong setWindowState() call without preserving old state, was:
@setWindowState(Qt::WindowActive)@
need:
@setWindowState(windowState() | Qt::WindowActive)@
