Re: [PATCH] Improve icon container size calculation

[Federico Mena Quintero <federico ximian com>]

On Wed, 2006-02-22 at 23:35 +0100, Christian Neumair wrote:

> The original motivation was that I hoped to be able to easily fix the
> problems reported by Martin where icons randomly jumped around
> (reproducible when pressing ctrl-R).

I think this is just hysteresis due to this:

	1. you turn off "keep aligned"

	2. you move an icon to a position that is not snapped; the 
	   metadata gets saved to your exact position

	3. you turn on "keep aligned" - the icon snaps

	4. you reload - the icon goes back to where you had placed it

It *may* be that the metadata is not getting updated after (3), but I'm
not sure.

I'm claiming that it is hysteresis, and not the snapping code, because
just today I was debugging some problems with volume icons on totally
new home directories (i.e. with no previous metadata), and I ran into
the "hitting C-r moves my icons" bug.

> I'm not sure what the best further steps are, we could
> a) rework some of the grid logic to maybe have a more fine-grained grid.
> Sounds reasonable. IIRC, Sebastien Bacher also requested that the drop
> grid (i.e. the tight one) matches the normal wise grid used in this
> case.

The placement grid is buggy.  It doesn't take into account
DESKTOP_PAD_{HORIZONTAL,VERTICAL}.  (And how are those different from
container->details->left_margin, etc?  This is so convoluted...)

> b) replace the NAUTILUS_IS_DESKTOP_ICON_FILE check in
> fm_icon_view_add_file with has_volume || has_drive.

See the patch I just sent to the list.  You could think that the bug is
the test for NAUTILUS_IS_DESKTOP_ICON_FILE(), but I think we just had an
evil bug of mine in finish_adding_new_icons().

> c) revert the last patch which removed the usage of a tight layout for
> semi positioned icons. Worst option IMHO.

I think that patch was correct; it needs to be consistent with the way
the desktop is created, which is with a non-tight layout.

> Also note that icon_set_position could need some love, it doesn't really
> clip the icon into the visible area, because it doesn't subtract the
> borders.

Let's reduce the number places where the coordinates get frobbed.  The
right behavior for icon_set_position(), I think, is to *not* touch the
coordinates it gets passed.  The calling code should have figured out
the correct and final coordinates already.