Summary: | Drag and drop with tabs | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | Christoph Wiesen <cwiesen> |
Component: | general | Assignee: | Peter Penz <peter.penz19> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | adminimus, entidad_universal, kde-2011.08, marcelovborro |
Priority: | NOR | ||
Version: | 16.12.2 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | patch for activating tab switch on drag |
Description
Christoph Wiesen
2008-06-17 17:46:56 UTC
*** 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 |