tabmail tab monitor enhancements coming for quick filter
asutherland at asutherland.org
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,
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