Project Filtering

Andreas Pakulat apaku at gmx.de
Mon Sep 2 15:07:37 UTC 2013


Hi,

On Mon, Sep 2, 2013 at 5:06 PM, Andreas Pakulat <apaku at gmx.de> 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.
>
>
>> > 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.
>

Oh and I forgot: I think you should merge the branch now, the remaining
issues can be solved in master IMO.

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


More information about the KDevelop-devel mailing list