GNOME Bugzilla – Bug 601469
"Keep aligned" should have a snap to grid behaviour
Last modified: 2012-09-19 23:54:49 UTC
Created attachment 147438 [details] Spotify icon shows how icons aren't aligned by row, only by column. The empty file shows how desktop icon labels overlap other icons. Sorry if this is not the correct component. It relates to the "Keep Aligned" option on the GNOME desktop, reached by right-clicking empty space on the desktop. Currently when checked "Keep Aligned" makes sure the icon is in line with other icons of the same column. However it does not at present keep icons aligned by row, so to speak. One can place an icon wherever one wants, half-way between two other icons vertically, as long as it is in another column. So "Keep Aligned" should function much as the way Windows in most incarnations does: it should form a grid not just vertical columns, and force icons to be inside these. Spacing should also be relative so icons and labels don't overlap but that can be another bug. I'll attach an image to illustrate my points.
Changed the component and also found a number of bugs that this incorporates elements of (sorry). Leaving this open as it's an amalgamation of the other enhancements. Bug #530430 Bug #566479 Bug #129937 Bug #143311
Created attachment 151022 [details] [review] Desktop grid snap and overlapping icons possible fix It appears "keep aligned" has supported snapping icons for some time, but the grid spacing is too small. When the spacing is adjusted, the icons still overlap, and new icons / copied icons do not initially snap to the grid. This patch adjusts the spacing to something larger than a normal icon size so the grid looks nicer. The x-spacing would now be 130 and the y-spacing would be 104 (pixels). These numbers seemed to minimize overlap, and the icons line up both vertically and horizontally. The other part of this patch is to realign the icons every time an icon is moved. This automatically moves icons around to prevent stacking.
i confirm on Ubuntu 9.10 . Related to Bug #332298 ?
From my mail on the list: While I agree that in some cases the original snap values are to small I'm not sure just bumping them is the ideal solution. There are a few issues I see, first of all it doesn't take into account a different zoom factor. If you change the default zoom to 50% then your values are to large. Secondly, the large snap factor gives a lot of whitespace, meaning a lot less icons will be visible: http://www.gnome.org/~alexl/snap-to-sizes.png This is the top left corner of my desktop after clean up by name. Left is with your snap sizes, right is with original sizes. 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. Re set_icon_position part: 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().
Created attachment 154102 [details] [review] Revised Patch for Icon Overlap (Also posted on mailing list) This is a revised version of my patch, keeping the above comments in mind. Instead of using schedule_align_icons, this patch realigns the moved or added icons using a PlacementGrid. I also have made no changes to grid size because icons can be multiple sizes.
Thank you Bill for your time. how can we test your patch?
Tested Bill Smith's patch and can confirm that patch does what is stated, no icon overlap. However icon text still overlaps, and it definitely feels like the icons are doing kind of like they want, e.g. if you try to drop one where there is no place for it (unless it would overlap) it instead jumps to the end of the sorting. It's a huge improvement in one area, but it creates new problems. If you use ubuntu, testable patched packages for 9.10 should are available from me here: https://launchpad.net/~arand/+archive/ppa (nil safety included). I have to say, thumbs up to you Bill for looking into this!
Thanks for testing and commenting! The "jumping icon" issue is due to the function I used, find_empty_location, which finds an unoccupied icon location in the current column before looking in the next row. I think this behavior is fine for adding icons, but for moving icons I'm pretty sure it isn't what we want (as you found). Some alternatives: 1) Use align_icons, but this could move other icons around, which could be problematic. 2) Implement a new function to find an empty location that is more intuitive. I have considered doing this, though it might not be a trivial piece of work. I guess the question is - where do you want the icon to go when there's a collision? Personally, I don't know, and it would be nice to hear some opinions.
Here's where I have to say that Windows has it right. I can't remember exactly what it does (haven't used it in a while) but it behaves well. It'd be complicated but if there's some way of telling where the overlap is, whether it's on the sides or top and bottom, then you'd place the icon next to it in the former, and above or below it if the latter, if there's a clear space. If that makes sense. Thanks for working on this. In addition, what gets me is that the labels can overlap another icon, perhaps the labels need to be reformatted so they're not as long horizontally and instead when over-running.
I don't know about more recent versions of Windows (I only have XP right now), but I did some investigation on my XP partition. From what I can see, collisions work in _exactly_ the way align_icons would handle it. That is, when it can't find an icon position, it rearranges other icons to put the icon in the position it was dragged into. Even more interesting - it shifts the colliding icons downward by column first, then by row. I think I need to see how other desktop environments handle this (e.g. KDE, XFCE). For the overlapping text issue, the compact layout flag (I think that's the name) already does what you're suggesting. I set the "tight" flag to true in creating the grid, but if it is false, the amount of whitespace looks really bad. Perhaps I could decrease the horizontal snap size, but the grid would be all but non-existent. It seems to be about finding a balance between those parameters.
Created attachment 154341 [details] [review] Alternate patch for preventing overlap in moving icons This patch mimics the functionality of XFCE in that it refuses to move an icon if there is a collision. It is an alternative to the other methods I proposed. This only applies to moving icons directly on the desktop; adding icons uses find_empty_location as before. Ideally this would have the animation as with a bad drop target (move back to position), but I haven't figured that out yet.
Dear all, please see Bug 613111
I've been using The first version of the patch https://bugzilla.gnome.org/attachment.cgi?id=154102 for some time, and one of the main issues that I see with it is that the empty-finding function of it seems to use a different grid than the standard grid, used for example in the "arrange by name" action. Illustrative screenshots attached, first is a bunch of new created folders, which in the creation will apply the grid of the patch. Second is the grid when the "arrange by name" normal action is used. As visualised, the grid is different, and may end up in a rather inconsistent state, if you or example have arranged it by name once, and then start adding a number of new files, you'll end up with one set of icons using one grid, and another set using another grid size.
Created attachment 158827 [details] arranged from patch
Created attachment 158828 [details] arranged normal
Created attachment 158928 [details] [review] Newer variation of Keep Aligned patch Because of the "jumping" issue, I went back to align_icons for moving icons. I kept the icon adding method the same because it prevents a renaming issue and isn't as noticeable. I also turned on the "tighter layout" flag for the desktop (with no way to turn it off) to see how it may affect the text overlap. It should also be noted that the overlap is dependent on the text size. The snap sizes were increased as a test with this in mind.
I note two things: . GNOME 3 has been put back until March 2011, so we will be using GNOME 2 for a while yet. . The latest nautilus-icon-container sources in GIT have none of the patches suggested. What is the status of this bug - seriously probably the most noticeable deficiency in GNOME now? PLEASE can we have ONE of the solutions above (my preference is mix between Bill's patch here, and Gerhard Bräunlich's patch to add gconf keys (referenced in Bug 613111 amongst others)).
*** This bug has been marked as a duplicate of bug 472289 ***