Bug 178630

Thanks for the report, I could reproduce the issue. Very strange: this must be a regression that has been introduced recently...

Will take a look when I get back to my home computer (29th-ish) :)

> 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 :-)

*** Bug 179465 has been marked as a duplicate of this bug. ***

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 :/

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).

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?

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."

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

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

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