tabmail tab monitor enhancements coming for quick filter

Andrew Sutherland asutherland at
Mon Apr 12 16:20:06 UTC 2010

  Development of the quick filter as an extension showed two major 
weakpoints that the gloda/quick search hybrid widget ("#searchInput") 
avoided because its logic was frequently just crammed into mailTabs:

1) No notification when a new tab was created if it was in the 
background; only tab switching received a notification.

2) No opportunity to contribute state to persisted tab state.

3) No in-API ability to contribute to / intercept the command 
hierarchy.  One could inject oneself into the command dispatcher chain, 
of course...

While it's very easy to make the argument that the quick search and now 
quick filter are special enough that it's fine, I think addressing the 
problems properly will have some factoring advantages and be of 
potential use to extensions that would otherwise end up monkeypatching 

As a result I will be adding the following to meet the above needs:

1) A tab monitor notification when a new tab is created/opened.

2) The ability for tab monitors to contribute to (and later use when 
restoring) tab state.  I'm just going to cram their contributions 
well-known-named dictionary that's part of the tab info.

3) Some kind of limited command vector support.  I'll probably just 
mimic the mechanism we use for tab types; it's slightly overkill and 
maybe not as helpful as it could be in specializing on tab type 
declaratively, but it's consistent and flexible.

I will also be adding the following to try and round out our coverage:

4) Notification that a tab is getting closed.  (This can also happen 
without a tab switch notification if the user closes a background tab.)

Is there anything I'm leaving out that would be useful to add?  Bad 
ideas in the above?  Speak now or submit a patch later...


More information about the tb-planning mailing list