Re: performance: filters, filternodes, & 34516

Hi Tor,

Tor Norbye wrote:

> I've been looking at bug 34516, which is pretty bad - it means that
> once you have more than 4 suggestions for a given type, you loose
> the ability to see these suggestions. 

sorry about that.

>
>
> It seems related to the new behavior in the tasklist that there is
> -always- a filter in effect, even when the user hasn't added one;
> the filter is a "null" filter - one without any conditions.
>
> The problem is that once you have a filter, a different route
> is taken in the TaskListView; it will use FilterNodes instead
> of TaskNodes in the display.  The net result is that you end up
> having to create twice as many nodes - for each task/suggestion
> in the display, you have both a task node and a filter node!
>
> This seems like unnecessary overhead. Is there a good reason it's
> this way? Can we change it back? I also noticed that the preview
> panel in the Filter dialog is gone - is the rationale that this
> is just a customizer now? (The originally copied the design of
> the filter dialog from the Mozilla mail filter dialog.) 

the filter dialog is now a non-modal dialog. It is much more convenient.
I don't think that there was a special reason for empty filter instead of
null. It was just easier to implement.

>
>
> The root cause of bug 34516 might be that our filter nodes
> (TaskNode.FilterTaskNode) isn't handling dynamic changes from
> Children.LEAF to Children(list) correctly.  So just changing the
> filter behavior back won't really fix the bug since you'd still
> have the problem once a filter is in effect (this is just theoretical
> speculation). 

Hopefully I will have some time next weekend to fix this bug.

-- Tim