Xfce Forum

zub

Member

Registered: 2023-01-18

Posts: 35

thunar custom actions as a package

I took the time to set up up some custom actions but it was time consuming to do by hand in the manner suggested.

I'd like to duplicate it across users and on different systems. I believe there is a config file(s) that can be copied to achieve this.

However, if I want to make a change later on, how to push the change to all locations it exists? Also it would be nice to share with others would might enjoy all this functionality. Would it be correct to call such a thing a "plugin"?

Could/should this be accomplished by git repo, package manager (in my case, pacman) or other means?

ToZ

Administrator

From: Canada

Registered: 2011-06-02

Posts: 11,485

Re: thunar custom actions as a package

This is an interesting suggestion and I think an opportunity for someone to create something specific to accomplish this. The way I see it, some wort of wrapper application that both allows you to check/uncheck custom actions to use (based on some sort of internal directory of available custom actions) as well as a design editor to allow you to create menu/submenu hierarchies.

It could potentially make sense to try to merge this directly into thunar as a plugin, but it could also work as a standalone app. There is this individual's work, (and newer project) which looks like a start that could be used or built upon. Or if you have some development skills, you could look at creating something new.

---

Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki  |  Community | Contribute ---

zub

Member

Registered: 2023-01-18

Posts: 35

Re: thunar custom actions as a package

Thanks for the response; the link you provided to the newer repo , Yann Büchau (nobodyinperson) / Thunar Plugins, looks like it is going in the same direction. I would be happy to use this if it were mature and already had community support. But unfortunately I lack the python skills to get it doing too much at the moment.

I wonder if there would be some way to dumb it down a bit to allow simpler features to be added more like they can be with the current interface?

The package currently comes with link.py which is a more full featured version of Thunar - Custom Actions > Create a symbolic link.

The python version is better because it prompts you to select a location for the link to reside rather than defaulting to same directory. I will keep the whole package for that function because it allows creating symlinks to system directories even while not using thunar as root.

But it has a drawback which is that I will never (at least, not any time soon) be able to create such a script. Whereas I *can* create the simple lines for which many examples are provided in the xfce docs. While the 141 lines of python is superior in the end, I will have to sit around and wait for others to create everything I want. Unless it would be possible to include all these simple bash lines in a python script? Until someone smarter comes along to do a better job.

nobodyinperson's older repo did helpfully remind me of where I had seen the configuration for these actions, which is
`~/.config/Thunar/uca.xml`. If it were a directory instead of a single file, it would be easy to include actions as separate files. And have thunar read them basically with `cat` or something. I guess it would be possible to write a shell script to generate the file from a directory. I think that might even be what nobodyinperson's older package is doing. Just in a way that is more sophisticated than anything I would come up with. (Since I was using it as a comparison above, I think this is the file that defines symlinking action in this project.)

In terms of an interface, in my simple mind you could stick a GUI that would just move the individual action files to a "deactivated" directory where it would be ignored by thunar; but I'm sure there is a smarter way a programed would think of. I don't know how to do that though. I think having human-readable names and descriptions would be nicer than just filenames but a solution that lacked this would be serviceable.