Bug 380897 - Renaming icons will reset the position
Summary: Renaming icons will reset the position
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Desktop icons & Folder View widget (show other bugs)
Version: 5.10.0
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-06 15:28 UTC by Gabriel C
Modified: 2017-06-30 06:44 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel C 2017-06-06 15:28:43 UTC
To reporduce that create a new folder , move it away from the top left corner where
it gets created. Now rename it to something else.

The renamed folder will reset his position back to top left corner.
Comment 1 Eike Hein 2017-06-07 09:04:53 UTC
I'm guessing this is related to bug 380898.

I recall working in the past specifically to fix this. I extended the DBus signal protocol used to get file change notifications into KDirModel so kio_desktop could probably cause a dataChanged instead of remove+insert so we wouldn't toss the position information aside. That worked fine, so this is a regression.
Comment 2 Eike Hein 2017-06-30 06:44:13 UTC
Git commit 6ca0b93e6029dc53a09e9e498e509ba714c2a1d7 by Eike Hein.
Committed on 30/06/2017 at 06:43.
Pushed by hein into branch 'master'.

Use KIO::rename instead of KIO::moveAs in setData

Summary:
We've recently been plagued by issues where renaming via KDirModel would
fail to call into the rename() implementation of kio_desktop (which is a
KIO::ForwardingSlaveBase). Instead it would end up doing a copy job on
its own, resulting in file removal + addition events, causing us to
ultimately lose icon positions on the desktop.

While I did work out why this happens through moveAs (it resolves to
local URLs and then does a direct rename on them, bypassing SimpleJob
calling into the slave), I failed to find anything wrong with it,
leaving the reasons for the behavior change as a mystery for now: It's
possible that fixes done to kio_desktop (e.g. 6911541421dc in plasma-
workspace) or porting away from kdelibs4support (f81c843dcfb3, same
repo) triggered it in some way in concert with KIO changes (super-
ficial bisecting didn't yield anything, though).

Meanwhile, this patch ports setData from moveAs to rename, which uses
SimpleJob directly, successfully calling into the slave (which we
really really want to do, as only the slave will trigger the right
KDirNotify change signals, avoiding a row remove+insert transaction
pair in the model).

This makes sense to me regardless of the behavior issue with moveAs.
While rename doesn't work across destination, setData operates on a
single model index, and only on the file name, so this can't happen
anyway, making rename the semantically correct call to make.
Related: bug 380898

Reviewers: #frameworks, dfaure, davidedmundson

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D6413

M  +2    -2    src/widgets/kdirmodel.cpp

https://commits.kde.org/kio/6ca0b93e6029dc53a09e9e498e509ba714c2a1d7