see e.g. https://bugs.kde.org/show_bug.cgi?id=315660 Reproducible: Always Actual Results: activeViewSpace() returns a pointer to the wrong viewspace (we should check for a pattern) Expected Results: it should always return the viewspace which is actually the active one
After some debugging I think this is due to activeViewSpace returning m_viewSpaceList.first() if no view space is marked as active. Now the more interseting question is why no viewspace is active. I'm still researching it.
If you find some reason, patches are really welcome!
Status update: After more debugging, here's what I've found out: After parentSplitter->insertWidget (index, currentSplitter->widget (0)); in KateViewManager::removeViewSpace, the activeViewSpace function reproducible returns a different value than before it. I'm not really sure why, and not even if the exact behaviour is deterministic, though the end result is always that a wrong value is returned. @Chritstoph: Any idea what could cause this? I can't say that I really understand what the code is doing there.
Hmm, I just look at the code, what means: wrong value? I mean, if the active viewspace is removed randomly one will be picked as new active.
If your comment is about comment #1: I can't reproduce that behaviour anymore (at least not the way I reproduce the bug at the moment). For what I'm doing now: I reverted commit 2e38699a04fc804b7619d0c48b6bea48b2dfa40f (which works around the issue), and reproduce the problem with the steps mentioned in Bug 315660 . Wrong value in the context of closing the other views means that firstly activeViewSpace returns the correct, active viewspace. Then, after removing some view spaces (none of them being the active one), activeViewSpace returns a different value. IMHO, removing/deleting view spaces which are not active shouldn't change the active view space. I've described what (I think) happens in the mail to the mailing list.
http://lists.kde.org/?l=kwrite-devel&m=136507949428322 says: This is more or less what happens: 1) parentSplitter->insertWidget (index, currentSplitter->widget (0)) in KateViewManager::removeViewSpace, kateviewmanager.cpp gets called 2) which triggers KateViewManager::activateSpace, which sets the wrong viewspace to active. 2) gets called, because of connect(view, SIGNAL(focusIn(KTextEditor::View*)), this, SLOT(activateSpace(KTextEditor::View*))); in kateviewmanager.cpp, line 416 as the focusIn signal is emmited
Actually, I am not aware of problems caused by that, therefore, I think we just ignore this behavior.