mail at milianw.de
Mon Aug 26 13:02:04 UTC 2013
On Monday 26 August 2013 11:38:31 Andreas Pakulat wrote:
> 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.
> 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).
> 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.
> 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.
> 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
Many thanks Andreas, I'll sent another mail once I have sorted out these
mail at milianw.de
More information about the KDevelop-devel