<div dir="ltr">Hi,<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 12:02 AM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Monday 26 August 2013 15:02:04 Milian Wolff wrote:<br>
> On Monday 26 August 2013 11:38:31 Andreas Pakulat wrote:<br>> > Unfortunately the logics are still not quite clear enough IMO. I've put<br>
> > 'wrappers' as the pattern and left the rest at the defaults (i.e. relative<br>
> > path, files+folders, exclusive), but this did not have any effect. Neither<br>
> > was the 'src/wrappers' directory removed from the treeview nor a top-level<br>
> > wrappers entry inside the project. After trying various combinations I<br>
> > could get /src/wrappers to filter that exact directory and also /wrappers<br>
> > to filter that directory. What also seems to have worked was '*wrappers'.<br>
> > Changing from 'relative path' to just 'basename' also didn't work out for<br>
> > me, though I got it to hide once but then after changing back and forth it<br>
> > wasn't hiding anymore.<br>
><br>
> Awesome, thanks for the input. I'll look into this.<br>
<br>
</div></div>So, I worked on it again and hopefully have resorted all issues now :) Please<br>
test again! Note that I extended the tooltips and also return "*/" as default<br>
when adding a new filter. Then you can simply append stuff to it which should<br>
be the most common usecase.<br>
<br>
I thought about transparently rewriting "foo" to "*/foo" in the relative-path<br>
case but then it would show up as "*/foo" the next time you edit the filter.<br>
And one would need to rewrite also when changing from basename to relative-<br>
path etc. which might be a bit strange I think? What do you think?</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > As you can see my expectation was that if I put just a name in there it<br>
> > filters out any item that matches that string exactly. Could this be<br>
> > added?<br>
> > If not the tooltip should at least include a few example, or a whats this<br>
> > thing so that users can discover this behavior.<br>
><br>
> Yes, this is indeed a very valid point and something that differs from<br>
> .gitignore behavior (which I now use as a baseline).<br>
<br>
</div>Imo, most users should use basename matching anyways. Should I maybe make this<br>
the default?<br></blockquote><div><br></div><div>Yes I think basename should be the default if thats what most people will use anyway.</div><div><br></div><div>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).</div>
<div><br></div><div>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)</div>
<div><br></div><div>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 :|</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > Also I'm wondering wether we should really make it impossible to see<br>
> > object-, moc- and vcs-files/folders. I had actually tried to play with<br>
> > hand-generated vcs-filters and only after that not working at all I lookup<br>
> > up the code in the projectfilter plugin to see that those are always<br>
> > filtered out no matter what - so even an inclusive filter won't make those<br>
> > folders show up. I think it would be more transparent if those where just<br>
> > default-supplied standard-filters on all projects like the .* one so the<br>
> > user could change/extend them and is more aware why his .git folder is not<br>
> > shown (or _darcs, SCCS in VCS systems having less-hidden folders).<br>
><br>
> Very valid point and something I thought about as well yesterday. I'll make<br>
> these things simply part of the default filter set, so that the user can<br>
> customize it at will.<br>
<br>
</div>Done, all these things are now user configurable. Note that the ".kdev4"<br>
folder and the "$project.kdev4" files are still hard-wired, as well as folders<br>
containing a ".kdev_ignore" file.</blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Probably my code calling qSwap does not work as I imagined :) Thanks, I'll<br>
> look at it tomorrow probably.<br>
<br>
</div>Fixed now, it was an issue with (de-)serializing the data to/from KConfig.<br>
Please test again.</blockquote><div><br></div><div>Seems to work now.</div><div> </div><div>Andreas</div></div></div></div>