Changing to "old" target milestone for all bugs laying around with no milestone set.

Just thinking we could do something simple about this, so here is a
suggestion:

* Put all mounts to top right corner of the desktop.
* Put trash on bottom right (of course remember position if one 
  moves it)
* Default launchers and other stuff to topleft corner of the screen

This way, it would be at least a bit more clean organization. I dont
think we need any preferences for this, though I can hear some freaked
out screaming about how someone wants to control where stuff goes :-)
But something like this as the default behaviour would definitely
clear things up and make things more simple. The "oh, where is the
device I mounted..? doh, under the Home icon!" -stuff is just confusing.

I think the behavior tigert describes here should be the default
cleanup behavior on the desktop :)

changing to future, adding gnome2 and usability keywords.

Also it would be nice if the desktop used seperate metadata for icon
position and icon stretching. That way you could use manual layout for
the desktop directory in the file manager without having icons that
are stretched on the desktop stretched in the icon view, or have icons
places all wierd. I have another bug for this open, but just thought
i'd mention it here too.

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

Would it be possible even, to make an option to lock a device icon on
the desktop(even when not mounted) sort of what is possible in KDE and
the only way in Windoze... Then only the title and possible the icon
for the device should be changed on mount.
This would make it real easy to arrange devices so that you CD-ROM is
always icon number three from top right and the CD-RW is right below
that on, etc... Hope you get my point... Even automounting of a device
when double-clicking the icon would be great!

I tend to miss dependencies and blocks, so I'll add a comment here to
look at bug 95648 (which is about the cd-rom icon forgetting its
position).

This bug, in combo with bug 95648, seems like a "cosmetic bug of
particularly high visibility", so I'm setting priority to high.

Now, in regards to tigerts suggestions:

It may be important to note that having icons near corners other than
the top left is potentially problematic when the screen resolution is
changed (see bug 47943).  I don't know how difficult this may be to
fix (bug 41670, which is nearly identical to tigert's suggestion,
claimed this problem was already fixed--though if it was, it has since
been broken again).  A possible solution to this may be using negative
locations (again, I've talked about this more in 47943).

Note that I believe the snap-to-grid feature that I'm trying to write
(see bug 41671 and note my disclaimers) should naturally allow for
icons in the top-right and bottom-right corners (bottom-left corner
may be problematic, unless, perhaps, I can come up with some
workaround--such as the one I can think of if negative locations were
used to keep track of icons near corners other than the top left)).

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

Changing the Severity from enhancement -> normal, since it seems like
a flat out bug.

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

This still happens with 2.7.92, Now that the new hotness g-v-m is upon us, and
automagical mounting of devices is becomming commonplace, this should seriously
be looked at for the next release (2.9). I will add a new screenshot
illustrating the behaviour. 

Created attachment 31279 [details]
This is an image of poor icon placement in action. 

