An update to the
previous post, I now included to the
Resource Filter bug report a UI implementation.
The
UI consist of a property page available when the user right clicks
IContainer objects (basically folders, projects and linked resource folders), and allows him to add, edit, remove and reorder resource filters.
The interface allows the user to choose which resource filter type (currently either a regular expression or a String Matcher), the mode ("Include Only" or "Exclude All"), the target ("Files", "Folders" or "Files and Folders" the filter type arguments, and finally whether it is inheritable to the container's children or not.
Unless I'm mistaken, the result of the filter operation is always the same no matter the order of the filters (i.e. (A & B & !C == A & !C & B), so why allow the user to order them?
The reason why filters can be reordered is
mainly for performance reason, since one can imagine filter types that are slower than others (one that check for file content types, for instance), and it is more efficient to put faster filters first so the slower filters have a smaller set to iterate through.
A side note, an interesting test is to put an "Exclude all" filter for files and folders matching "*" on a project itself: Will it cause the ".project" file to be filtered out as well? Thankfully, it doesn't, since the code path to
retrieve the ".project" file is different than the regular local refresh. So the project still opens fine, although it is indeed an extreme case.