Re: [PATCH] Desktop Icons with "Keep Aligned"
- From: Alexander Larsson <alexl redhat com>
- To: Bill Smith <snowmanam2 gmail com>
- Cc: nautilus-list <nautilus-list gnome org>
- Subject: Re: [PATCH] Desktop Icons with "Keep Aligned"
- Date: Wed, 20 Jan 2010 16:36:53 +0100
On Mon, 2010-01-18 at 19:20 -0500, Bill Smith wrote:
> For the zoom, however, this doesn't seem to be an issue. I tested my
> changes at a number of zoom levels, and the grid scales with each
> level.
> I searched through nautilus_icon_container.c, and it seems zoom is
> handled through the conversion of global coordinates (where snap size
> works) to pixel coordinates.
Cool, thats one less problem then.
> > Third, with multiple size icons in the same layout (stretched,
> > thumbnails, normal icons) increasing the snap size is risky as if
> some
> > icon is accidentally a tiny amount larger than the snap size we
> almost
> > double the size used for that icon. This can create large holes in
> the
> > layout.
>
> If the desired behavior of the desktop is to be a grid, I would think
> this is what we want. If we didn't allow massive icons to take up more
> grid space, the desktop would allow overlapping icons (or it wouldn't
> be
> aligned).
At some level we want it to be a grid. But for better or worse the
design of nautilus is such that icons are often of different sizes
(thumbnails, stretched icons, etc) and this is most often used on the
desktop. So, we better handle this as well as possible.
Now, if there is any form of grid any icon that is larger than the grid
will take up two grid cells. If the icon is just slightly larger than
the grid size then this looks sort of bad, and it looks increasingly
more bad as the grid size goes up.
Clearly there is no ideal rules here, and the layout "algorithms"
currently in use are obscure and hairy. We can tweak them a bit and hope
things get better for more people, but its kind of risky as we may cause
things to get worse for other users.
At some point we probably want to completely redo this. Then we could
split the manual positioning and the automatic positioning code paths
and do things a lot better i believe. Not a trivial piece of work
though.
> > This isn' right. icon_set_position is the really lowlevel
> positioning
> > function. The code tries to handle keep_aligned before changing the
> > position, obviously we're missing it somewhere, but forcing snapping
> > always (even after e.g. a relayout which uses icon_set_position())
> isn't
> > the right solution.
> >
> > In fact, isn't there a risk of infinite loops since align_icons()
> calls
> > icon_set_position().
>
> This was poor thinking on my part - using icon_set_position() could
> have
> many unintended consequences. It worked because I used
> schedule_align_icons instead of align_icons, though that probably had
> an
> infinite loop in idle cycles anyway. Looking at the higher level
> functions (e.g. nautilus_icon_container_move_icon()), I think the snap
> problem comes from the way icon alignment is handled when an icon is
> moved or added. I tried the following changes and it gave the same
> functionality:
>
> - In nautilus_icon_container_move_icon(), icon alignment is handled
> through snap_position(), but snap_position() snaps icons to the grid
> with no regard for other icons. I think this the true cause of the
> "stacked icons" issue. I propose replacing snap_position with
> schedule_align_icons(), and placing the statement after setting the
> icon
> position (to give a starting position to the icon).
Yeah, this is kind of lame. One wonders why enabling "keep aligned"
moves all icons so nobody overlaps, but then nothing even keeps on doing
this as icons change.
> - In nautilus_icon_container_add(), I can't find any reference to
> alignment in the current code. I propose adding schedule_align_icons()
> to the end of the function (because it should occur after the icon is
> fully created).
I think this kind of "lazy" fixup is gonna be problematic. We should
just do the snapping and aligning as each single icon is added or moved.
This means for instance that we always position the changing icon so
there is no stacking, rather than risking the general schedule_align
code moving some other icon to make place for the new icon or whatnot.
It also means we don't move stuff unnecessarily, avoiding the rename
issue you mention (we should have positioned it snapped before even
enabling the rename.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alexander larsson gmail com
He's an impetuous bohemian jungle king with a secret. She's a supernatural
extravagent Hell's Angel looking for love in all the wrong places. They fight
crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]