Noodlesoft Forums

I often encounter this type of situation:
I want to process a group of related files of different kinds (i.e. movies - MPEG Movie, QuickTime Movie, AVI Movie; or archives - 7zip archive, zip archive, far archive), but I have to specify each file type individually (either by kind or extension).

For example:
I have three files in my Downloads folder that I want moved to my Documents folder:
File.pages (kMDItemKind: Pages Document)
File.numbers (kMDItemKind: Numbers Document)
File.key (MDItemKind: Keynote Document)

The condition "Kind is Document" does not work*, so I have to set up a separate condition for every file type (and there are a LOT more than three!).

My Request is this:
Is it possible to add "contains" to the "Kind" conditions? "Kind contains (variable)" would allow easy grouping of similar files for sorting / processing.

*edit: after more research I realize that this should work, but it does not.

Thanks for your attention!

RC

I'm not sure why you would need to do this for movies or archives unless the app that handles those file types set up things incorrectly. Interesting notion but I'd need to think about it as it does clutter up that interface for what seems to be more of an edge case.

In your documents example, can you list a larger excerpt of the types and why they need to be grouped together (what is it that they have in common that you'd want to do this?)

Looking at the "kind" list in Hazel I count 9 different types of movie/video files, 11 types of image files, 22 types of archive and package files, 25 types of Source files, and so forth.

What I'm requesting - basically, is a way to move (sort, process) all of the movies by adding one line to a rule: "kind contains movie" to deal with all of them as a group; instead of making a rule that has eleven lines to do the same thing.

Your clutter comment has me confused.

Replacing eleven lines with one seems line it would reduce, not increase clutter. Also, the "kind" attribute in hazel's rules only has 4 attributes: is, is not, is blank, is not blank, while the "name" attribute has 12, I don't see how adding one more to "kind" would create clutter - It makes me think I have not been clear about what I am suggesting.

I've taken a few screen shots to help illustrate, as soon as I have somewhere to host them I'll add links.

edit:
Ok, I think I managed it - I was asking if "contains" could be added here:


to



which would allow someone to perform an action on all this:
or or or

With just a single line in a rule, well, or at least fewer than are needed now.
Thanks for taking my request seriously, I appreciate that.

Maybe you edited your article but my comment about clutter was about using patterns (or did I imagine that part)? Doing something like that would greatly clutter the UI for something rarely used.

Now, the issue here is that stuff should work. If you select "Image", it should mean any image file. If certain image types are not covered by that, that is the fault of the application that handles that file type. The "Kind" system is a hierarchy and all image types should descend off of "Image". The app authors define how the file type their app handles hooks into the rest of the Kind system so if they didn't do it correctly, there's little I can do at my end. For those types, I suggest contacting the author of those apps or finding another app that handles that file type properly.