After update to 1.6.9, Trash panel plugin is not working anymore (previous release it was ok). This plugin is installed, find /usr/local/lib/xfce4/panel/plugins | grep tpa /usr/local/lib/xfce4/panel/plugins/libthunar-tpa.so If I put file in .local/share/Trash/files/, there's no icon, except on desktop. I use gvfs 1.20.3
Ok, sorry for breaking it. I tested it, and it worked on my system and apparently for others (see bug #9513), but your configuration may be different from mine so it is quite possible the changes do not work as intended everywhere. Fixed for some, broken for others :-/ Since I cannot reproduce it, I need more information: What exactly is the problem, can you describe it in more detail? e.g. The plugin does not show the correct state, does have no icon, cannot be added to the panel? Does it appear in the process list? Does restarting the panel help (use xfce4-panel -r)?
(In reply to Harald Judt from comment #1) > Ok, sorry for breaking it. I tested it, and it worked on my system and > apparently for others (see bug #9513), but your configuration may be > different from mine so it is quite possible the changes do not work as > intended everywhere. Fixed for some, broken for others :-/ > > Since I cannot reproduce it, I need more information: > > What exactly is the problem, can you describe it in more detail? e.g. The > plugin does not show the correct state, does have no icon, cannot be added > to the panel? Does it appear in the process list? > > Does restarting the panel help (use xfce4-panel -r)? In fact, trash icon doesn't appear in shortcuts view, and in standard view I have only delete action, not move to trash. In previous release (1.6.8) I applied patch found in bug #11896, otherwise monitoring didn't work.
Ok, so the trash is not working at all. libthunar-tpa is only for xfce4-panel. If you quit thunar (thunar --quit, but please make sure it did really exit) and then restart it (thunar --daemon), does it work again? Is gvfsd-trash running?
I have excactly the same issue since 1.6.9. Running 'thunar --quit' makes trash reappear and work, however, this has to be repeated after every system start. And yes, gvfsd-trash is running all the time.
Created attachment 6254 trash-add-debugging-messages.patch Ok, let's try to narrow this down. Since restarting thunar fixes this, this still seems to be only a timing issue. The attached patch adds another two reloads, one after 10 seconds, another one after 15. So if that is what's wrong, then it should really fix it, because in 1.6.8, the reloads would also stop after 15 seconds. The patch also adds debugging statements, maybe they help to see what's going on. Can you please apply this patch and see if it helps, or if it does not help provide its output? I'm not sure where the output is written to on startup, maybe you have a $HOME/.xfce4-session.verbose-log or a $HOME/.xsession-errors. With that info, I could create a better patch.
Created attachment 6255 xfce4-session.verbose-log Unfortunately, the patch does not fix it for me. I am attaching the debugging statements.
Created attachment 6256 xfce4-session.verbose-log Attaching again as plain text. Sorry.
(In reply to Harald Judt from comment #5) > Created attachment 6254 > trash-add-debugging-messages.patch > > Ok, let's try to narrow this down. Since restarting thunar fixes this, this > still seems to be only a timing issue. > > The attached patch adds another two reloads, one after 10 seconds, another > one after 15. So if that is what's wrong, then it should really fix it, > because in 1.6.8, the reloads would also stop after 15 seconds. > > The patch also adds debugging statements, maybe they help to see what's > going on. > > Can you please apply this patch and see if it helps, or if it does not help > provide its output? I'm not sure where the output is written to on startup, > maybe you have a $HOME/.xfce4-session.verbose-log or a > $HOME/.xsession-errors. > > With that info, I could create a better patch. Same behaviour reported by Christian. If I kill Thunar's daemon and relaunches it, trash icon appears. With your patch, I got this message: Thunar trash file is not in cache, loading it. Thunar trash file loaded; scheduling reloads of trash file.
Created attachment 6257 xfce4-session log (under FreeBSD) My xfce4-session log under FreeBSD.
Created attachment 6258 revert-trash-session-client.patch Ok, unfortunately the xfce4-session logs do not show anything about thunar, so these messages are posted somewhere else it seems. This patch simply reverts the removal of the code in the session client. Please let me know if this restores the correct behaviour.
I applied the patch and recompiled, but still no joy. Also tried with a clean configuration.
Created attachment 6259 revert-fix-for-bug-9513.patch So the problem is with the patch which should fix #9513. Now the attached patch here should revert that patch for #9513. Could you please try this, just to be really sure it is what causes your problems?
That works. Normal behavior is restored. So the culprit is indeed commit 2d5567b2f6ae6223c8865547704797a5c785ec1f.
(In reply to Harald Judt from comment #12) > Created attachment 6259 > revert-fix-for-bug-9513.patch > > So the problem is with the patch which should fix #9513. Now the attached > patch here should revert that patch for #9513. Could you please try this, > just to be really sure it is what causes your problems? Yes, everything works fine.
Created attachment 6260 alternate-version-for-fixing-bug-9513.patch Thanks. I still haven't got a clue why this doesn't work on all systems, but here is another attempt to fix it. This patch (to be applied on thunar-1.6.9) does not do the reload in idle, but instead it sets up a thunar_file_watch, then does one reload. On my system, it fixes the bug too, and maybe it does so without wreaking havoc on your systems?
Unfortunately no. Trash is gone again and only direct delete action is available with the alternate patch.
(In reply to Harald Judt from comment #15) > Created attachment 6260 > alternate-version-for-fixing-bug-9513.patch > > Thanks. I still haven't got a clue why this doesn't work on all systems, but > here is another attempt to fix it. This patch (to be applied on > thunar-1.6.9) does not do the reload in idle, but instead it sets up a > thunar_file_watch, then does one reload. On my system, it fixes the bug too, > and maybe it does so without wreaking havoc on your systems? Like Christian
Thanks for testing. That's unfortunate. Maybe reloading the trash later, after the gui has been created, could work. But I will ask on #xfce-dev, maybe someone has a clue what's wrong or a better idea how to tackle this. BTW: Christian, do you use FreeBSD too?
(In reply to Harald Judt from comment #18) > BTW: Christian, do you use FreeBSD too? No, I use Gentoo.
Created attachment 6261 fix-trash-state-at-startup-bug-9513-and-11913.patch Here is another attempt, this should work properly. Please revert my original patch (use attachment #6259 , revert-fix-for-bug-9513.patch), then apply this one.
Created attachment 6262 reload-trash-bin-after-dbus-service-startup.patch Next, please apply this on top; For me it fixes the state of the trash panel plugin at startup.
(In reply to Harald Judt from comment #21) > Created attachment 6262 > reload-trash-bin-after-dbus-service-startup.patch > > Next, please apply this on top; For me it fixes the state of the trash panel > plugin at startup. No, icon is always missing.
Weird, to me it does not make sense why this shouldn't work. There must be some other reason. (In reply to duchateau.olivier from comment #8) > Same behaviour reported by Christian. If I kill Thunar's daemon and > relaunches it, trash icon appears. > With your patch, I got this message: > > Thunar trash file is not in cache, loading it. > Thunar trash file loaded; scheduling reloads of trash file. Can you please try to reproduce this again (preferably with the debugging patch), but this time kill gvfsd-trash beforehand too? thunar -q; killall gvfsd-trash; thunar This should hopefully result in the same behaviour as running thunar at session start and print the debugging statements with more information. BTW: How do you usually start thunar?
For me your last attempt (i.e. applying patches from comments #12, #20, and #21) works fine.
(In reply to Harald Judt from comment #23) > Weird, to me it does not make sense why this shouldn't work. There must be > some other reason. > > (In reply to duchateau.olivier from comment #8) > > Same behaviour reported by Christian. If I kill Thunar's daemon and > > relaunches it, trash icon appears. > > With your patch, I got this message: > > > > Thunar trash file is not in cache, loading it. > > Thunar trash file loaded; scheduling reloads of trash file. > > Can you please try to reproduce this again (preferably with the debugging > patch), but this time kill gvfsd-trash beforehand too? > > thunar -q; killall gvfsd-trash; thunar > > This should hopefully result in the same behaviour as running thunar at > session start and print the debugging statements with more information. > > BTW: How do you usually start thunar? Sorry Harald, I've found why your latest patches did not work, because I forgot to apply revert-fix-for-bug-9513.patch. As I'm working on 2 boxes at the same time, I tested Thunar with another version of gvfs (not available in your ports tree, in order to be sure it was not on my side). Thunar (daemon) is started by xinitrc file (provided by xfce4-session).
With patches #22, #21, and #12, when Thunar is open, CPU increases up to 100%. I will try to build with debug symbols.
*** Bug 11916 has been marked as a duplicate of this bug. ***
With all the idle reloads and glib/gtk signal handling, this probably results in a race. Thanks so far for testing and help with debugging. I will think about a different solution and upload a patch when I have one ready.
Just for reference, on my system I cannot reproduce the CPU load issue.
Created attachment 6270 file-reload-idle-gdk-threads.patch Here is another patch which would be an easy fix. Not sure if it will help or not, nevertheless worth a try. Apply on top of the other recent patches.
(In reply to Harald Judt from comment #30) > Created attachment 6270 > file-reload-idle-gdk-threads.patch > > Here is another patch which would be an easy fix. Not sure if it will help > or not, nevertheless worth a try. Apply on top of the other recent patches. It works fine :) Thanks.
Created attachment 6271 fix-gsourcefunc-in-file-reload-idle.patch Oh, so success this time! However, I suspect that only this part of the patch is necessary. The line that replaces g_idle_add with gdk_threads_idle_add might not be required and could even cause performance degradation. To be sure, please try again with this revised patch. It fixes the return value of thunar_file_reload, which should be gboolean not void because it is a GSourceFunc callback function. Probably that is what is causing the varying behaviour on different systems; some might treat the missing return value as true, others as false and react accordingly (repeated reloading vs reloading only once).
(In reply to Harald Judt from comment #32) > Created attachment 6271 > fix-gsourcefunc-in-file-reload-idle.patch > > Oh, so success this time! However, I suspect that only this part of the > patch is necessary. The line that replaces g_idle_add with > gdk_threads_idle_add might not be required and could even cause performance > degradation. > > To be sure, please try again with this revised patch. It fixes the return > value of thunar_file_reload, which should be gboolean not void because it is > a GSourceFunc callback function. Probably that is what is causing the > varying behaviour on different systems; some might treat the missing return > value as true, others as false and react accordingly (repeated reloading vs > reloading only once). Works fine!
No issues here either with patch from comment #32.
Created attachment 6272 thunar-file-reload-return-type.patch Ok, so finally there is a solution that works for everyone, that's good to know. Additionally, this will fix some other potential issues where reload in idle is used. Thank you for testing. I am curious though if the old solution as implemented in thunar-1.6.9 would now work together with the fixed file reload too. I'd prefer doing the once reloads at program (thunar daemon) start instead of every time a new widget or view is created. Could you please try this patch on top of thunar-1.6.9 (no other patches required) and see if the initial issues persist?
Ok, please forget my last comment. I've found that the original solution has other issues anyway.
Pushed patches to master: http://git.xfce.org/xfce/thunar/commit/?id=e3b65ff628499248dadfe7cbdb027e17b7db03c2 http://git.xfce.org/xfce/thunar/commit/?id=9bf051a0005cef3d661493a44e7de911868cf5e7 http://git.xfce.org/xfce/thunar/commit/?id=6010f71d865b624f5f58b81405764c4ce6b2afc4 I will leave this bug report open until the thunar-1.6.10 release, in case anyone else finds this and wants to try the patches.
1.6.10 has been released, closing.