[Thunderbird] QuickSearchBar : custom search result
asutherland at asutherland.org
Mon Aug 26 19:29:09 UTC 2013
(tb-planning is the best venue for questions like this since others may
have better ideas and then everyone can benefit from any answers;
replying there. Information on joining the list is available at
On 08/26/2013 06:06 AM, Karim Gemayel wrote:
> I'm writing a Thunderbird extension, and as you wrote some code for
> the Thunderbird Quick Search bar perhaps you could enlighten me.
> I'm looking to replace the result returned when a search query is done
> with the Quick Search Bar.
> Looking at the code and .idl, I thought registering a search listener
> with the event 'onNewSearch' and stopping the original search with
> nsIMsgSearchSession.interruptSearch() would do the trick, and then
> adding my own result using nsIMsgSearchSession.addSearchHit().
> interruptSearch() completely stops the search process, so I removed it.
> Now it works, my own search result is displayed, but the original
> search result is also displayed.
> So, I'm wondering, how can I disable the display of the original
> search and replace it with my own result ? I'd simply want to inject
> my own result in place of the original one without modifying anything
> else, specially without affecting observers and listeners notifications.
For clarity, I suspect you're talking about the quick filter bar; the
"quick search" bar was present in Thunderbird 3.0 and earlier versions.
I don't think it makes sense to directly replace the quick filter bar's
mechanisms. If you are adding some type of additional filtering
mechanism, you can contribute an additional filter via the
quickFilterManager. I made a blog post long ago on creating extensions
that can be found here:
The source for the extension is now here:
But there are probably more interesting extensions to look at,
especially if you want to more comprehensively alter the behaviour of
the quick filter bar. For example, alta88's "TotalQuickFilter" looks
If your goal is not to integrate with the quick filter bar, then you
should probably do something like the global database's faceted search
mechanism does when you select the "open email as list" option. It
creates a tab of type glodaList which then creates a GlodaSyntheticView
instance which FolderDisplayWidget.show() knows how to use. The list in
question can then be further filtered by using the quick filter bar.
If your replacement search is using the global database, then it's
really easy to do, open a glodaList tab. Otherwise, because of the
specialness of the 3-pane tabs' multiplexed implementation, it might be
"easiest" to just call .show() on the current folder display widget with
a synthetic message view implementation that you implement (look to
GlodaSyntheticView for inspiration). If your search is strongly
associated with the currently displayed folder, you can probably get
away with leaving the folder tree showing the current folder being
selected, but you'd need a UI affordance to make it easy for the user to
get back to the original contents of the folder without switching away
and then back. If your search is sufficiently different, you can
probably create an artificial node in the folder tree. If you are
creating a new node, it might make more sense to hang a UI off of the
global search box's extensible autocomplete mechanism instead.
Anywho, those are my thoughts. Since you didn't explain your use case,
I might be way off, but those approaches are more advisable than mucking
around in the lower level internals of the
FolderDisplayWidget/DBViewWrapper and interfering with the operation of
the quick filter bar. Please be sure to describe what your end goal is
at a high level if any of this sounds problematic or there are nuances
that you would like to discuss further.
More information about the tb-planning