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
Comments
@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. |
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). |
@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). |
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. |
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. |
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. :) |
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. |
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).
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).
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).
For the record, dropping at drop position is done by #504. |
i don't understand... this issue is being ignored? opening new ticket... |
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.
The text was updated successfully, but these errors were encountered: