derf / feh

a fast and light image viewer
https://feh.finalrewind.org
Other
1.51k stars 159 forks source link

Support rename command from within feh #188

Open za3k opened 9 years ago

za3k commented 9 years ago

The argument for having rename be provided by feh itself is:

  1. A 'mv' action doesn't maintain knowledge of the where the image is for filelist or back/forward.
  2. I think it's a common requirement, around as common as rotation.
hidroto commented 9 years ago

i second this.i think the move itself should still be done outside of feh and then telling feh where it was moved as an option left to the user so that the behave of existing scripts remains the same.

rr- commented 9 years ago

I think you could write a python script that shows a dialog in Qt and bind it with .config/feh/keys.

derf commented 9 years ago

I'm not sure if this is sensible — After moving a file, feh has no way of indicating that it moved it. But since you can't move something from A to B twice, using the mv key again would be an error.

While I understand the point of using mv from a feh action (and often do so myself, too), I don't see the advantage in an mv-aware feh which can still display the image after moving it. Why do you need it?

za3k commented 9 years ago

That's a "move to B" key, which is only one use case. Keep in mind rename is also a mv. I think a typical use case would be prompting the user for a location or name as rr- suggests, in which case it might make perfect sense to press the key twice.

My use-case is sorting scanned images. For example, I might want to rename an image, then crop it, then move it to the "postcards" subfolder. That's two moves (if I spell things correctly).

I agree with hidroto that telling feh the new image location via an external tool is probably the most sensible way to implement this. I'd suggest feh do the move rather than the external tool. That way, it's foolproof against the tool reporting an inaccurate location.

keks24 commented 3 years ago

My use-case is sorting scanned images. For example, I might want to rename an image, then crop it, then move it to the "postcards" subfolder. That's two moves (if I spell things correctly).

I have a similar use-case, where I want to visually evaluate screenshots and rename them accordingly.

In my case, it would be sufficient to just rename the current opened file and then reload the files of the directory, where feh was opened from. After that feh is aware of the renamed files.

mtfurlan commented 1 year ago

My usecase is sorting pictures from a camera in an unsorted directory into actually helpful directories, as well as sometimes renaming them.

My proposal is that when an action is run, if the stdout is a filename, feh should assume the file was moved to that and update the filelist accordingly. This is a fairly minimal API change. The downside is that feh would check for the existence of a bunch of garbage files in all the cases where this isn't expected. Maybe a flag could be added for a move type action so this isn't the default?

EDIT: Looks like adding a flag wouldn't be too bad, but capturing stdout would be annoying. We have access to the opt stuff in feh_event_invoke_action, but not in feh_action_run where would need to actually capture stdout.