lxqt/pcmanfm-qt

[Feature request] Support Path variable in .desktop specification for file-manager actions.

Closed this issue · 4 comments

Not entirely certain if this should be a bug report instead since this seems like it should nto be standard behavior... anyhow:

Currently pcmanfm-qt always executes any file-manager actions (custom context menu items) frome the home directory.

In the .desktop specification you can set a Path variable to configure the working directory, this could be used to prevent this issue by setting

Path=%d

to set the working directory as the actual directory the script was executed from instead of the home directory.

As it stands this is not supported and there isn't a way to ensure a custom action executes from the folder it was called from.

At least if there is, it is not listed here: https://github.com/lxqt/pcmanfm-qt/wiki/custom_actions

And I did indeed test to see if the path setting worked but it does not.

Please add support for this.

Please read the Wiki to know what a custom action is and how you can pass parameters.

Please read the Wiki to know what a custom action is and how you can pass parameters.

%d is the custom parameter that spits out the name of the directory the action was called from... There's nothing else! Do you expect me to read something that hasn't been written?

There is no way to actually use these parameters to set the working directory to the value of %d (because Path= is not supported by pcmanfm-qt... Hence the feature request)

What am i supposed to do? cd %d && my-command.sh?

That won't work, it fails at the && part.

I already in fact told you that there was nothing in there that lets me set the working directory.

Are you talking about the basenames and folders setttings? They do in fact not let you set the working directory, they're just conditionals.

There's no point in repeating the Wiki here, but this is a simple example:

[Desktop Entry]
Type=Action
Icon=utilities-terminal
Name=Open Terminal Here
Profiles=profile-zero;

[X-Action-Profile profile-zero]
SelectionCount==1
MimeTypes=inode/directory;
Exec=qterminal -w %f
Name=Default profile

QTerminal should be opened in the right-clicked directory only if told; otherwise, there would be a bug to fix.

What am i supposed to do? cd %d && my-command.sh?

bash -c "A && B"

Do you expect me to read something that hasn't been written?

In any documentation, it's expected that the user reads it and uses his/her deduction power.

QTerminal should be opened in the right-clicked directory only if told; otherwise, there would be a bug to fix.

Supporting Path= does not affect that.

bash -c "A && B"

I figured it might be possible to do it in this kind of way, but it is convoluted and no one who hasn't been using linux for many years would even think of it, generally, unless explicitly instructed to, the wiki contains no such example.

To illustrate my own point, I say 'i figured' but what it really means is I only first thought of it today after writing the feature request (and I cannot remember if the moment i had the thought was 6 hours ago when i wrote the op or 20 minutes ago when i wrote my response)... And it's been 3 days since i started wondering about this, granted i didn't spend all that much time on it. But I am naturally inclined to use this kind of solution only as an absolute last resort because the syntax sometimes gets a little fucky when you execute commands this way; and it also doesn't work everywhere, it's just the luck of the draw really if sh -c "command && command" (and almost universally when it does work it's in cases where it shuoldn't be needed, like the .desktop files which support executing but only with limited sh syntax so you can use sh -c to get full exec syntax but not with 100% reliability) is gonna work or not so even veteran users may take a while to think to try it, case in point i've been using linux for more than 10 years, and I don't mean ubuntu, I mean arch, and even gentoo. And sure, i thought of it eventually, you're right about that part... But look how long it took.

And I absolutely detest this solution for aforementioned reasons (though I will use it, but only because it's the only way...)

Throughout my entire linux usage history I've maybe used this method 10 times. That's like once per year at best...

In any documentation, it's expected that the user reads it and use his/her deduction power.

And my deduction power was right, setting the working directory isn't actually supported, you can hack your way around it using the method you described, but it's not exactly user friendly, or the normal way of doing it for the .desktop format for that matter, hence feature request.