© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Yes, it would override the default action for that shortcut. I'm sorry that I didn't make it clear.
I suggested using Ctrl + F, which would override the default action, because people commonly associate this shortcut with a search function, and non-recursive search in current working directory still can be performed in a another way so we don't lose functionality. However, we don't necessarily have to use Ctrl + F for that custom action. If you're personally against this change or there is a concern that using an existing shortcut for something different will cause too much controversy among Thunar users, who are used to the current state of things, we could use different unused shortcut, such as Ctrl + Shift + F. My main idea here is to make recursive search more accessible and the actual shortcut that would be used for this is a secondary matter for me as long as it stays intuitive and easy to press with one hand.
As for the unique identifier requirement - if I am not mistaken, it should be possible to create unique identifiers for custom actions provided by Xubuntu, by modifying
https:/
I have attached the diff file that demonstrates how uca.xml.in could be altered. After hardcoding these unique identifiers it would become possible to create /etc/xdg/
In case of doubt if assigning the same shortcut (F4) to two different custom actions rather than one could and should be done - IMO this is needed because one custom action is responsible for opening the terminal when folder is selected or nothing is selected at all. The second custom action is responsible for opening the terminal when a file is selected. Assigning F4 shortcut to only one of these actions will result in the inability to open the terminal with a shortcut in one of the above situations.
Although the graphical editor does not allow you to assign one shortcut to two different actions, it's still possible to do this by editing accels.scm and doing so doesn't seem to cause any conflicts in this particular case.