Version: (using KDE Devel) Installed from: Compiled sources Compiler: g++ OS: Linux When I load KDevelop I get a KDevelop window with no contents then a seperate main window called "mdi_area_cover" which contains all the dockwindows and childwindows. I've had this error before and posted a message to the mailing list along with a screenshot, see: http://lists.kde.org/?l=kdevelop-devel&m=108185261702286&w=2 I can reproduce the error as follows: 1) By default I use KDevelop in IDEAl Mode. 2) Change to Childframe mode then restart KDevelop 3) Change back to IDEAl mode then restart KDevelop 4) The "mdi_area_cover" window should appear. Note this only happens with CVS - I can't reproduce this bug using stable KDevelop. Temporary fix provided by Jens Dagerbo replying to my post on the mailing list: "Try this: Close KDevelop, open your ~/.kde/share/config/kdeveloprc file, remove anything that says [dockSetting.. or [dockSession (this is probably most of the file), save. Restart KDevelop. Hopefully, it should be back to normal now." I find it easier to just remove the file altogether then re-configure KDevelop (works out to be quicker in the end!).
Yep, just got bitten by this one myself... nasty.
I spent an hour or two trying to understand this last night. My educated guess is: KMdiMainFrm, at least when running in IDEAl mode, cannot restore the dockwidget settings stored by a different UI mode. The problem described by this BR could also be triggered when doing runtime switches between UI modes. For this reason, KDevelop was recently changed in HEAD to only allow UI mode changes via a restart, in the hope this would result in better behaviour. However, dockwidget restoration had been disabled since around 3.0-beta2 as it was simply too buggy and was only re-enabled in HEAD about a month ago. Re-enabled dockwidget setting restoration + restart-only UI mode changes is what is now producing This bug.
I fixed this a month or so ago. The various ui modes now write to their own settings file, so they only ever get to read what they wrote themselves. I can no longer trigger this behaviour after this fix. FIXED.