Version: (using KDE 4.2.2) After splitting the current view and hiding one of the views (by dragging its border all the way to the right or left) if one hits the close button, to close the current view, it is no longer possible to access the still-open view (that we previously hid). Doing so, it is no longer possible to visualize any information regarding your file structure. How to reproduce: 1) Open dolphin 2) Split 3) Hide one of the views (all the way to left or right) 4) Close the visible view Note: This also applies to Kate.
Thanks for the bug report! I can confirm this issue in 4.2.2 and current trunk. The easiest way to fix this is probably to prevent the QSplitterHandle between the views from being dragged all the way to the left or right (see patch below). Although I think that it does not make much sense to hide one of the views completely, my patch is more a workaround than a real fix. I don't know yet what the root cause of this strange behaviour is. Please file a separate bug report for Kate. Thanks! Index: src/dolphinmainwindow.cpp =================================================================== --- src/dolphinmainwindow.cpp (revision 957336) +++ src/dolphinmainwindow.cpp (working copy) @@ -348,6 +348,7 @@ ViewTab viewTab; viewTab.splitter = new QSplitter(this); + viewTab.splitter->setChildrenCollapsible(false); viewTab.primaryView = new DolphinViewContainer(this, viewTab.splitter, url); viewTab.primaryView->setActive(false); connectViewSignals(viewTab.primaryView); @@ -981,6 +982,7 @@ setAcceptDrops(true); m_viewTab[m_tabIndex].splitter = new QSplitter(this); + m_viewTab[m_tabIndex].splitter->setChildrenCollapsible(false); setupActions();
Thanks Frank for the patch. Although it seems to be a workaround, I'd say please commit the patch as honestly speaking I've no idea currently how to fix the root cause itself.
SVN commit 957703 by freininghaus: Make it impossible to hide one of the views in a split view setup completely by dragging the QSplitterHandle to the left or right. This fixes the problem that a hidden view disappears completely after closing the visible view. The root cause of this issue still seems to be unclear though. BUG: 190265 M +2 -0 dolphinmainwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=957703
SVN commit 957706 by freininghaus: Make it impossible to hide one of the views in a split view setup completely by dragging the QSplitterHandle to the left or right. This fixes the problem that a hidden view disappears completely after closing the visible view. The root cause of this issue still seems to be unclear though. CCBUG: 190265 M +2 -0 dolphinmainwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=957706
I think the actual cause of the bug was that QSplitter resizes the remaining widgets after one widget was removed, but only those that are not hidden (see QSplitterPrivate::doResize()). An alternative fix would then be to un-hide the hidden view manually by a call to QSplitter::setSizes(). But IMHO, the current solution is better because hiding one of the views by moving the QSplitterHandle between them is not really needed - if I want to see only one view, I can just close the other one ;-)
Created attachment 33128 [details] Testcase I think this might be a qt bug. I've made a small test case, and if you collapse the splitter then click on the "delete" button, the current widget is (correctly) deleted, but the hidden one just goes away. What do you think? Should this be reported upstream? Is there someone with sufficient qt knowledge that can answer if this is a bug or supposed to be like this?
@Ivo: Nice testcase! As I said in my previous comment, I think the problem is that 'collapsed' widgets (that's how QSplitter calls them internally) are never 'uncollapsed' when other widgets inside the QSplitter are removed. I think that the fact that there's no way for the user to recover the collapsed widget is indeed a bug that should probably be reported. However, I'm not sure what change to suggest. In our case it's obvious what to do (just show the collapsed widget if the other one is removed), but if there are more collapsed widgets, which one shall be shown if the last visible one is removed? And if all widgets have maximum/minimum sizes, one could maybe think of even more complex situations where collapsed widgets should be shown just to fill up the available space, even if the removed widget is not the only visible one. Anyway, maybe Peter or somebody else has a good idea, or the Qt Software people themselves can think of a good solution :-)
Yes, with multiple splitters (I was playing around with that too on the testcase, that's why I made it like that), it can be hard to decide which widget to show, but I think that at least the splitter should never disappear. Maybe this should be configurable, applications might want to say "never 'uncollapse' widgets, even if it results in the user staring at a grey space with a small splitter on the side; 'uncollapse' the last widget remaining and hide the splitter (should be the default?), or try to rearrange all splitters to 'optimal' sizes".
I've reported this upstream here: http://www.qtsoftware.com/developer/task-tracker/index_html?id=254111&method=entry . Hopefully the folks at Qt Software will solve this at the right level in the stack.
Qt devs have fixed this recently: http://bugreports.qt.nokia.com/browse/QTBUG-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel http://qt.gitorious.org/qt/qt/commit/a925ba1ab6316a155f2ac61f898c52f07a1340b4