Project Filtering

[Andreas Pakulat]

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.


> > 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?

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.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130902/ab23292e/attachment.html>