Am Donnerstag, den 23.02.2006, 21:03 -0600 schrieb Federico Mena
Quintero:
> 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.
find_empty_location returns FALSE for grid locations that seem to be
totally fine to the user.
This is not a problem when the initial desktop layout is calculated,
because the positioned icons are not checked for having a free placement
grid location, and when the desktop is loaded, no positioned icons are
around ($HOME wasn't loaded yet). Therefore, the virtually merged in
desktop, trash and volume icons are assigned a position before their
non-lazy counterparts.
This problem can easily be proven by moving all the icons away from the
top-left corner except for the NAUTILUS_DESKTOP_FILE items, laying them
out next to each other with a "natural" spacing. At 75 percent zoom,
after reloading they're totally shuffled, i.e. the icons positioned
later are moved down as they're considered to overlap.
A part of it may be that we use a column size detection algorithm in
lay_down_icons_tblr using max_icon_width + DESKTOP_PAD_HORIZONTAL, while
the grid doesn't take this into account and just uses SNAP_SIZE_X. Maybe
we should just fix the max. icon width in canvas units and use it for
layout, but the nerds will hate us for not being able to scale their
icons to 500 px, and the file preview problems I'll explain below
remain, even if we could auto-switch to manual layout when people have
weird icon sizes.
> > 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...)
DESKTOP_PAD_HORIZONTAL/VERTICAL are taken into account in
canvas_position_to_grid_position. They are the extra margins Nautilus
adds to the desktop. Other containers use CONTAINER_PAD_FOO.
The extra margins (top_margin etc.) are set incorporating the
"_NET_WORKAREA" information from the X server. With the current layout
code they are not considered.
>
> > 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().
There is definitly more than one bug involved. One problem is that the
icon container code is used for many different things (fixed/manual/auto
layout) without a clear distinction wrt the function names and use
cases. I plan to hack on an additional tiny icon view with text besides
icons, I think Windows has a "List View" that works like that, and the
Mac Finder IMHO also uses columns with small icons, so this problem will
even get more pressurizing.
> > 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.
Yes, I also agree it is correct.
Today I played around with MacOS X and its semantics aren't perfect
either: When an icon has no other icons besides it (it is far away from
others), a bigger grid is used, and the icon gets snapped to around 100
px grid width with the default size but you're allowed to use a tight
drag snapping when you drag another icon right next to an existing icon.
That code might have been added the layout of very crowded desktops.
I very much like the Windows XP semantics here, where each icon has
enough space and is equally large, but this isn't feasible with
previewed PDF files. They seem to occupy extremly much space compared to
other icons and make the desktop extremely cluttered, mine often looks
like "The Settlers II".
I'm really not sure whether PDF preview orgies like on Ubuntu Dapper are
a good idea, while the number of image-related icons in the theme
generally get reduced. I think adding preview tooltips instead is way
better, but I think Alex disagreed on that some time ago.
> > 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.
Yes, I agree. We're doing desktop layout code in many places, though,
and I'm not sure whether we have enough time to shift all the sanity
checking. Getting the whole beast really cleaned up requires lots of
tedious hacking and many edge cases to consider.
--
Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil