Created attachment 175553 [details]
Concept art of the "Grid visualization circle" following the cursor.

Created attachment 175554 [details]
Fade out stays on the dropped file.

A nice touch would be the grid staying on the dropped file as it fades out like this concept gif.

Please ignore the part about following the cursor, just make follow the file/folder being dragged.

*** Bug 495067 has been marked as a duplicate of this bug. ***

Created attachment 175557 [details]
Highlight Right-Clicked area when "Create New" from the Context Menu is selected.

Additionally, I'm requesting that when "Create New" from the Context Menu is selected, the area which a file/folder would be created becomes highlighted and the grid visualizer also appears.

It would be nice if the border of the circle of the grid were always faded into transparency. It would look more aesthetic that way.

It's an interesting idea, but can you explain why? What advantage would this offer the user?

(In reply to Nate Graham from comment #6)
> It's an interesting idea, but can you explain why? What advantage would this
> offer the user?

It makes it less of a hassle to organize files on a very high resolution monitor/TV with low scaling percentage, or small icons settings, or both at the same time.

But how? Can you be more specific? i.e. in what way is it a hassle right now, and how exactly would the proposed change alleviate it?

(In reply to Nate Graham from comment #8)
> But how? Can you be more specific? i.e. in what way is it a hassle right
> now, and how exactly would the proposed change alleviate it?

With the default icon size + 1080P screen + Default scaling (or 100%, which I'm using), it's easy to just eyeball the grid.

However, when dealing with the only area in which its main feature is its "customizable placements", with 4K/8K/16K resolution, low percentage of screen scaling, and/or small icons; although it might not be noticeable with short usage, as you keep dropping files in undesired placements, it becomes increasingly annoying to deal with day-by-day, which will cause the average user who cares about organizing desktop files/folders to inevitably just go back to bigger icons at the cost of screen space.

The same applies to a Steam Deck that has too many game shortcuts so the user had to set icons to small, making it hard to adjust placement in its small screen.

So this "grid visualizer" is my proposal to help the users to place files correctly at first try with ease, which not only lessens the stress, but also makes small icon/scaling/resolution settings more appealing than they usually are for those who like organizing the desktop).

I guess it boils down to: regardless of how big icons are or what the screen resolution or scale factor is, why do you need to care about seeing the grid? Icons snap to invisible grid cells anyway when you drop them. I'm failing to understand what's wrong or problematic for the status quo.

(In reply to Nate Graham from comment #10)
> I guess it boils down to: regardless of how big icons are or what the screen
> resolution or scale factor is, why do you need to care about seeing the
> grid? Icons snap to invisible grid cells anyway when you drop them. I'm
> failing to understand what's wrong or problematic for the status quo.

The Desktop is the only area that organization relies fully on placement with the mouse and the user's vision, so ideally you would want to get the placement right the first try and move on, especially with multiple files/folders.

An alternate solution would be to make the cursor go from center-of-grid to center-of-grid when dragging files/folders. But I hate this one.

This request is for users who actively wants a very small icon size while maintaining precision in order to not be frustrated with misplacements.

I don't think it enters in conflict with the request of Bug 496004

As a side effect, it would make very small icons/scaling as attractive as the "normal" sizes, since constant misplacements during organization won't be as common.

I came to the realization that the grid is not useful for these situations when compared to a simple highlight for items.

Bug 495067 is more simple and adequate.