Project Filtering

[Milian Wolff]

On Monday 26 August 2013 15:02:04 Milian Wolff wrote:
> On Monday 26 August 2013 11:38:31 Andreas Pakulat wrote:
> > Hi,
> > 
> > On Mon, Aug 26, 2013 at 2:03 AM, Milian Wolff <mail at milianw.de> wrote:
> > > On Tuesday 23 July 2013 02:08:41 Milian Wolff wrote:
> > > > Hey all,
> > > > 
> > > > I finally sat down to implement a generic project filter interface and
> > > 
> > > user
> > > 
> > > > configuration. I've published what I have so far in the projectfilter
> > > > branch, please take a look.
> > > 
> > > Once more, I am considering merging this :)
> > > 
> > > I spent today to refactor the settings UI for the project filter. This
> > > should
> > > hopefully be much simpler and intuitively to use, compared to what we
> > > had
> > > before. The UI should be rather self-explanatory. Please test it out!
> > > 
> > > If I don't get any objections, I'll merge the branch sometimes next
> > > week.
> > 
> > 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?

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

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

> > The order of the entries seems to be automatically re-arranged after
> > closing and re-opening the dialog in some cases. This makes the "move
> > up/down" buttons pretty much useless. I've had this after adding a
> > "_darcs"
> > entry for folders-only. It got sorted after the default .* entry, but when
> > re-opening the dialog was suddenly in front of that entry. Similar
> > automatic re-ordering seems to happen after manually moving an entry to a
> > particular position.
> 
> Thanks for the reports, I'll investigate.
>
> > Hmm, after some more playing, I think the re-ordering might explain my
> > first problem and why changing to 'basename'  was only working once. It
> > almost looks like the reordering is only visual, but under the hood the
> > entries are in the 'original' order. So when changing something like
> > 
> >  relative-path to basename for the re-ordered 'wrappers' entry the
> > 
> > underlying data changed it on some other entry actually. Hence the change
> > has no effect unless I happen to change the visual entry that belongs to
> > the 'wrappers' pattern. So it looks like something is fishy with the
> > model<->data mapping the listwidget.
> 
> 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.

> > What seems to be pretty well reproducable for this is (with a project
> > which
> > has a src/wrappers directory):
> > - expand the project tree so that the src/wrappers directory is visible
> > - Open the config page
> > - add an entry called 'wrappers'
> > - change the match against to 'basename'
> > - Hit 'apply', the filter will hide the src/wrappers entry from the tree
> > - Change the match against back to 'relative path'
> > - hit Return to make apply enabled again
> > - hit apply
> > 
> > For the me the wrappers entry keeps staying hidden, even though it should
> > be visible again now (assuming I understood basename vs. relative path
> > properly).
> 
> Many thanks Andreas, I'll sent another mail once I have sorted out these
> problems.

Bye!

/me who hopes we can finally merge this when he comes back on Monday!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de