GNOME Bugzilla – Bug 314137
'open folder' icon never reverts to closed after window is closed
Last modified: 2013-03-25 12:12:02 UTC
With the latest HEAD builds, if I click on a folder on my desktop, I get the 'folder is open' icon and the folder opens. Good so far. I then close the folder, but the icon stays 'open'. The only way to get the folder to revert to 'closed' is to restart nautilus. Tentatively marking a showstopper, just because it is so visible.
I'd really like to know what Lil' Luis did to his box to get this bug. Maybe you could printf-debug libnautilus-private/nautilus-icon-container.c:nautilus_icon_container_update_icon by adding a g_warning ("got pixbuf icon request: %s", icon_name); statement right before the nautilus_icon_factory_get_pixbuf_for_icon statement, telling us the output when opening/closing an (empty) folder that is on the desktop.
Oh, and if you don't know how to pipe Nautilus stdout into a terminal, consult [1]. In short: Open a terminal, gnome-session-remove nautilus, and enter NAUTILUS_DEBUG=1 nautilus. [1] http://live.gnome.org/Nautilus#CommonProblems
Luis?
Sorry, was traveling. I'll try to duplicate now.
14:53:33 <luis> Manny: at any rate, I can't duplicate the bug anymore with distro 2.12 (I had been seeing it with jhbuilt 2.11.9x) 14:53:41 <luis> Manny: so I guess it should just be closed 14:53:50 <luis> sorry I couldn't get more useful information :/
Normally this works fine for me, but for some reason it stopped working for me today. I'm adding the debug statement and recompiling to see if I can reproduce the issue. --- I applied the following patch, and followed the instructions regarding removing nautilus from the session and then starting it in a terminal with the debug env variable set. I do not get any warnings upon opening and closing the folder. Index: nautilus/libnautilus-private/nautilus-icon-container.c =================================================================== RCS file: /cvs/gnome/nautilus/libnautilus-private/nautilus-icon-container.c,v retrieving revision 1.396 diff -u -r1.396 nautilus-icon-container.c --- nautilus/libnautilus-private/nautilus-icon-container.c 1 Sep 2005 09:29:57 -0000 1.396 +++ nautilus/libnautilus-private/nautilus-icon-container.c 18 Sep 2005 18:59:02 -0000 @@ -5050,6 +5050,8 @@ if (icon == details->drop_target) { modifier = "accept"; } + + g_warning ("got pixbuf icon request: %s", icon_name); pixbuf = nautilus_icon_factory_get_pixbuf_for_icon (icon_name,
Thanks for your efforts Brent! I would like you to take a closer look at nautilus_icon_container_update_icon, by similar means. Does it get called when hovering? Also, it would be interesting whether nautilus-icon-dnd.c:set_drop_target is called and what codepath exactly is taken. You can find out this with code like: g_message ("old icon: %p, new icon: %p", container->details->drop_target, icon); that way, we can see whether the drop target is unset correctly when set_drop_target is called. When hovering the icon, it should return two identical addresses, when leaving the drop target, it should instead return an address > 0 for old_icon and 0 for icon.
Sorry, please ignore comment 7. This is not a DND issue.
Brent: I'd like you to debug nautilus_file_set_has_open_window in a similar way, i.e. by adding g_message ("setting has open window: %s - bef. %d, after %d", file->details->uri, file->details->has_open_window, has_open_window);
Did you mean file->details->activation_uri or file->details->relative_uri?
using relative URI should be enough. It's just important to identify whether the file belonging to the open window is affected.
Brent and me had quiet an extensive debugging session. All we found out is that the destroy method is called for the spatial window and spatial_window_destroyed_callback, but the finalize function is not called. We were unable to find out where a potential additional ref came from, even with the g_trap_object_ref magic :/.
There is no spacial mode anymore. I assume this is obsolete.