Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Positions when moving files to desktop or renaming files on desktop #500

Closed
agaida opened this issue May 1, 2017 · 9 comments
Closed

Positions when moving files to desktop or renaming files on desktop #500

agaida opened this issue May 1, 2017 · 9 comments

Comments

@agaida
Copy link
Member

agaida commented May 1, 2017

This is a follow up for #495 and lxqt/lxqt#1030.

Imho the current handling of moving or renaming files is false in the sense that it don't match users expectations. When i move a file (or a bunch of) to the desktop per drag and drop i expect that it lands on the mouse position. When i rename a file it should stay in the position where it was before - when the desktop is set to use custom positions instead of auto-sorting.

Sample of that behaviour (Win 10): https://youtu.be/0H9p4XqO6dA

@tsujan: feel free to change title or wording - i don't know how to describe it better.

@tsujan
Copy link
Member

tsujan commented May 1, 2017

@agaida The wording is good enough.

As for renaming, it's possible only when files are renamed on deskop itself -- and I think that's sufficient.

I also think that this should be added as an option in Desktop Preferences.

The needed code seems to be more or less straightforward.

@tsujan
Copy link
Member

tsujan commented May 1, 2017

This is my plan for now (you may disagree with it, of course):

(1) The auto-sorting will remain intact so that when a file is pasted or downloaded to desktop, it will appear according to the chosen sorting.

(2) When files are put on desktop by dragging and dropping, they will (almost) land on the mouse position (but optionally).

(3) When a file is renamed from inside desktop, its position won't change (but optionally).

@fulalas
Copy link

fulalas commented May 1, 2017

@tsujan, sounds great. But my dream is an option to disable auto-sorting, like Windows, for example. In other words, it would add icons like a stack (from top left to bottom right).

@tsujan
Copy link
Member

tsujan commented May 1, 2017

it would add icons like a stack (from top left to bottom right).

That means all items are listed, instead of them being sorted. it can be implemented but please let me first implement the above-mentioned properties in an experimental PR. Then it could be tested and more properties could be added step by step. I think the current desktop structure has still potential.

@tsujan
Copy link
Member

tsujan commented May 1, 2017

On second thought, I should say that auto-sorting cannot be removed logically. Suppose that we put items on desktop only based on a growing list (which means stacking). Then, yes, we could add new items to the end of the list but where on desktop? Stacking doesn't mean that there are no gaps between the real items on desktop -- and the gaps can be large. Should we put the new item immediately after the last one? The answer is no because the last item may be positioned at the right of dekstop.

So, I stick with my previous plan for now.

@fulalas
Copy link

fulalas commented May 1, 2017

Should we put the new item immediately after the last one?

No. You put on the first found gap -- unless user created/moved/copied an icon to a specific place, of course.

OK, no need to hurry. :)

@tsujan
Copy link
Member

tsujan commented May 2, 2017

No. You put on the first found gap

First found gap is not an option -- the user wants to find the file that's just downloaded to desktop quickly, for example. The end of the first incomplete column is almost acceptable.

Good news: landing on drop position for multiple files is possible with the current structure. But I have to find a way to make it more elegant.

Bad news: As I'd suspected a year ago, fixed position after renaming is not possible with the current structure (of course, when sorting is done based on modification time, items have already a fixed position on renaming). The reason is that renaming is dealt with as a removal immediately followed by an addition. I "succeeded" in fixing the position on renaming only with dirty hacks that aren't acceptable at all.

tsujan added a commit that referenced this issue May 7, 2017
Fixes (a part of) #500.

For a more natural "desk-top" experience, dropped items are positioned successively (top→bottom + left→right), starting with the drop position (rectangle).

IMO, there's no need to make this optional because mose users expect such a behavior and if a user doesn't want it, he/she could use the context menu easily (see #499).
tsujan added a commit that referenced this issue May 7, 2017
Fixes (a part of) #500.

For a more natural "desk-top" experience, dropped items are positioned successively (top→bottom + left→right), starting with the drop position (rectangle).

IMO, there's no need to make this optional because most users expect such a behavior and if a user doesn't want it, he/she could use the context menu easily (see #499).
agaida pushed a commit that referenced this issue May 10, 2017
Fixes (a part of) #500.

For a more natural "desk-top" experience, dropped items are positioned successively (top→bottom + left→right), starting with the drop position (rectangle).

IMO, there's no need to make this optional because most users expect such a behavior and if a user doesn't want it, he/she could use the context menu easily (see #499).
@tsujan
Copy link
Member

tsujan commented Jul 3, 2017

For the record, dropping at drop position is done by #504.

@agaida agaida added this to Whishlist in Issues Jul 14, 2018
@agaida agaida closed this as completed Oct 7, 2018
Issues automation moved this from Wishlist to Closed Oct 7, 2018
@agaida agaida added this to Done in Issues Nov 26, 2018
@ghost
Copy link

ghost commented Jan 5, 2019

i don't understand... this issue is being ignored? opening new ticket...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Issues
  
Closed
Issues
  
Done
Development

No branches or pull requests

3 participants