|
|
It turns out that I never released a Parent Rename plugin with FileSieve - I could've sworn I had. In fact, checking the source code, while I may have started the plugin, the Process() method (in the programming sense, not FileSieve's Method sense) is completely empty. The project date stamp for Parent Rename appears to be 2013 (!?), so I wonder if the plugin didn't progress due to a limitation within FileSieve at the time? |
|
|
The core code is now working! Next up is to add support for regular expressions and some other options such as only processing the smallest/largest file within a directory. It seems a bit... odd... that filtering for the smallest/largest/etc file within a directory is left to the Method itself as opposed to the core FileSieve Source Item editor. Methods should only dictate the destination for a processed file, and not which files are processed. This requires big UI and core changes that makes me hesitant due to the possible breaking of existing profiles. |
|
|
Regular expression support is now in. Lots of UI polish required, and I think it might be worth adding reg-ex capturing. There are a few places within FileSieve that reg-ex is used, so I think it's probably worthwhile to make a generic reg-ex control so I only need to write the feature once; not sure if this should be done later rather than sooner... |
|
|
Gaaah, it looks like the regex editor is contained within the FileSieve4.exe assembly and so isn't exposed to plugins as they only reference FileSieve4.Plugins.dll. Refactoring: required. |
|
|
Preliminary testing is... good! FS4-ParentRename.png (17,248 bytes) |
|
|
Oh... uh-oh. I now remember why I stopped work on the Parent Rename plugin. Damn. Okay. Parent Rename can match a file via a regular expression, but can also match against the smallest or largest file within a directory - except it can't do the two latter size matches because items are processed in a sequential one-at-a-time. A whole directory isn't passed along and then a plugin can('t) go "Oh, OK; so, we have a list of files within a single directory, so let's pick out the smallest/largest one". While the plugin can keep a list of each file that was passed along and then determine that said file belongs in a certain directory, there isn't a way for it to know whether the file passed is the last one in the directory or not and then process the directory. That would also be a weird actually-processing-multiple-files-at-once-instead-of-one-at-a-time thing. FileSieve itself would need a mode for this, but I'm not really sure how to go about it. Maybe pass along a whole directory's contents at a time to a plugin, as opposed to a single file at a time? Hmm, there would need to be a Batched Get Files Mode implemented at some point. Plugins can outline their capabilities, but the user can select the Get Files Mode on a per Source Item basis, so that would have to be overridden. Oh, man... no wonder I binned this off. Alright, so the more advanced size stuff can wait and reg-ex matching has to be the main mechanism this works. I'll see if I can think of any other options to add. Just remembered: the user can set a min/max file size match on a per Source Item basis, so that's... something, I guess? FS4-ParentRenameNotPossible.png (50,405 bytes) |
|
|
Oops - seemed like I got this wrong. While I personally use a Parent Rename on an almost-daily basis (in a CLI form using a little program I did years ago), it appears the user (hi Jim!) wanted the layout in a different way (description updated accordingly). Thankfully, I'm pretty sure it'll be trivial to add because I'll be going with the Naming Mask approach (eg. %PARENT_NAME%\%FILE_NAME%.%FILE_EXT%) so you can specify exactly how you want things to be laid out and named. |
|
|
Going to have to leave the Examples (live preview of the current settings) section of the plugin out for now as it's taking forever preparing everything to get it working and delaying the test build. |
|
|
Will do more work on this plugin in the future. |
- Anonymous
