Project Filtering

[Andreas Pakulat]

Hi,


On Fri, Aug 30, 2013 at 12:02 AM, Milian Wolff <mail at milianw.de> wrote:

> On Monday 26 August 2013 15:02:04 Milian Wolff wrote:
> > On Monday 26 August 2013 11:38:31 Andreas Pakulat wrote:
> > > Unfortunately the logics are still not quite clear enough IMO. I've put
> > > 'wrappers' as the pattern and left the rest at the defaults (i.e.
> relative
> > > path, files+folders, exclusive), but this did not have any effect.
> Neither
> > > was the 'src/wrappers' directory removed from the treeview nor a
> top-level
> > > wrappers entry inside the project. After trying various combinations I
> > > could get /src/wrappers to filter that exact directory and also
> /wrappers
> > > to filter that directory. What also seems to have worked was
> '*wrappers'.
> > > Changing from 'relative path' to just 'basename' also didn't work out
> for
> > > me, though I got it to hide once but then after changing back and
> forth it
> > > wasn't hiding anymore.
> >
> > Awesome, thanks for the input. I'll look into this.
>
> So, I worked on it again and hopefully have resorted all issues now :)
> Please
> test again! Note that I extended the tooltips and also return "*/" as
> default
> when adding a new filter. Then you can simply append stuff to it which
> should
> be the most common usecase.
>
> I thought about transparently rewriting "foo" to "*/foo" in the
> relative-path
> case but then it would show up as "*/foo" the next time you edit the
> filter.
> And one would need to rewrite also when changing from basename to relative-
> path etc. which might be a bit strange I think? What do you think?


I think this works relatively good now. Its easy to get a working filter by
just adding some text from a folder or file visible in the tree and the
validity checks make it more understandable why some filter does not do
anything.


> > > As you can see my expectation was that if I put just a name in there it
> > > filters out any item that matches that string exactly. Could this be
> > > added?
> > > If not the tooltip should at least include a few example, or a whats
> this
> > > thing so that users can discover this behavior.
> >
> > Yes, this is indeed a very valid point and something that differs from
> > .gitignore behavior (which I now use as a baseline).
>
> Imo, most users should use basename matching anyways. Should I maybe make
> this
> the default?
>

Yes I think basename should be the default if thats what most people will
use anyway.

However I'm wondering why there is made a difference anyway? Is there an
optimization possible in one case vs. the other? Having no distinction (or
deducing it from the filter text) would cause less confusion and could feel
more natural for those that already wrote a gitignore or svnignore rule (or
other types of wildcard filter rules).

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)

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

> > Also I'm wondering wether we should really make it impossible to see
> > > object-, moc- and vcs-files/folders. I had actually tried to play with
> > > hand-generated vcs-filters and only after that not working at all I
> lookup
> > > up the code in the projectfilter plugin to see that those are always
> > > filtered out no matter what - so even an inclusive filter won't make
> those
> > > folders show up. I think it would be more transparent if those where
> just
> > > default-supplied standard-filters on all projects like the .* one so
> the
> > > user could change/extend them and is more aware why his .git folder is
> not
> > > shown (or _darcs, SCCS in VCS systems having less-hidden folders).
> >
> > Very valid point and something I thought about as well yesterday. I'll
> make
> > these things simply part of the default filter set, so that the user can
> > customize it at will.
>
> Done, all these things are now user configurable. Note that the ".kdev4"
> folder and the "$project.kdev4" files are still hard-wired, as well as
> folders
> containing a ".kdev_ignore" file.


I think having the latter hardcoded is fine (its a more or less hidden
feature anyway). The project files I don't really have an opinion. I do
happen to edit them every once in a while manually but thats because "I
know what I'm doing" (tm) and I have kdev closed during that anyway. You
can always enable editing them if users complain (much harder to go the
opposite direction).


> > Probably my code calling qSwap does not work as I imagined :) Thanks,
> I'll
> > look at it tomorrow probably.
>
> Fixed now, it was an issue with (de-)serializing the data to/from KConfig.
> Please test again.


Seems to work now.

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