User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060413 Ubuntu/dapper Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060413 Ubuntu/dapper Firefox/1.5.0.1 right now when inside a mounted removable device's folder, if an unmount is done in the sidepane the folder is moved away from and removed from the path bar. However there are two situations when the folder is chdired away from only but it remains in the pathbar. 1) unmount done on the xfdesktop removable icon 2) removable device just removed from the slot without unmounting first Reproducible: Always
it's not the unmount actually but the removal of the mount point in case of hal-pmounted devices. If we're in a directory and it is removed by an external program the location bar does not get notified. thunar chdirs up a level but the dir stays there in the bar invalid. Similar to the solved http://bugzilla.xfce.org/show_bug.cgi?id=1686 one thing different is that when thunar removes it it also explictely feeds a remove event, not sure if it's related.
Hm, don't you use Gamin?
sure I use gamin :) unlike the shortcut model the buttons do not attach to the destroy signal of thunar file, dunno if that could be it. Anyway when removed from another thunar window the directory behaves nice, is deleted from the pathbar. Only when removed by an external application does it not sense it.
The ThunarLocationButtons container handles the "destroy" signal (via ThunarFileMonitor), so deleted folders are indeed removed from the pathbar (otherwise it wouldn't work when done from another Thunar window).
ok. if you cannot reproduce it I'll debug some more.
Indeed both the location bar and the file window connect to the file-destroyed signal. At least here, the first run is always the one in the location bar, thunar_location_buttons_file_destroyed(). This does not remove the last button as it is still the one marked as that of the current directory. After this thunar_location_buttons_set_current_directory() is called via the other callback to the destroy signal, thunar_window_current_directory_destroy(). This makes the active button be the parent of the destroyed dir, but the button stays there since it's removal did not happen in the first callback. This happens when the current thunar dir is removed from an external app. When the removal is done from another thunar window, the same sequence of callbacks happen, but thunar_location_buttons_file_destroyed() is called a second time too after that and it does remove the button this time.
Created attachment 548 Should do the trick then This patch should atleast work around the problem then. I need to take a closer look later to come up with a real solution for the issue.
the button callback is still called first. The two racing callbacks are not signalled from the same object or even with the same signal name (at least not directly, one is via changed on ThunarFile the other directly on the monitor), so maybe that's why connect after does not make a difference?
Created attachment 549 Next one Ah, I see the problem. This patch will reverse the "destroy" and "file-destroyed" invokation order. Tho, the solution is nowhere near perfect...
thanks, this makes it work.
plan to commit this one or thinking of another solution?
I don't know... I really don't like this solution, but on the other hand I don't know of a better one right now... I'll see to it during the weekend (hopefully)... in the meantime, feel free to include that patch for Xubuntu.
Created attachment 571 Nice one This patch is much nicer, tho I'm not yet convinced that it works properly in all situations. But since it doesn't work properly in all situations currently, we won't make it worse atleast. ;-) Can you try it?
Committed with revision 21893. 2006-05-29 Benedikt Meurer <benny@xfce.org> * thunar/thunar-location-button.c, thunar/thunar-location-buttons.c: Cleanup location buttons properly when a directory is unmounted or otherwise destroyed. Bug #1752.