Feature enhancement request

[MacAhi]

In the search dialog box, leaving the 'Case sensitive' box unchecked makes the filename search parameter case insensitive.

In the conditions section below, Pathname (and maybe other fields), is case sensitive, and there's no way to disable that. If I want to avoid searching in certain folders, I have to make sure to include a statement for every possible case variation. I haven't tested this with the Comments or other text-based selections, but I assume they're also case sensitive.

[xnview]

you would like to have case sensitive for folder and not for filename?

[jkm]

Evidently, this only happens on the OP's operating system.

On Windows with 1.9.3, where the filesystem is case insensitive but case preserving, the Pathname search is always case insensitive, even if the "case sensitive" box is checked.

[MacAhi]

you would like to have case sensitive for folder and not for filename?

Hi, no I'd like both to be able to be case insensitive.

[MacAhi]

Evidently, this only happens on the OP's operating system.

On Windows with 1.9.3, where the filesystem is case insensitive but case preserving, the Pathname search is always case insensitive, even if the "case sensitive" box is checked.

The 'Case sensitive' checkbox seems to only affect the Filename field and not any of the Conditions. I'm attaching a made-up example. If I want to avoid searching any folder which contains the word 'preserved', I have to list it separately with every iteration of the case.

I am on MacOS

[jkm]

I understand, and agree that the issue that occurs on MacOS needs to be fixed. It might occur on Linux too, I haven't tried.

To get around this problem, you could possibly use a Regular Expression.

A regex that would normally work for your case would be

Code: Select all

(?i)^(?!.*preserved).*test

However, I tried this and a couple of other variations, and the regex built into XnViewMP either is not sophisticated enough or uses some different syntax. QRegularExpression was enhanced in v5.0 to support lookbehinds, but evidently only fixed length, so I'm not sure if that's the issue or if XnViewMP is using a different regex implementation.