This is a screenshot of the placement of the cdrom icon after mnounting
automatically. (If it is of any relevance, "keep aligned" is set for my
desktop.

still here with 2.9.90, that would be nice to get that fixed for 2.10 if
possible ...

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

Can the device icons be turned off altogether as an option? 

I run submount and they become really nasty. The icons always stick on the
desktop and have no useful functions. And they confuse fresh ex-windows users.  

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

@sdiconov: You're probably interested in the gconf key
/apps/nautilus/desktop/volumes_visible.

Is it really that hard to programatically call 'clean up by name' when
displaying a new desktop icon, that it's taking 4 years to correct?

Mace: By auto-cleaning up by name, you'd seriously break users' layout. I rather
suppose we ensure that the old icon position metadata for the newly mounted
device is ignored and instead a new empty position determined if the old
position overlaps with another icon on the desktop.

The relevant layout code is in reload_icon_positions. If we are on the desktop
and have_stored_position is TRUE, we may only want to restore the metadata
position it if it doesn't interfere with another (already displayed) item. This
could be done by calling nautilus_icon_container_get_is_desktop and
eel_canvas_get_item_at for the upper and lower icon boundary coordinates. The
trick is probably that this should only be done for volumes. I suppose it would
be ugly, but we could get the metadata name and check whether it ends in
".volume" - or we'd have to ask FMIconView whether a particular NautilusIcon has
a volume associated with it, maybe by changing the NautilusIconContainer API and
adding a NautilusIconIsVolume callback or something.

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

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

You can also make this bug show up by going into a terminal and typing:

 touch hello1
 rm hello1
 touch hello2
 touch hello1

So it's not just limited to volumes. Basically, when restoring a desktop icon
that has a remembered size/position, check for conflicts and throw away the
remembered position if there is a conflict.

Bumping up version to 2.11.x.

I am not sure whether it is another bug or it is the result of this one.

When two icons overlap and are at the exactly same position (pixel to pixel) if
one navigates through desktop icons with keyboard and marks one of the
overlaping icons - there is no way you can unfocus them by using your keyboard.

Way to reporoduce:

Get two overlapping icons.
Select one of them (let's call it Icon1 and the overlaping icon - Icon2).
Click any arrow key.
Icon2 is selected.
Click any arrow key.
Icon1 is selected.
Click any arrow key.
Icon2 is selected.
...

No way to select another icon on your desktop without falling back to your mouse.

Created attachment 50703 [details] [review]
Proposed patch

I've also submitted the patch to the nautilus mailing list [1] for review.

[1] http://mail.gnome.org/archives/nautilus-list/2005-August/msg00135.html

Ignas: That's another issue. We probably shouldn't snap to grid when dropping
where another icon is already located.

I commited the patch, but there is still a problem on startup, and when files
get resurrected. 

See http://mail.gnome.org/archives/nautilus-list/2005-September/msg00147.html
for details.

Assigning to myself; I'm working on this.

This is actually three different bugs:

Bug 1:

  cd ~/Desktop
  touch foo       <- icon appears
  right-click on foo
  select "Delete" instead of "Move to trash" <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

Bug 2:

  cd ~/Desktop
  touch foo       <- icon appears
  rm foo          <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

Bug 3:

  the CD-ROM thing

I have a fix for (1); will attach it immediately.  I'm working on (2) and (3).

Created attachment 54302 [details] [review]
gnome-vfs2-115467-remove-deleted-file-metadata.diff

Patch for Bug (1) above.  This is actually a gnome-vfs problem.

Created attachment 54448 [details] [review]
nautilus-45953-dont-overlap-volume-icons.diff

Actually, the fix for case (3) above is quite simple.  Manny already had code
to distinguish icons which have a stored position, but which we don't want to
overlap.  I just changed the tests a bit so that even if an icon has a stored
position (like a volume icon), it will be put in the semi_position_icons list
to make sure that there are no overlaps.

This fixes the "volume icons overlap" bug for me, and it's the patch I'll use
for our Novell package.  I'm just missing case (2).

I commited both patches (with a coding style change).

Thanks, Alex :)

So, to summarize, the only thing that remains is case 2 from comment #30.  I'll
rename the bug to indicate this.

Any idea of how Nautilus finds out that a file disappeared on the outside?  I
set breakpoints in the obvious functions in nautilus-monitor, but they never
triggered...

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

The touch1/rm/touch2/touch1 flaw is still present in CVS HEAD.  I'll take a look at why.

nautilus-monitor is not removing the metadata in the case caused by rm or any other non-Nautilus driven action.

Patch submitted to the nautilus list.

Created attachment 77876 [details] [review]
Patch to handle external removes

Commited. 

Gene, you are my hero.  I couldn't find the right place to put that code.  Thanks for fixing this!

Of:
https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/12454/comments/9

"I have encounter this problem again in Hardy Beta."

Bug:
https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/12454

Confirming. Reopen or open a new bug?

There's already new report on the issue (bug 531019) so I guess we can use it instead of reopening this one.

This bug:

  touch foo       <- icon appears
  rm foo          <- icon disappears
  touch bar       <- icon appears where foo used to be
  touch foo       <- icon appears, overlapping bar

is still here (2.28.1). It's super annoying.