Reverse Filter order

[blues12]

I wonder if it were easier to have Exclude Filters on top (considered first), then followed by Include.

This would assume an implicit "Include all" by default, instead of requiring the mandatory asterisk.

The lower Include-list would then allow exceptions very easily. Say you want these subs only:
\A\B\98\
\A\B\99\

You'd exclude the whole \A\B\*\ , then include the subs 98 and 99 again - on the same filter page, at one glance.

No need anymore to set up additional sync-paths and local filters that override global filter. Less clutter, less clicking back and forth between filter dialogs, less wondering what filter page overrides what other filter page.

Let's consider the opposite: You want everything (1-97) except 98 and 99. Just as easy, simply enter them into the Exclude list this time:
\A\B\98\
\A\B\99\

This still works as it does now. I don't see any drawbacks, only an easier handling overall. No mix-up anymore of truly different sync-paths with those you had to construct only to include subfolders of excluded parents.

[Zenju]

Currently include (I) and exclude (E) filters are AND-related in the sense of "I && !E". Your proposal is an OR-relation: "!E || I". This supports the new scenario to exclude all subfolders expect a few given ones, but breaks the opposite scenario of including all subfolders except a few given ones.

[blues12]

I don't understand why your last secnario would have to be different from the way it's handled now. You enter the few excludes. Period. The only difference = not needing the asterisk, because everything is included by default.

I probably lack the programming background to think it all through.
To me, it works like this now:
1) Global Filter: Include everything via *
2) Global Filter: Exclude \A\B\
3) Local Filter: Include \A\B\99\

In my new scenario 1) would fall away because it is implicitly assumed.
2) and 3) would stay the same, except for being gathered on one filter settings dialog only.

[Zenju]

> I don't understand why your last secnario would have to be different from the way it's handled now. You enter the few excludes. Period. The only difference = not needing the asterisk, because everything is included by default.

The opposite scenario doesn't work with your model:

Include: \A\B\
Exclude: \A\B\99\

Expected: include everything from A\B except subfolder A\B\99. With your handling the exclusion would be overwritten by the include filter.

> I probably lack the programming background to think it all through.
To me, it works like this now:
1) Global Filter: Include everything via *
2) Global Filter: Exclude \A\B\
3) Local Filter: Include \A\B\99\

This cannot work even right now since global and local filter are AND-related: A local include filter cannot overwrite a global exclude.

[blues12]

The 3) in my scenario is not an actual filter, but an added subfolder-sync to override the global exlusion filter for it's parent. I just named it "filter" to explain my intention to consolidate in/excludes into one filter dialog.

I wouldn't know how else to achieve sub-includes of parent-excludes, other than by setting up additional sync-pairs. If I am wrong and there are easier ways, please tell me.

My include-filter never contains anything but the asterisk. So I figured why not make better use of it by allowing "real" includes that complement parent-excludes with specific sub-includes, wildcard enabled. As a quicker alternative to setting up additional sync-pairs with additional filters.

You probably have thought it through better than I have. Just trying to make sure you understand my line of reasoning. From a user's perspective. Which may not be feasible with programming logic.

[Zenju]

> If I am wrong and there are easier ways, please tell me.

I don't think there's currently a better way to handle your scenario other than splitting into two folder pairs with different filters.

> You probably have thought it through better than I have. Just trying to make sure you understand my line of reasoning. From a user's perspective. Which may not be feasible with programming logic.

The current handling cannot be changed in a way to support your scenario without also breaking other equally important ones. Therefore the only solution to handle both cases is to add additonal configuration options, e.g. two radio-buttons to specify the filter relation: AND/OR. But this comes at the price of overall higher complexity and I'm not sure if cases like yours are frequent enough to justify this general user interface burden.

[blues12]

Thanks for taking the time to answer.
What would really help me and maybe others as well, were an example of when and how to use the Include section. Filters are the most challenging part of FFS, imo. Time and size sections also make me think twice about how they apply to includes and/or excludes.

The help file has great examples for Excludes only. Whenever your time permits, maybe you could supplement that with an example that has it all, includes, excludes, time/size section.