GNOME Bugzilla – Bug 765601
icons overlapping on desktop's left upper corner
Last modified: 2016-10-07 17:52:25 UTC
Created attachment 326751 [details] bad placed icons under linux Dear maintainer I have installed gnome-3.18.2 under freebsd-10.3 and under debian sid. In both cases I have noticed that when desktop-icons are showned those are overlapping in desktop's left top screen. If I have arranged them by name from desktop icons position's are ok. I have noticed also that under user's home ./config/nautilus/desktop-metadata has changed between those two cases. When icons positions were ok desktop-metadata content was [directory] nautilus-icon-view-keep-aligned=true nautilus-desktop-icon-size=64 nautilus-icon-view-layout-timestamp=1461653360 [trash] nautilus-icon-position=40,714 icon-scale=1 nautilus-icon-position-timestamp=1461653360 [home] nautilus-icon-position=40,14 icon-scale=1 nautilus-icon-position-timestamp=1461653360 When icons posistions were not ok all icons-positions were set to 40,0 something like: [directory] nautilus-icon-view-keep-aligned=true nautilus-desktop-icon-size=64 nautilus-icon-view-layout-timestamp=1461653360 [trash] nautilus-icon-position=40,0 icon-scale=1 nautilus-icon-position-timestamp=1461653360 [home] nautilus-icon-position=40,0 icon-scale=1 nautilus-icon-position-timestamp=1461653360 Adding a good desktop-metadata file under ./config/nautilus dir leads to correct icons positions. Bad icons position image under linux is in first attachement. Same behaviour is under freebsd too for gnome-3.18.
In both cases gvfs version implied is 1.26.X
Both cases means in freebsd and in linux
Thanks for your bugreport though I don't think this is related to GVfs - reassigning to Nautilus.
As I searched on internet icons positions are stored as gvfs metadata. http://askubuntu.com/questions/573348/desktop-icon-position-programmatically-access-and-manipulate I don't know more but I will try to test if it's really gvfs related. Thank you.
Positions for some special files are obviously stored in some custom nautilus database in ./config/nautilus/desktop-metadata. But you are right that positions for regular files are stored in gvfs metadata databases. However metadata database is only storage, I suppose that wrong positions are written by nautilus, which I suppose is responsible for placing... Are the positions wrong after you restart the computer if you arrange them before?
(In reply to Ondrej Holy from comment #5) > Positions for some special files are obviously stored in some custom > nautilus database in ./config/nautilus/desktop-metadata. But you are right > that positions for regular files are stored in gvfs metadata databases. > However metadata database is only storage, I suppose that wrong positions > are written by nautilus, which I suppose is responsible for placing... > > Are the positions wrong after you restart the computer if you arrange them > before? Or it happens only for first time?
If I arrange them positions are ok after logout and relogin.
Do you have the "keep aligned" option marked in the right click context menu?
Yes, Keep aligned was marked when icons overlapped. After unmark it and mark again there positioned ok.
Created attachment 334511 [details] [review] Patch for discussion - this seems to sufficiently work around the issue for us
Review of attachment 334511 [details] [review]: ::: nautilus-3.21.91.orig/src/nautilus-canvas-container.c @@ +2041,3 @@ /* Check and see if we need to move to a new column */ + if (y != DESKTOP_PAD_VERTICAL && y + icon_height_for_bound_check > height && + height > 0 && total > 3) I'm still unsure about the general code here, so forgive my questions. Why this 3?
@ZhaoQiang: as the patch originated from you ( to my info ), can you please reply to Carlos?
(In reply to Carlos Soriano from comment #11) > Review of attachment 334511 [details] [review] [review]: > > ::: nautilus-3.21.91.orig/src/nautilus-canvas-container.c > @@ +2041,3 @@ > /* Check and see if we need to move to a new column */ > + if (y != DESKTOP_PAD_VERTICAL && y + > icon_height_for_bound_check > height && > + height > 0 && total > 3) > > I'm still unsure about the general code here, so forgive my questions. Why > this 3? Hi Carlos: In fact, I'm working to make the soluiton more generic now. :) "Total" ver here is nautilus desktop icon numbers. I use it to judge if the system is in first time boot to gnome desktop. This bug is caused of in this moment, current user don't have $HOME/.config/nautilus/desktop-metadata. nautilus have to detact the screen and do a auto arrange for all icons, but it do a wrong move to new icon arrange column. Main linux distributions don't have more than 3 icons in desktop, It can cover 90% of the scene. and I test it's really works. So, I set it.
Alright, I've been debugging this, since we see it on Ubuntu. I figured out that when this happens, 'height' is 1, instead of the actual height of the desktop. That messes up all of the following calculations. It's because, in the incorrect case, the size hasn't been allocated yet. There's a race condition going on - I don't see the bug every time. I didn't test this yet, but I wonder if returning from lay_down_icons_vertical_desktop if (!container->details->has_been_allocated) would work?
(In reply to Iain Lane from comment #14) > Alright, I've been debugging this, since we see it on Ubuntu. > > I figured out that when this happens, 'height' is 1, instead of the actual > height of the desktop. That messes up all of the following calculations. > > It's because, in the incorrect case, the size hasn't been allocated yet. > There's a race condition going on - I don't see the bug every time. > > I didn't test this yet, but I wonder if returning from > lay_down_icons_vertical_desktop if (!container->details->has_been_allocated) > would work? Do you mean the actual desktop window height is 1? We set the window height in nautilus_desktop_window_new, is that incorrect for you?
Created attachment 337164 [details] [review] nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet Sometimes we were trying to lay down icons before size_allocate had been run. When this has happened, gtk_widget_get_allocation returns 1×1 as our size. This messes up the algorithm and causes icons to be overlapping on the canvas. We fix this by noticing if we're called before size_allocate and then deferring icon layout until later on, after size_allocate has happened. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1611955
Created attachment 337166 [details] [review] Now with some missing style and code fixes
Review of attachment 337164 [details] [review]: I believe your code is actually the right solution. Doing this upper in the stack, in the desktop-canvas-view as I proposed, means the parent needs to know whether the child is allocated or not for "just sorting the icons", which is the responsibility of the canvas-container. So let's review this code: ::: src/nautilus-canvas-container.c @@ +141,3 @@ + GList *icons; + double start_y; +} SizeAllocateUserData; I'm fine having this in the priv @@ +1441,3 @@ + /* We can't get the right allocation if the size hasn't been allocated yet */ + g_assert (container->details->has_been_allocated); don't crash nautilus because the icons are wrong, instead g_warning. @@ +1950,3 @@ + /* We can't get the right allocation if the size hasn't been allocated yet */ + g_assert (container->details->has_been_allocated); ditto @@ +2141,3 @@ +static void +canvas_container_size_allocate_callback (GtkWidget *widget, we already have a handler for size_allocate, use that one. @@ +2165,3 @@ double start_y) { + if (!container->details->has_been_allocated) although this is the function that makes nautilus crash, we can go a little upper in the call stack, since this shouldn't have been reached already. So let's move this check with a comment to nautilus_canvas_container_sort? The comment can be along the lines of: "The clients of the container could want to reorganize the icons when the canvas is not allocated yet. This is the case of the desktop canvas view, where it might reorder the icons when it finish loading all the files" Then instead of connecting to any signal, you actually have a "needs_resort" in the private data. And actually, container_sort just redoes the layout with that set. So I think it will work just skipping the redo_layout in container_sort if !has_been_allocated because it will be resorted in the redo_layout in the next size_allocate. This will make the code much simpler and clearer.
Created attachment 337183 [details] [review] Latest version - directly skip code if we haven't been allocated. This is all called later on when the icons are laid out.
Review of attachment 337183 [details] [review]: Can you point to e0081be7cd in the commit message? Can you explain that this mostly happens in sessions that uses the desktop when starting the session, which easily triggers not having allocation but having all the files read already? ::: src/nautilus-canvas-container.c @@ +7847,3 @@ NautilusCanvasPosition position; + if (!container->details->has_been_allocated) can you add a comment here along the lines of: "the container will freeze the icons when allocated, since that calls freeze_icon once it does the relayout. This avoids freezing icons that needs re-position when the allocation is still not done, in order to avoid a wrong position for the icons"
Created attachment 337184 [details] [review] Thanks for the reviews, here's the latest version
Created attachment 337185 [details] [review] ...and the version for gnome-3-20
Review of attachment 337184 [details] [review]: Excellent patch, I think there is a typo, feel free to commit with that fixed: ::: src/nautilus-canvas-container.c @@ +7849,3 @@ + /* This early-exit avoids freezing the icons before they have been properly + * positioned, since we won't re-layout if auto_layout is TRUE. FALSE you mean?
(In reply to Carlos Soriano from comment #23) > Review of attachment 337184 [details] [review] [review]: > > Excellent patch, I think there is a typo, feel free to commit with that > fixed: > > ::: src/nautilus-canvas-container.c > @@ +7849,3 @@ > > + /* This early-exit avoids freezing the icons before they have been > properly > + * positioned, since we won't re-layout if auto_layout is TRUE. > > FALSE you mean? Yeah, sorry about that. I'm out the door in 1 minute though, so I'll do it tomorrow or you (or anyone) can fixup + push for me. Thanks!
Created attachment 337186 [details] [review] nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet Sometimes we were trying to lay down icons before size_allocate had been run. When this has happened, gtk_widget_get_allocation returns 1×1 as our size. This messes up the algorithm and causes icons to be overlapping on the canvas. This case happens when using Nautilus as the desktop in early-startup (e.g. from its XDG autostart file). It can happen that we have read the desktop files before the allocation has happened. We fix this by noticing if we're called before size_allocate and then deferring icon layout until later on, after size_allocate has happened. This behaviour was introduced in commit e0081be7cd65de6422529d831f7882009ce00a9d, which sorts and freezes the desktop in early-startup. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1611955
Comment on attachment 337186 [details] [review] nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet Thansk a lot Ian! Excellent work. Attachment 337186 [details] pushed as d82b5bb - nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet
Created attachment 337190 [details] [review] nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet Sometimes we were trying to lay down icons before size_allocate had been run. When this has happened, gtk_widget_get_allocation returns 1×1 as our size. This messes up the algorithm and causes icons to be overlapping on the canvas. This case happens when using Nautilus as the desktop in early-startup (e.g. from its XDG autostart file). It can happen that we have read the desktop files before the allocation has happened. We fix this by noticing if we're called before size_allocate and then deferring icon layout until later on, after size_allocate has happened. This behaviour was introduced in commit e0081be7cd65de6422529d831f7882009ce00a9d, which sorts and freezes the desktop in early-startup. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1611955
and for 3.20 Attachment 337190 [details] pushed as 4bd2be2 - nautilus-canvas: Don't lay down desktop icons if we haven't been allocated size yet