Project Filtering

[Andreas Pakulat]

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.

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.

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

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.

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.

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

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20130826/6ec23f78/attachment.html>