Bug 315722

Thanks for the report, I agree that this might make sense. I'm not quite sure though what we should do if multiple files are pasted/dropped - maybe always scroll to the first one?

(In reply to comment #0)
> Since other people might prefer the current functionality, this
> should probably be a setting.

IMHO, there should definitely not be a setting for that. If we add options for every little detail, the settings dialog will quickly turn into an unusable mess.

(In reply to comment #1)

I thought about that as well, since multiple files might spread beyond the window's height when pasted together. I think the best solution would be to scroll to the last file. Perhaps bottommost with ascending sorting, and topmost with descending sorting... so you always see the latest.

A menu option might not be needed for this, and it would indeed clutter the menu to add those for little things. Perhaps it should be a setting in the config file only (editable manually) but enabled by default, just in case someone happens to be bothered by this change (very unlikely though).

(In reply to comment #2)
> A menu option might not be needed for this, and it would indeed clutter the
> menu to add those for little things. Perhaps it should be a setting in the
> config file only (editable manually) but enabled by default, just in case
> someone happens to be bothered by this change (very unlikely though).

Config-file only options are only used under extremely exceptional circumstances. I would not introduce such a setting just based on the assumption that someone might want to change it.

We would not only have to tell every user who wants to change the behaviour about the hidden setting (and thus spend much time providing support). Another problem is that, even if hidden settings do not clutter the settings dialog, they still require multiple code paths and additional code to read the setting from the config file and thus make future maintenance harder.

(In reply to comment #3)

Makes sense. No worries about it then, this does sound like something that wouldn't need a setting overall. But I hope it can be done in the code for next version, it would be useful functionality.

I recently noticed something that might be of use to this problem. If you open a large folder in Dolphin, select a file near the top, scroll down so the file you selected is out of range, then press one of the arrow keys to move the selection, Dolphin knows to auto-scroll back up so you see where the selection went. Sounds like the same system can be used for pasted files too, and only needs to be triggered by this event also.

(In reply to comment #5)
> I recently noticed something that might be of use to this problem. If you
> open a large folder in Dolphin, select a file near the top, scroll down so
> the file you selected is out of range, then press one of the arrow keys to
> move the selection, Dolphin knows to auto-scroll back up so you see where
> the selection went. Sounds like the same system can be used for pasted files
> too, and only needs to be triggered by this event also.

This is unrelated. The code for handling keyboard events just makes sure that the view scrolls to the new current item.

Scrolling to one of the pasted files is not quite as straightforward, I'm afraid.

Git commit e92b4ba227c71dc5f26e9bc46f299814a70033e9 by Emmanuel Pescosta.
Committed on 23/04/2013 at 22:50.
Pushed by emmanuelp into branch 'master'.

Scroll to newly pasted files.

If multiple files are pasted, scroll to the first pasted file.
REVIEW: 109950
FIXED-IN: 4.11.0

M  +11   -2    dolphin/src/views/dolphinview.cpp
M  +1    -0    dolphin/src/views/dolphinview.h

http://commits.kde.org/kde-baseapps/e92b4ba227c71dc5f26e9bc46f299814a70033e9

I got so used to "finding" the pasted files, that I did not even notice how painful it was. So I was a bit irritated yesterday, when the new files simply appeared without hunting. Awesome little patch, that makes a large difference. Merci!

I upgraded from KDE 4.10.5 to KDE 4.11.2 yesterday. Although it's stated that this was fixed in 4.11, it does not work for me. I still get the old behavior, and Dolphin doesn't scroll to the location where new files are pasted. I assume there might be a bug which causes it not to work?

Cannot reproduce. Can you please describe in detail (including the view mode, and every key press/mouse click that you do) how you paste files such that the view does not scroll to the new position?

The view mode is always Icons. Size is 32 pixels when Preview is disabled, 48 pixels when Preview is enabled (I only tested with it enabled). In my test, the Dolphin instance in which files were pasted had Sort By set to either Name and Date, always in ascending order.

The method of copying or moving files was by having two Dolphin instances, and Shift + dragging or Control + dragging one or more files from one window to the other. I also tried to move a file from the desktop by using cut (Control + X -> Control + V) and the result was the same.

Not sure if relevant, but Dolphin no longer has its own version so I don't know if it's 2.2. It's now called 4.11.2 like KDE itself.

Over the last few months, I noticed there are rare cases when this does work as intended. I don't know which factors and settings cause it to work, but there have been a few moments when I dragged a file to a Dolphin window and it automatically scrolled there. 95% of the time however, Dolphin never scrolls. I'm currently on 4.11.3 also.

(In reply to comment #11)
> The method of copying or moving files was by having two Dolphin instances,
> and Shift + dragging or Control + dragging one or more files from one window
> to the other.

This is drag&drop. The fix from comment 7 was only for files that got pasted (by pressing Control+V or by choosing "Paste" from the context menu or the toolbar).

We can keep this report open as a wish to extend this functionality to the drag&drop case. I'm not sure if both should be treated the same way though. In the drag&drop case, it's possible that the user drags many files one by one from the left view to the right view. It might be annoying if the view scrolls to a different position every time. But I see that it can also be annoying to have to scroll and look for the file(s). I really don't know what's best.

The "Paste" case is different because it's not so likely that the user performs a sequence of many "Paste" operations - between two "Paste"s, one has to activate a different view first, select files there and invoke the "Copy" or "Cut" actions.

Ah, yes. I can confirm that at least in 4.11.4, Dolphin does properly scroll to where files are pasted. I didn't think there would be any difference with dragging and dropping. If the developers agree, I would indeed like to see the same functionality for it... which is actually what I had in mind when I suggested the feature initially.

+1 for scrolling to dropped items.

@Frank:
I'll implement it, when you give me the ok ;)

(In reply to comment #15)
Since this is probably something simple to code, and I don't think there's any reason for anyone to oppose it, that would be a welcome thing to do in my opinion. Frank might be away or not watching this, since there's been no response for 3 weeks, but hopefully he or someone else can still review it.

Git commit f40cc13d3137a1c3d86517a55aacf83dae64d5a2 by Emmanuel Pescosta.
Committed on 27/02/2014 at 11:17.
Pushed by emmanuelp into branch 'KDE/4.13'.

Scroll to newly dropped files.

If multiple files are dropped, scroll to the first dropped file.
FIXED-IN: 4.13
REVIEW: 116020

M  +1    -0    dolphin/src/views/dolphinview.cpp

http://commits.kde.org/kde-baseapps/f40cc13d3137a1c3d86517a55aacf83dae64d5a2