<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 10:13 PM, 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="im">On Tuesday 23 July 2013 02:08:41 Milian Wolff wrote:<br>
</div><div class="im">> Hey all,<br>
><br>
> I finally sat down to implement a generic project filter interface and user<br>
> configuration. I've published what I have so far in the projectfilter<br>
> branch, please take a look.<br>
<br>
</div>I'm now considering merging this code into master - objections? Before doing<br>
so though, I have to figure out what to do with the current state of the<br>
pseudo-threaded CMakeManager which breaks this new API...</blockquote><div><br></div><div style>What does 'break' mean here? Does the filtering not work 100% correctly or does it crash even more often? In the latter case I think it would be better to first start the cmake-manager-refactoring and once its sufficiently advanced so that you know it'll be mergeable within a few weeks merge the filter branch into master. That way you don't break master for cmake users for an unforseeable amount of time. If its just the filtering thats not working all the time or so, its probably not as critical to wait for the cmake-refactoring. My concern is just that the refactoring can take quite some time and hence may be delayed for weeks or even months and having the filtering half/completely broken for so long means there can't be any releases...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> What I want to know now though, is whether my fancy settings dialog I wrote<br>
> years ago for the GenericManager actually is useful. I have the feeling that<br>
> its too complicated, albeit powerful.<br>
<br>
</div>I think I'll leave this for now until someone comes up with an improvement<br>
suggestion. Looking on the web though I see that there do exist usecases for<br>
the separated include/exclude rules.</blockquote><div><br></div><div style>Improving the UI once you have more feedback from users is usually quite simple provided that the logics are flexible enough. I also think having include and exclude rules for filtering can be useful/needed for some cases so its good to have.</div>
<div style><br></div><div style>Unfortunately I didn't get around testing the branch yesterday, maybe I can do that sometime during the day today.</div><div style><br></div><div style>Andreas</div></div></div></div>