Steps to reproduce: 1) open a dolphin window, call this window "A". 2) open another window (another application, konqueror for example), call this window "B". 3) open a new dolphin window, call this window "C". -> now we have "A" below "B" which is below "C". 4) select a file on "C" and press ALT+Enter: this will open a properties dialog window -> now the window order (from bottom to top) is: B, A and C. I hope to have correclty explained the problem. I'm not sure this is a dolphin problem, maybe it could be a kwin one.
confirmed, does not happen with compiz actually the other window is raised as soon as the dialog takes the focus (try increasing the focus stealing prevention to extreme) the dialog is /not/ modal and transient to the window it's opened from /only/ i nevertheless suspect it's related to the two dolphin windows being children of the same process...
i assume layers.cpp:393ff is the "trouble" causer if a transient window is raised all group members are raised instead just "c->transientFor()" unfortunately i cannot test atm (need to rebuild kdelibs before...)
ok, this "fixes" it - i.e. the result is as expected (only the dialog parenting dolphin window is raised in case - lilke in compiz) question: is the current behaviour intended (like helping out theGimp or so?)
Created attachment 36317 [details] functional patch (original code is only commented, not deleted)
Patch does not take into account recursive transients.
Created attachment 36318 [details] Handle recursive transients Would it be necessary to also catch cyclic transients, i.e. e.g. A -> B -> C -> D -> B while ((transient_parent = transient_parent->transientFor()) && !transient_parent.contains(transient_parent))
Patch is fine to commit.
SVN commit 1030954 by luebking: don't raise the whole group with a transient, but only its ancestors BUG: 199910 M +6 -4 layers.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1030954