Unfortunately the behaviour that I experience is occasional, and I have no way to systematically reproduce it. After working with kig, or even just after loading kig with an argument, pressing the "Save As" button (or pressing Ctrl+Shift+S) completely freezes the kig window. I could only kill it by pressing "Ctrl-C" on the console from which I started it. (On my DELL laptop with Fedora 22 and a fresh installation from sources of kig) Reproducible: Sometimes Steps to Reproduce: Start kig with an example: $ kig fuga.kig [the url above points to the file given] [<Enter> to quit the "tip of the day"] Press: Ctrl-Shift-S Actual Results: Sometimes (for me a frequency like 1 every 2 or 3 tries) the kig window completely freezes, no button is responding (not even the "quit" button to quit the window). When kit does work correctly, I quit kig and retry by invoking "$ kig fuga.kig" again. Expected Results: A window should appear asking the file name kig is compiled using the following cmake invocation: $ cmake . -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull -DPLUGIN_INSTALL_DIR:PATH=/usr/lib/qt5/plugins
I have news on this problem! I still do not know *what* triggers this behaviou, however a collegue of mine experienced the same on his workstation (fedora 22 with an rpm installation of kig: Applications/15.04.03), whereas on my other workstation I could never see the problem. The "big" news is that actually it only seems to be a visualization problem: kig does not freeze, but behaves exactly as if the dialog window were present! So it is sufficient to blindly write the file name and press enter (or just press enter). It seems something related to some missing "refresh" or some caching of graphics primitives that is not flushed before user input... I tried to experiment with the kig sources, but actually I have no idea what is the source file where to work.
Since you don't actually lose data I decreased the severity of the bug
Additional info. There are now three computers where the problem is present. Two workstations and one laptop. All with fedora 22 installed, kig (and the whole kde) at version 15.04.3. Actually, the problem seems to reside *outside* of kig, and precisely in the QFileDialog::getSaveFileName However I couldn't find any other kig application exhibiting the same behaviour, so I am not really sure whether perhaps there is a buffer overflow somewhere cousing the problem just as a collateral effect. Resuming: the problem occurs occasionally (frequency about 10 to 25 percent). In case of problem: pressing <Ctrl><Shift>-S (save as) no window appears, however it seems that there is an invisible 'ghost' window that grabs keybord keystrokes (not sure about the mouse, but the main window is apparently completely freezed), since pressing <Alt>-C allows to regain control of the main kig window. Same with other actions (e.g. "export"). Unfortunately I am still not able to deterministically trigger the problem. If you are not able to reproduce the problem, do you have some suggestions on how I could get more info? Some "cmake" flag?
Additional info: I tried "xwininfo -name "Saving..." in the two situations: when everything is fine and the Dialog window is open and when the problem occurs, and everything seems freezed. In the latter case I get: $ xwininfo -name "Saving..." [...] Map State: IsUnMapped [...] whereas when I see the window I get: Map State: IsViewable So the Dialog window is there, but it is not mapped for some reason. I suspect that the problem is not in kig itself but perhaps in qt; however kig is the *only* application for which I experience the problem, so I will insist posting here. I also tried messing with qtbase sources (5.5.0), when everything freezes. ---- exerpt from qdialog.cpp -------- int QDialog::exec() [...] show(); printf ("I AM HERE!\n"); // <-- this is printed when the problem occurs QPointer<QDialog> guard = this; if (d->nativeDialogInUse) { d->platformHelper()->exec(); } else { QEventLoop eventLoop; d->eventLoop = &eventLoop; (void) eventLoop.exec(QEventLoop::DialogExec); }
The problem apparently disappeared after an update of Fedora 22 from kf5-*-5.14.* --> kf5-*-5.15.* I don't know exactly which is the involved package because I cannot find the 'old' *-5.14.* fedora RPMs. Perhaps we could close the bug report...
OK, let's consider it fixed for now (closing) feel free to reopen otherwise.