Re: performance: filters, filternodes, & 34516

Tor Norbye wrote:
> I was more trying to argue that this bug is pretty severe.
> So I'm thinking of the following:
>  - I'd like to revert the code in TaskListView.getFilter
>    to return null, and then handle that gracefully in a couple
>    of places such that it doesn't throw exceptions.
> 
> I think this breakage will be less severe than the current
> one; then we can work on a better fix.  This also has
> the advantage of giving better performance when no
> filters are in effect. 

I realized why having filter==null was a problem; you have 
a change listener which activates/deactivates the RemoveFilterAction,
and this is registered with the filter. If there is no filter,
who notifies the remove action that it should be disabled?

So I did something else. I instead modified TaskListView to
use filter nodes if the filter has constraints (instead of
if filter != null). I also modified the show-suggestions action
to use an empty filter instead of null.

Things should work now - let me know if you see any problems.
Committed to trunk and merged to dev35 branch; module versions
1.9 (tasklist/core) and 1.8 (tasklist/suggestions).

-- Tor