Version: (using KDE 4.0.80) Installed from: Ubuntu Packages OS: Linux The addition of tabs to have quick access to multiple folders is great, but it naturally lacks some of the advanced functionality know from Konqueror/KDE3. Here I'd like to describe those which I think are important when actually using the tab feature - maybe some of it can be implemented in Dolphin at some time. Since the following are related closely with each other I hope it's alright to have all of them in a single report; A) Open folder in new tab ---------------------- When you drag and drop a folder from the current view to empty space on the tab bar it could be opened in a new tab and switch the active view to this new tab. B) Open folder in another opened tab -------------------------- When dragging a folder on a currently opened tab and then releasing it, it could be opened in this tab - overriding the previous folder of that tab. It would be possible to switch back to the previous folder with the normal 'back' button of course. This is the behaviour in KDE3 C) Move/copy/link to other opened tab ------------------------------ Alternative to B) Unlike KDE3 dragging and releasing a folder on a currently opened tab could instead open the move/copy/link context menu, to quickly e.g. move a folder to one of the other opened tabs. D) move/copy/link inside other tab ---------------------------------- This something else than C) and is implemented in Konqueror/KDE3. When you drag a file on another opened tab and hover there a second, the current view changes to this tab. Then you can keep dragging the file to some empty space in this folder or onto a subfolder to move/copy/link it there. This I think is a very important feature for tabs in Dolphin as it enables interaction between the various opened tabs.
*** Bug 166058 has been marked as a duplicate of this bug. ***
+1 I miss D especially.
Created attachment 26756 [details] patch for activating tab switch on drag can anybody test this?
Thanks Dmitry for the patch, I'll test the patch during this week.
SVN commit 846009 by ppenz: Activate the tab when an item is dragged above an inactive tab. Thanks to Dmitry Khlystov for the patch! BUG: 164312 M +7 -0 dolphinmainwindow.cpp M +6 -0 dolphinmainwindow.h WebSVN link: http://websvn.kde.org/?view=rev&revision=846009
@Christoph: Only D has been fixed currently, I'm not sure whether this issue can be set to resolved now from your point of view... Some comments to your suggestions: A: Sounds good. Must be fixed in kdelibs so that it can be used throughout KDE -> will take a little bit time + discussions on core-devel. B: I don't understand the benefit of this. It's a lot easier just clicking on the folder to enter it instead of dragging it above the current tab. Am I missing something here? C: This conflicts with D, doesn't it?
to Christoph: B: conflicts with D:. If user dragging one folder to existing tab, how can we determine what he wants to do: open folder in this tab or switch to this tab and continue dragging? A: is interesting, but this is not a dolphin feature. Dolphin uses component from kdelibs for tabs. You can post A: to kdelibs wishlist
Thanks for the feedback and patch of course. Based on your information I'll just re-open A as a whishlist item for kdelibs. Since D is fixed now only B and C remain. From my point of view neither B nor C conflict with D - note though that I have not yet been able to check out Dimitry's actual implementation - see below. Peter, the idea with B is to drag a folder to another tab (not the current one), so that other tab's view is changed. You can check it out in Konqueror 3 or 4 - the tab behaviour seems pretty much intact in Konqueror/KDE4 as well. I included it since this is the behaviour in Konqi, so some people might expect it. Note that B and C conflict with each other. Personally I'd prefer to see C implemented. It's simply a faster way to copy/move/link to another tab than D. The difference between B/C and D, and the reason why neither conflicts with D is, that to activate D you need to hover over another tab for about one second before it switches to that tab. So if you release the mouse button before that you'd activate B/C instead of D. That said, maybe Dimitry's implementation doesn't have the delay (I assume it does not because there is no action you could invoke before the delay hits). Hope I didn't cause more confusion with all the B, C and D here. If so let me know ;) Unless you agree that C (or B) might be useful I think RESOLVED is fine for the report since the most important feature is implemented.
Reopened A) against kdelibs: Bug 169163
This bug should be reopened, because new dolphin lacks again copy/move, etc on new tab.
The regression has already been fixed for 4.8.1