Good morning, every time I do the right button on any file send to -> recipient (thunderbird) automatically the function creates in ~ / .local / share / applications a file userapp-Recipient-CVQ0AZ.desktop. This event generates in the menu "open with" many entries with (thunderbird). you can find this error here http://xfce.10915.n7.nabble.com/send-to-td48999.html still here https://www.archlinux.it/forum/viewtopic.php?f=13&t=22610#p183197 regards
I confirm I can reproduce the bug.
Hi Distribution: Ubuntu 18.04.1 LTS Thunar Version: 1.6.15 Same here. Executing /usr/lib/x86_64-linux-gnu/Thunar/thunar-sendto-email <filename>, directly. Works. (no files will be added) @archlinux83 your link is not working (https://www.archlinux.it/forum/viewtopic.php?f=13&t=22610#p183197)
Steps to Reproduce: 1. Start Thunar 2. Sent to recipient 4. ls ~/.local/share/applications/userapp-* /home/{user}/.local/share/applications/userapp-Recipient-S86BOZ.desktop 4. rm ~/.local/share/applications/userapp-* 5. Sent to recipient again 6. ls ~/.local/share/applications/userapp-* <empty> 7. Close Thunar 8. Start Thunar 9. Sent to recipient, once again 10. ls ~/.local/share/applications/userapp-* /home/{user}/.local/share/applications/userapp-Recipient-7H2MOZ.desktop
(In reply to brunnenschacht.eins from comment #2) > Hi > > Distribution: Ubuntu 18.04.1 LTS > Thunar Version: 1.6.15 > > Same here. > > Executing /usr/lib/x86_64-linux-gnu/Thunar/thunar-sendto-email <filename>, > directly. Works. (no files will be added) > > @archlinux83 your link is not working > (https://www.archlinux.it/forum/viewtopic.php?f=13&t=22610#p183197) @archlinux83 link works again
Created attachment 7994 Ugly patch Helpers are inserted into the context submenu at thunar_launcher_sendto_idle:1830. When activated, the call chain is thunar_launcher_action_open -> thunar_launcher_open_paths -> thunar_g_app_info_launch. That last function unconditionally calls g_app_info_set_as_last_used_for_type, which creates the unwanted desktop files described in this bug report. A flag could be passed down the call chain, e.g. update_last_used, but thunar_launcher_open_paths is passed as parameter to g_hash_table_foreach, so we can't change its signature. The attached patch is very very ugly hack, it fixes the misbehavior but also demonstrates an approach that I'm not going to merge. I could create a wrapper function to thunar_launcher_open_paths that always passes update_last_used as FALSE, but I'm also not sure of the elegance of this approach either.
Created attachment 8728 skip-app-info-update-wrapper.diff (In reply to Andre Miranda from comment #5) > I could create a wrapper function to thunar_launcher_open_paths that always > passes update_last_used as FALSE, but I'm also not sure of the elegance of > this approach either. The attached diff implements this suggestion, which is even more ugly and much more convoluted.
Created attachment 8730 skip-app-info-update.diff Ugly patch updated to recent changes made to thunar_g_app_info_launch. Still ugly but I can't think of a better solution.
I did a quick test and can confirm that skip-app-info-update.diff fixes the bug.
(In reply to Andre Miranda from comment #7) > Still ugly but I can't think of a better solution. Nah, it's not to bad. Think we ship alot of code which smells worse :D The patch works fine for me ! ... did not even know that it is possible to use "g_object_set_data" using foreign data tags :) > g_object_set_data (G_OBJECT (lp->data), "skip-app-info-update", GUINT_TO_POINTER (1)); Think you as well can pass NULL instead of GUINT_TO_POINTER (1) "g_object_get_data" still should find the data (even though it is NULL now)
(In reply to alexxcons from comment #9) > did not even know that it is possible to > use "g_object_set_data" using foreign data tags :) I could have used a quark, but I wanted to keep it simple. > Think you as well can pass NULL instead of GUINT_TO_POINTER (1) > "g_object_get_data" still should find the data (even though it is NULL now) That's just a lousy way to set a flag, passing NULL how can we know the flag was set or not?
(In reply to Andre Miranda from comment #10) > > Think you as well can pass NULL instead of GUINT_TO_POINTER (1) > > "g_object_get_data" still should find the data (even though it is NULL now) > That's just a lousy way to set a flag, passing NULL how can we know the flag > was set or not? Ugh, sorry I was wrong ... g_object_get_data returns the pointer to data .. true, than data NULL cannot be distinguished from NULL.
Andre Miranda referenced this bugreport in commit 9c87733c03079fdf7b6de5cb5ded4ae10f22f0dd Do not register "send to" as last used app (Bug #14118) https://git.xfce.org/xfce/thunar/commit?id=9c87733c03079fdf7b6de5cb5ded4ae10f22f0dd
Andre Miranda referenced this bugreport in commit 06c0e3eb10dc72dcea072926d5fbbe9936cf5a3e Do not register "send to" as last used app (Bug #14118) https://git.xfce.org/xfce/thunar/commit?id=06c0e3eb10dc72dcea072926d5fbbe9936cf5a3e