Well, filter patterns are file related.

But i'm currently working (fighting) with a parallel folder patterns syntax.

It will be unusable to apply the same filter pattern also to folders. Results would be reallt weird.
So, the default will still be to filter on files, which is natural to most users.

If one wants to filter also on folders, it should use the new syntax, that is to prepend a backslash to the pattern.
The backslash will not mean "root", it will be just a switch that will assign the pattern to the folder filter.
I choosed the backslash just because it is one of the forbidden chars so i don't risk to find a element with this char in the name.

With the new syntax, if you want to filter, say, all jpegs into temp folders (wherever they are) you will write:

*.jpg;\temp

Does it sound useable? Umberto

Good to know.

I have still some dubts about the "\" switch, which may be confused with the "root" specifier, but available forbidden chars are \, /, :, *, ?, ", <, >, |...

* and ? cannot be used because they are part of the pattern match syntax, | is used to negate, " sounds odd, as long as < and >...

The only survivor looks like :, that i already used as switch specifier starting char ( see :tag:, :attr: and so on). For sake of uniformity i should add the :folder: switch, but looks rather long to type. Maybe i can add both "\" and :folder: synonims.

Any hint? Umberto

I'm concerned about adding too many synonims... at the moment i think it's better to keep only the backslash switch.

I attach a screenshot of the candidate 1.1.3.0 release. You can notice 4 new features over the many other features added):
1. Filter by folder name (here it's not shown but also negative filters are supported). After playing a bit with this feature i can say that it's cool.
2. Notice that the folders that match the folder filter pattern are displayed with name in BOLD font. This makes easier to understand why stuff has been included by the filter.
3. I filtered also by zip and jpg files. Notice they are colored with different colors (optional) because they belong to different file classes (customizable)
4. The selected element will drop a shadow (optional) to make it easier to visually track.

[attach]

I don't think I really understood the syntax before.  Just to check I've got it right now, the release candidate is looking at all folders, and shows all their sizes.  But, it is set to filter folders that start "program*," and within those, it considers JPG and ZIP files.  SpaceSniffer's main statistics at the top of the screen now show those files in those folders only, and those are the ones where text is in bright white, and specially coloured.  Other folders and files are shown with their sizes, but not considered in the main statistics.

Is that correct?

Well... not. I think that this way it should be difficult to understand. Maybe i lacked of explanation in my previous post. In the posted example, the filter is composed of two main parts: a folder mask and two file masks.

If you consider the disk structure as a tree, the purpose of the folder mask is to cut all branches whose paths don't contain "program*" in at least one nesting level.
After the tree has been cutted down, the file mask will search for the file extensions. It's like a two dimensional filter: the first axis is the folder dimension, the second axis is the files dimension. Both are perpendicular and not directly related.

Consider this example:

root
|
+Program Files
|     |
|     +Data
|
+Users
|     |
|     +Programs
|     |
|     +Data
|
+Windows
|     |
|     +System

The previous folder mask will consider all files under "Program Files\..." and all files under "Users\Programs\..." but not other branches because they don't contain "program*".

The statistic of a folder is always the sum of the size of their direct children, hence in the screenshot you will see that the C:\ drive contains 1.7Gb of JPG or ZIP files that are stored under a program* folder (at any nesting level). Actually, the C:\ drive is 300 Gb in size (without filters).

Suppose that your disk structure contains many folders with similar names, but you don't know how many and where they are (and at which nesting level they are). Without a folder mask you must examine each branch of the disk structure to find them. With folder mask you can find every "temp" folder with a click.

I think that the semanthics is simple (perhaps only to me because i programmed the algorithm, eheh), but if you have any other interpretation please let me know. I need to understand if the behavior of SpaceSniffer is what people expects.

Thank you! Umberto

Contro, you will need to wait some other few days...

Tomorrow i changed my mind about the folder name filter. Having two different pattern match methods is pretty confusing. Now i propose another solution to the problem (more efficient).

If the pattern doesn't contain the backslash (*.jpg) the pattern matching is applied only to the file name itself. So, this will make SpaceSniffer behave exactly like the released version.

If the pattern contains che backslash (\temp) the pattern matching is extended to the whole file path (final file name included).

Example: (\temp) which doesn't contain a wildcard, is implicitly extended to (*\temp\*), so "c:\windows\temp\data\abc.txt" is found

Example: (*\temp\*.jpg) will match any jpg file under a temp folder at any nesting level (because the second * will match any char sequence, hence any folder nesting)

Example: (*\temp* ) will match any file under a temp folder or any file whose name starts by temp

The only drawback is that i lose the BOLD hilight because il will need too much CPU power to do realtime.

But... maybe working always with the full path will be limiting... I wonder if the folder pattern should be extended the the full path (file name included) or only to the path (file name excluded). I still wonder which case is the most flexible...

It's like a two dimensional filter: the first axis is the folder dimension, the second axis is the files dimension. Both are perpendicular and not directly related.
[...]
Consider this example:

root
|
+Program Files
|    |
|    +Data
|
+Users
|    |
|    +Programs
|    |
|    +Data
|
+Windows
|    |
|    +System

The previous folder mask will consider all files under "Program Files\..." and all files under "Users\Programs\..." but not other branches because they don't contain "program*".

I didn't realise that the folder wildcard implied the equivalent of DOS wildcard "*folder*".  I thought it meant "folder*", no front wildcard, so would only apply to the green branch above.  It would have excluded everything else, shown in red branch.  I just needed to grasp that it's *folder*.  I think I see what you mean about having two dimensions of filters.

Suppose that your disk structure contains many folders with similar names, but you don't know how many and where they are (and at which nesting level they are). Without a folder mask you must examine each branch of the disk structure to find them. With folder mask you can find every "temp" folder with a click.

That problem is a real pain with my file manager, Total Commander.  Anything to help is welcome!

I think that if one wanted to explore just folder*, he would start the snif operation from that folder instead of the entire drive.

Yes.  I'm not thinking clearly again.  An all-to-frequent state of affairs 

So, do you consider the current release candidate behavior useful?

Yes, but, please can you make sure the folders and filters wildcards are explained in Help, like you did above?

Honestly, i'm still looking for the "magic words" that make the user understand the concept with less text. Sometimes i've a bit of difficulty because i'm not english native. Hints are welcomed!

I should warn you than whenever I've "helped" someone's "magic words," the author generally ends up thinking I make it too long!  But I think that's excellent.  I've taken the liberty of changing a few spellings and very minor grammar points, but what you meant is perfectly clear:

"The filter by file name mask applies only to files. Sometimes you may want to search only under certain folders, say, temp folders. You don't know where they are and at which nesting level on your media device, but you know they are there, and possibly more than one.

In this case you can use a folder name mask filter. Folder name mask filters are the same as file name mask filters, except they apply to folders. To identify a pattern as a folder mask pattern, simply prepend it by the '\' (backslash) char. The backslash char doesn't have the meaning of "root folder", it is simply a switch. It has been chosen as "switch" char because it is forbidden in file and folder names (it is a path separator), hence it cannot exist in an element name.

When you apply a folder name mask filter, only files whose path contains a matching folder are included. Moreover, folders whose names match the mask are hilighted with the BOLD style in their name. This makes easy to understand why stuff has been included by the filter. If, on the other hand, you are using an exclusion filter (by prepending the whole pattern string by the negation pipe (|) char), excluded folders are not hilighted, just because they will not be displayed.

Example: by typing \temp every file under a temp folder (at any nesting level) is included. For example, C:\Windows\temp\data\abc.txt would be included.
Example: on the contrary, by typing |\temp every file under a temp folder (at any nesting level) is excluded.

Hint: You can consider folder and file masks as a two dimensional filter. The first axis is the folder mask, the second axis is the file mask. Both axis work independently. When you apply a folder+file mask you are defining some kind of "coordinate" in a 2D space. You first "cut" the directory tree structure and isolate the searched folders, then examine the wanted file names by the other mask."

Online quick tip window:

By folder name
        Same as by file name, but prepend with '\' (backslash) (|).
        The folder mask considers files whose path contains elements
        that match the mask at any nesting level.
        Matching folders are renderer with BOLD font.
        The mask itself cannot include the '\' char.
        Example: \temp will include only files whose path contain
                at least a 'temp' folder.
                For example, C:\windows\temp\data\abc.txt is ok
        Example: |\progr* will exclude files whose path contain
                at least a 'progr*' folder.
        The starting backslash char does not mean 'the root', it has
        been choosen as switch because it is a forbidden char
        in files and folders name.
        (Note: Folder masks are slower than file masks)

Thanks, Umberto! 

Just for information...

1.1.3.0 is out. Enjoy!

http://www.uderzo.it/main_products/space_sniffer/download.html