Bug 178630 - "Opening folders during drag operations" only works for one directory per drag operation
Summary: "Opening folders during drag operations" only works for one directory per dra...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Unclassified
Component: general (show other bugs)
Version: 16.12.2
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
: 179465 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-24 01:51 UTC by Panagiotis Papadopoulos
Modified: 2009-01-04 19:35 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Awful band-aid "solution" for this bug (862 bytes, patch)
2009-01-04 12:25 UTC, Simon St James
Details
A slightly better heuristic for deciding if the user initiated a header resize. (679 bytes, patch)
2009-01-04 12:28 UTC, Simon St James
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Panagiotis Papadopoulos 2008-12-24 01:51:55 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

I just noticed this bug in the "Opening folders during drag operations" feature of dolphin:

You only can enter one directory per drag operation

If I drag a file into a folder and then try to drag it into another folder, dolphin won't open the folder. You have to drop the file and start another drag operation for this.

Thanks
Comment 1 Peter Penz 2008-12-24 09:47:50 UTC
Thanks for the report, I could reproduce the issue. Very strange: this must be a regression that has been introduced recently...
Comment 2 Simon St James 2008-12-24 09:57:51 UTC
Will take a look when I get back to my home computer (29th-ish) :)
Comment 3 Peter Penz 2008-12-24 10:25:30 UTC
> Will take a look when I get back to my home computer (29th-ish) :) 

That would be great, thanks :-) I took a short look into the history of FolderExpander, but could not find anything suspicious. Also the recently introduced DolphinViewAutoScroller seems to be innocent. Very interesting: when dragging from an icon view into a folder which uses the details view, the columns of the details view don't appear at all... I'm sure this must be only a very minor issue that has been introduced during the last weeks.

BTW: I'm also offline until the end of this year :-/ OK, this is my last entry for today, merry Christmas :-)
Comment 4 Dario Andres 2009-01-03 15:10:52 UTC
*** Bug 179465 has been marked as a duplicate of this bug. ***
Comment 5 Simon St James 2009-01-03 16:14:16 UTC
During the second hover, in DolphinController::triggerItem(const QModelIndex& index), m_mouseButtons is 0, and as of 

http://websvn.kde.org/?view=rev&revision=888007

this will cause triggerItems to exit without doing anything.  Unfortunately, I don't really understand the history behind the usage of m_mouseButtons (the Qt Task Tracker doesn't seem to be particularly informative), so I think I'll have to bounce this one back to Peter, I'm afraid :/
Comment 6 Simon St James 2009-01-04 12:25:32 UTC
Created attachment 29888 [details]
Awful band-aid "solution" for this bug

Last-resort "fix" for this issue.  Peter: depending on what you have in mind for when Qt-issue 176832 is fixed, do you think it would be better to have two overloads of DolphinController::triggerItem(const QModelIndex& index, ...), where one allows the mouse button state to be passed in, and the other simply calls this with m_mouseButtons as the argument? Then DolphinView::enterDir(...) could call DolphinController::triggerItem(index, Qt::LeftButton).
Comment 7 Simon St James 2009-01-04 12:28:14 UTC
Created attachment 29889 [details]
A slightly better heuristic for deciding if the user initiated a header resize.

I'm not sure why the bug is re-appearing now, but http://websvn.kde.org/?view=rev&revision=879152 probably doesn't go far enough.  What do you think of the attached?
Comment 8 Simon St James 2009-01-04 12:29:18 UTC
Oops - the second patch is for this issue:

"Very interesting: when
dragging from an icon view into a folder which uses the details view, the
columns of the details view don't appear at all... I'm sure this must be only a
very minor issue that has been introduced during the last weeks."
Comment 9 Peter Penz 2009-01-04 19:20:03 UTC
SVN commit 905622 by ppenz:

Don't set the mouse button state to NoButton, this is invalid e. g. during a drag operation. The mouse button state will be updated anyhow on each item-click. This fixes the regression that the feature "automatically open folders during drag operations" did not work anymore after one level.

Thanks to Simon St. James for the good analyzes!

BUG: 178630

 M  +0 -6      dolphincontroller.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=905622
Comment 10 Peter Penz 2009-01-04 19:26:47 UTC
SVN commit 905627 by ppenz:

Fixed issue that in combination with the "automatically open folders during drag operations" the details view is not drawn correctly in the following case: Drag an item in the icons view to a folder which uses the details view.

Thanks to Simon St. James for the patch!

CCBUG: 178630

 M  +4 -2      dolphindetailsview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=905627
Comment 11 Peter Penz 2009-01-04 19:35:37 UTC
SVN commit 905632 by ppenz:

Only expand the tree view if it has an enabled 'itemsExpandable' property. If this is not the case, the folder will get opened like in the icon view by exchanging the whole content.

CCBUG: 178630

 M  +1 -1      folderexpander.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=905632