<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 2, 2013 at 5:06 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de" target="_blank">apaku@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Sun, Sep 1, 2013 at 11:10 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="im">On Friday 30 August 2013 20:32:58 Andreas Pakulat wrote:<br></div><div class="im">> Maybe you said so already, but whats the reason for requiring */ (or a<br>


> leading slash) for relative paths? Is the implementation getting more<br>
> complicated when you'd allow for 'foo/bar' as a path that would filter out<br>
> any bar thats below foo anywhere in the project tree? (i.e. /my/foo/bar and<br>
> /foo/bar and /blah/fasel/blub/foo/bar would all match)<br>
<br>
</div></div></div><div class="im">Hehe thanks for the input, I've implemented this now. So much simpler, why<br>
indeed did I never think about this yet? Anyhow, this is what these<br>
discussions are about :) Please try again Andreas!</div></blockquote><div><br></div><div>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. </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> Ah and one last thing just crossed my mind: Escaping, I just tried to match<br>
> a file called 'foo*bar' (with a literal star in the filename) with a<br>
> basename rule that had the text 'foo\*bar' (i.e. using backslash as<br>
> escaping character) but this did not work :|<br>
<br>
</div>Fixed now. TIL what the difference between Wildcard and WildcardUnix is in<br>
QRegExp :)<br></blockquote><div><br></div></div><div>Works now :)</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've also added a context menu entry for ProjectItems which offers a way to<br>
directly hide/exclude a given item from a project. Very useful imo. Please<br>
test that as well!<br></blockquote><div><br></div></div><div>That works very nicely as well, good idea!</div><div><br></div><div>Hmm, one more point (two actually, but one is just cosmetic):</div><div><br></div><div>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?</div>

<div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div></div></font></span></div></div></div></blockquote></div><br></div><div class="gmail_extra">Oh and I forgot: I think you should merge the branch now, the remaining issues can be solved in master IMO.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Andreas</div></div>