| Summary: | Folder View does not perform timely repaint when drag does remove file | ||
|---|---|---|---|
| Product: | [Plasma] plasma4 | Reporter: | David Benjamin <davidben> |
| Component: | widget-folderview | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
SVN commit 824463 by fredrik: A successful drop doesn't always mean that the dragged icons are moved out of the folder, so always repaint the area occupied by the icons after a drag operation. Patch by David Benjamin. BUG: 164949 M +3 -5 folderview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=824463 |
Version: (using Devel) Installed from: Compiled sources OS: Linux When dragging an icon from a Folder View where the drag does not remove the file (e.g. to the Frame applet or creating a link), the icon does not get repainted until hover. Patch below results in a repaint regardless of the result of the drag. Alternatively, if (result != Qt::MoveAction) could be used, but I don't know if it's possible to get a Qt::MoveAction and not actually remove the file. A confused client or moving into the same folder, perhaps? Index: folderview.cpp =================================================================== --- folderview.cpp (revision 824074) +++ folderview.cpp (working copy) @@ -1399,10 +1399,8 @@ m_dragInProgress = false; - // Repaint the dragged icons if the drag was canceled - if (result == Qt::IgnoreAction) { - markAreaDirty(boundingRect); - } + // Repaint the dragged icons in case the drag did not remove the file + markAreaDirty(boundingRect); } QSize FolderView::iconSize() const