Bug 315722 - Dolphin doesn't automatically scroll to where new files are pasted / dragged
Summary: Dolphin doesn't automatically scroll to where new files are pasted / dragged
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: view-engine: general (show other bugs)
Version: 2.2
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-24 16:31 UTC by Mircea Kitsune
Modified: 2014-02-27 11:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.13


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mircea Kitsune 2013-02-24 16:31:51 UTC
If you open a folder that's large enough to require the vertical scrollbar, dragging or pasting new files will not move your view to where the files appeared. If you want to see them or make sure they got copied, you need to scroll manually until you find them.

Reproducible: Always

Steps to Reproduce:
1. Let's say you have a folder with 1000 files in it. Since they can't fit in the view you'll have a scrollbar to go up and down. All file names begin with the letter "a" and sorting is set to Names.

2. With the view scrolled to the top, paste a file which begins with the letter "b" in that folder. The file will appear at the bottom.
Actual Results:  
The view will not move, and it will stay at the top.

Expected Results:  
The view should automatically go to the bottom where the new file appeared.

As someone who moved from Windows and its desktop shell, this is something that has been bothering me slightly, and I'd like to see Dolphin being aware of it. Since other people might prefer the current functionality, this should probably be a setting.
Comment 1 Frank Reininghaus 2013-02-24 17:12:17 UTC
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.
Comment 2 Mircea Kitsune 2013-02-24 18:41:03 UTC
(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).
Comment 3 Frank Reininghaus 2013-02-25 08:55:10 UTC
(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.
Comment 4 Mircea Kitsune 2013-02-25 10:36:57 UTC
(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.
Comment 5 Mircea Kitsune 2013-03-11 18:45:10 UTC
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.
Comment 6 Frank Reininghaus 2013-03-19 11:27:18 UTC
(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.
Comment 7 Emmanuel Pescosta 2013-04-23 20:52:22 UTC
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
Comment 8 Christoph Feck 2013-04-30 21:28:38 UTC
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!
Comment 9 Mircea Kitsune 2013-11-13 23:15:42 UTC
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?
Comment 10 Frank Reininghaus 2013-11-14 08:06:57 UTC
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?
Comment 11 Mircea Kitsune 2013-11-14 11:54:09 UTC
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.
Comment 12 Mircea Kitsune 2014-01-12 00:29:14 UTC
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.
Comment 13 Frank Reininghaus 2014-01-19 23:04:10 UTC
(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.
Comment 14 Mircea Kitsune 2014-01-21 14:30:48 UTC
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.
Comment 15 Emmanuel Pescosta 2014-02-05 15:33:32 UTC
+1 for scrolling to dropped items.

@Frank:
I'll implement it, when you give me the ok ;)
Comment 16 Mircea Kitsune 2014-02-23 12:26:06 UTC
(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.
Comment 17 Emmanuel Pescosta 2014-02-27 11:18:37 UTC
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