Project Filtering

[Milian Wolff]

On Monday 02 September 2013 17:06:30 Andreas Pakulat wrote:
> Hi,
> 
> On Sun, Sep 1, 2013 at 11:10 PM, Milian Wolff <mail at milianw.de> wrote:
> > On Friday 30 August 2013 20:32:58 Andreas Pakulat wrote:
> > > Maybe you said so already, but whats the reason for requiring */ (or a
> > > leading slash) for relative paths? Is the implementation getting more
> > > complicated when you'd allow for 'foo/bar' as a path that would filter
> > 
> > out
> > 
> > > any bar thats below foo anywhere in the project tree? (i.e. /my/foo/bar
> > 
> > and
> > 
> > > /foo/bar and /blah/fasel/blub/foo/bar would all match)
> > 
> > Hehe thanks for the input, I've implemented this now. So much simpler, why
> > indeed did I never think about this yet? Anyhow, this is what these
> > discussions are about :) Please try again Andreas!
> 
> Thanks that works quite well as far as I can see, it also stirrs up a new
> question: Whats the reason for asking the user wether the filter should
> apply to files or folders? Is this needed for an optimization or for
> clarifying to the user why certain elements might be filtered which he
> didn't expect.

Yes, it's just an optimization and clarification. Since it's purely optional I 
think we can leave it in as-is. Also you'd have no easys way otherwise to hide 
e.g. a binary "foo" but not the folder "foo". I.e.:

/
foo/
foo/foo

-> only hide foo would then need the explicit "/foo/foo" pattern which I find 
odd. I prefer the way it is now.

> > > Ah and one last thing just crossed my mind: Escaping, I just tried to
> > 
> > match
> > 
> > > a file called 'foo*bar' (with a literal star in the filename) with a
> > > basename rule that had the text 'foo\*bar' (i.e. using backslash as
> > > escaping character) but this did not work :|
> > 
> > Fixed now. TIL what the difference between Wildcard and WildcardUnix is in
> > QRegExp :)
> 
> Works now :)
> 
> > I've also added a context menu entry for ProjectItems which offers a way
> > to
> > directly hide/exclude a given item from a project. Very useful imo. Please
> > test that as well!
> 
> That works very nicely as well, good idea!
> 
> Hmm, one more point (two actually, but one is just cosmetic):
> 
> I'm wondering wether inclusive filters should always be inclusive or not
> regardless of the order. Right now if I have an inclusive filter for
> src/web/Buildsub and an exclusive after that for web/Buildsub (which
> filters out examples/web/Buildsub), the exclusive filter wins. If the
> inclusive filter is after the exclusive one its visible. Are you aware of
> any use-cases that can only be implemented when having the current
> implementation?

I followed what .gitignore does here.

https://www.kernel.org/pub/software/scm/git/docs/gitignore.html

Also I think I can contrive some examples which would otherwise break:

hide: .*
include: .*.cpp
hide: .*.hidden.cpp

> The other (cosmet) point is that the icons and texts for move
> up/down/add/remove would probably look better when they'd be left-aligned
> instead of center-aligned. I'm not sure you can fix that though.

I'll see what I can do and then merge this.

Many thanks for your feedback again Andreas!

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de