GNOME Bugzilla – Bug 149847
Desktop icons not moving correctly when top dock resizes
Last modified: 2010-07-10 12:41:28 UTC
1. Launch GOK 2. Configure the GOK window to be a top dock 3. Note that the desktop icons have moved down some to get out of the way of the GOK window, but not enough out of the way (the top of the "This Computer" icon is cut off) 4. Select the Compose keyboard in GOK 5. Note that the desktop icons have moved further down to get out of the way of the expanded GOK window, but now both "This Computer" and also "Documents" are complely obscured. 6. Select the Launch keyboard in GOK (only two rows by default) 7. Note that the desktop icons have now moved up a bit, and only the very top of the "This Computer" icon is obscured. 8. Bring up an application (e.g. gedit) and place its window just underneath the GOK window. Go through a bunch of GOK keyboards (e.g. "Activate", "Launch"), and note that this applications' window accurately tracks the resizing. This suggest the bug is (mostly) in Nautilus and not GOK. Turns out it doesn't track correctly with "Compose". Will file a GOK but for that...
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Is this still an issue for recent Nautilus/GOK combinations? If so, I suppose that there are bugs wrt GOK/"_NET_WORKAREA". Nautiluses uses the workarea to determine its margins. If you have some time to debug Nautilus, you may dive into src/file-manager/fm-desktop-icon-view.c and check whether con_container_set_workarea behaves as expected.
Quiet a dumb issue. Confirming.
Created attachment 52848 [details] [review] Proposed patch I've also submitted this patch to nautilus-list [1] for review. [1] http://mail.gnome.org/archives/nautilus-list/2005-September/msg00211.html
Comment on attachment 52848 [details] [review] Proposed patch Alex review and Mannys response from the list: > Thats not right. Some places treat the margins as canvas units already I wasn't aware of these horrible inconsistencies, sorry. > Furthermore, the margins should be in pixels, since they are in pixels. > When the zoom changes the margin in pixels doesn't change, but the > margin in canvas units does. Oh, that's what these obscure canvas units are all about :D. I didn't closely investigate it and thought this would just be some obscure factor like the PANGO 1024 #define. > A better fix would be to always correctly treat ->*_margin as in pixel > coordinates. Surprisingly, that doesn't fix it. The icons are now layed out extremely tight to the canvas top-left edge. The whole icon container code is quiet confusing, and a mixture of #defines and externally set margins. The layout code for instance does not do x+=left_margin and y+=top_margin before laying out, resulting in a top-left layout with double right/bottom margins. Also, lay_down_icons_tblr is extremely tied to the desktop, which is reflected by DESKTOP_PAD_HORIZONTAL and DESKTOP_PAD_VERTICAL defines it contains. The bitrotten icon container really deserves an in-depth investigation.
Updating version to 2.13. Chances are quite good that we get a patch similar to [1] into 2.14. Milestoning to 2.14. [1] http://mail.gnome.org/archives/nautilus-list/2006-February/msg00098.html
Apologies for spam-- marking AP3 to reflect accessibility impact.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
I may be at deep water here but resizing the gnome-panel moves the icons on the desktop correctly (in nautilus 2.30). Is that what this bug is about or have I missed something?
It seems Alexander committed a fix for this: http://mail.gnome.org/archives/nautilus-list/2006-February/msg00130.html "I commited the attached patch. I verified that it at lest fixed the top icon moving wrongly when using != 100% default zoom and changing the size of the top panel." So, let's close this as OBSOLETE. Feel free to reopen the bug if it's still an issue.