I am looking for this setting also.
Since I can't find any other information about it, I'm going to also
raise the question as to whether this is possible. It's a pain to
always have to click on it after the search is done.
+1 on this request
/Magnus
Thritto.
On 12/16/2009 06:22 AM, klint wrote:
> Is there a hidden setting that switch the default sort order of
> faceted search results by date, instead of "by relevance"?
I fixed this for myself... but it's a hack. I haven't made it into an extension... maybe someone can whip one up? I made a simple working
extension for Firefox once ("Background Tabs": http://caseyconnor.org/jl/backgroundtabs), but there's so much i don't understand about all that
that someone else should probably do this correctly. :-) It would take an experienced extension maker about 5 minutes, i figure.
I'm on Linux, and this is how I did it:
-------
To make faceted search results sort by date instead of relevance, by default:
* close down thunderbird
* sudo emacs -nw /usr/lib/thunderbird-3.1.6/chrome/messenger.jar
* find glodaFacetView.js (something like line 226 for me), hit <enter> on that line to edit it (emacs can edit inside .jar files)
* change the text on line 412 from
this._sortBy = '-dascore';
to
this._sortBy = '-date';
* fire up thunderbird and it should be good to go
...if you're using an editor that can't edit inside of .jar files, you'd have to extract that jar in another directory, edit the file, and then
repackage it. Obviously an extension would be a lot easier, since this will be overwritten on an update. If you're using Windows or a Mac,
you're on your own, but it shouldn't be hard to find the equivalent location of those files.
Hope that helps. Good to know i'm not the only one. :-)
-c
Very cool, nice work!
There's a tool (that I haven't yet had a chance to poke at), intended to
make it very easy to set up an
Would you be willing to try
<https://addons.mozilla.org/en-US/developers/tools/builder> to do the
heavy lifting and put your little piece in it and report back here on
whether it turns out to be as easy as one might hope?
Thanks,
Dan
Uh oh, what i have gotten myself into... :-)
Started the wizard but got stuck at the "which versions does your plugin support" question...
I'm trying to look at different versions of Tbird to see where my patch would be appropriate, but i have no idea where in the byzantine CVS
hierarchy glodaFacetView.js resides...
I checked out the CVS module for /cvsroot/mozilla/mail, but the file doesn't appear to be in there anywhere. I looked in a bunch of other
modules under mozilla and couldn't find it.
This:
http://mxr.mozilla.org/comm-central/search?string=.dascore®exp=1&find=glodaFacetView.js&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central
...shows it in /mail/base/content/.
...but /cvsroot/mozilla/mail/base/content does not hold it.
Any tips? I am clueless about all of this. Thanks,
-c
I would probably recommend limiting yourself to 3.1 and the current
3.2/3.3 alphas. Thunderbird 2 is no longer supported, and I believe 3.0
is entering its end-of-life phase.
[1] Some of the CVS trunk is actually preliminary work on Thunderbird
3.0: 3.0b1 is the first release that uses in Mercurial.
Thank you for setting me straight! (Maybe someone should update http://developer.mozilla.org/en/Download_Mozilla_Source_Code)
Also, is the SVN repository yet a third view into the tree?
I have confirmed that this patch should work with 3.0 through the current trunk (3.3 alpha).
Dan - I went through the online wizard, and though it's helpful (similar to that Firefox add-on creator extension i suppose) it doesn't do the
hard part. :-) I get confused/baffled in the terminology of overlay/DTD/CSS/chrome and X?? acronyms and all that. I don't have the time to sort
it all out, so regrettably for now I'll have to leave it to someone more experienced (for whom i'd guess it would be a trivial exercise). I'll
even volunteer to make the entry and screen shots at AMO and so forth. :-)
For the record:
/mail/base/content/glodaFacetView.js
lines 398 to 417 are currently:
-------------
initialBuild: function() {
let queryExplanation = document.getElementById("query-explanation");
if (this.searcher)
queryExplanation.setFulltext(this.searcher);
else
queryExplanation.setQuery(this.collection.query);
// we like to sort them so should clone the list
this.faceters = this.facetDriver.faceters.concat();
this._timelineShown = ! Application.prefs.getValue('gloda.facetview.hidetimeline', true);
this.everFaceted = false;
this._activeConstraints = {};
if (this.searcher)
this._sortBy = '-dascore';
else
this._sortBy = '-date';
this.fullSet = this._removeDupes(this._collection.items.concat());
this.build(this.fullSet);
},
---------
and they should become:
-------------
initialBuild: function() {
let queryExplanation = document.getElementById("query-explanation");
if (this.searcher)
queryExplanation.setFulltext(this.searcher);
else
queryExplanation.setQuery(this.collection.query);
// we like to sort them so should clone the list
this.faceters = this.facetDriver.faceters.concat();
this._timelineShown = ! Application.prefs.getValue('gloda.facetview.hidetimeline', true);
this.everFaceted = false;
this._activeConstraints = {};
this._sortBy = '-date';
this.fullSet = this._removeDupes(this._collection.items.concat());
this.build(this.fullSet);
},
-----------
If i get inspired to muck through it i will update here.
-c
Here's my current mostly-ignorant understanding (kindly vet and correct any of these that are misguided):
- because i'm trying to alter one small spot in a javascript file, i have to overlay creatively (i.e. there is no "javascript overlay" where i
can just replace a function)
- i could use an javascript override in chrome.manifest, but i'd have to replicate the entire (large) glodaFacetView.js file, and that's not a
good option (why can't i do an "override" that replaces selectively? Basically "apply patch before running"...?)
- thus i need to find a .xul somewhere that i can hook in to so i can inject some creative javascript
- XUL overlays don't take effect until the overlaid XUL is instantiated at runtime
- FacetContext, which lives in glodaFacetView.js, is where the date vs. relevance setting goes down. It's set in an initialization call dynamically.
- this: http://mxr.mozilla.org/comm-central/source/mail/base/content/glodaFacetView.xhtml
contains the reference to glodaFacetView.js, and FacetContext won't be loaded until that .xhtml file is instantiated
- there's no such thing as an xhtml overlay
- this: http://mxr.mozilla.org/comm-central/source/mail/base/content/glodaFacetTab.js#51
...is where the .xhtml file is instantiated
- line 56 of that same file is the appropriate .xul to deal with (glodaFacetViewWrapper.xul)
- that xul (i guess it's a wrapper around a set of tabs with some common data structures?) loads, and the load event in turn triggers the
insertion of a tab containing the .xhtml file (line 51)
So here was my scheme: i don't think there is any way i can set the necessary variable (FacetContext._sortBy = "-date") ahead of time, because
everything is dynamically instantiated and initialized on-demand by javascript for every search, and goes away after the search closes. I won't
have a shot at setting that variable until everything is up and displayed, so my plan was to let it display and then immediately set the
variable to "-date" and trigger a refresh.
After the wrapper has loaded, the .xhtml is loaded into the <browser> object inside the wrapper (glodaFacetViewWrapper.xul) (see line 49 of
glodaFacetTab.js for browser reference), so i thought that i could attach a callback onLoad event to the browser object as that wrapper was
loaded, and after that loaded i should have access to the FacetContext scope.
Thus i created a chrome.manifest override for the glodaFacetViewWrapper.xul file. I tried to do overlays, but nothing seemed to stick. The only
way I could effect change in there was to do an override.
I just copied the file exactly, but at the end, just before </window>, I added:
<script type="application/x-javascript" src="chrome://srsbdnr/content/srsbdnrOverlay.js"/> <!-- (srsbdnr is the addon) -->
...which is a javascript file that is supposed to work the magic. E.g. in that file:
// this works, afaik, to tell me when the wrapper loads, but the xhtml and FacetContext stuff hasn't loaded yet, so it's useless:
window.addEventListener("load", function () { alert("xul loaded"); }, false);
// this doesn't work:
window.addEventListener("load", function () { window.document.getElementById("browser").addEventListener("load", function () { alert("xhtml
loaded, ready to work my magic here"); }, false); }, false);
Current problems/questions:
- using addEventListener on the browser object has no apparent effect, likewise no effect (or errors) when i try to set it on the many many
attempted variations of browser.window, browser.contentWindow, document, parent, etc etc etc. Where should that hook go?
- is it even possible to add that callback, or am i coming up against some kind of scoping thing in javascript? I just want to have a function
run after the xhtml has loaded into that "browser" object, and afaik i have to make that happen inside of the "wrapper" xul, but any other
methods are welcome.
Even assuming i can get that event to fire for me and that i have a reference to the browser object, i still face two big questions:
- whether or not FacetContext will actually be in scope/accessible
- after doing FacetContext._sortBy = "-date"; i still need to trigger a refresh, which i see happening at
http://mxr.mozilla.org/comm-central/source/mail/base/content/glodaFacetBindings.xml#1426
...but that's a whole 'nother bag of worms in terms of figuring out how to get a reference to that node to make that call...
window.parent.getElementById("results-message")???
Thanks for any ideas,
-c
In terms of the load events, I have found them troublesome too. I think
that is why we have the function reachOutAndTouchFrame at the bottom of
glodaFacetView.js.
If you look in that function, at the bottom you will see that it
establishes a linkage with the owning tab, and then checks
aTab.query.completed to decide whether it should kick off the faceting
process. This suggests to me that you could probably perform some
shenanigans in terms of abusing that logic.
Specifically, if you replace aTab.query with an object whose getter
triggers your logic and also return false, you should be able to either
stop the initial build logic and/or replace the implementation of
initialBuild with your own function.
It's fairly ugly, but as you discovered, the current implementation is
unintentionally highly resistant to extension and so anything that works
is a major accomplishment regardless of how ugly it is.
(Alternatively, you could avoid booby-trapping the completed attribute
and instead just have it always return false if you can get the load
notification to work.)
FWIW, We/I take the lack of extensibility very seriously and are working
to make sure this doesn't happen again going forward.
Andrew
> ....which is a javascript file that is supposed to work the magic. E.g.
> ....but that's a whole 'nother bag of worms in terms of figuring out how
Er, but you will also need to move the collection to another attribute
on the tab so that when reachOutAndTouchFrame thinks it is registering
itself as the listener for the collection, it actually is not.
Andrew
First, Andrew, thanks for the flattery and the help. :-)
I got something working, and I'm curious to know if you or anyone has any feedback.
Rather than implode trying to grasp all the helpful hints you gave, I found what for me was an easier way...
I did a full override for the entire glodaFacetView.xhtml file (which isn't large). In the override, immediately following the line where it
includes "glodaFacetView.js", I include my own .js file. In that file I programmatically replace the javascript function I wanted to alter:
FacetContext.initialBuild = function() {
// my replaced content here
}
...works like a champ. Seems so easy in retrospect. Almost... too easy. :-) Any problems with that?
I have an .xpi ready for AMO, but thought I'd run it by the group here first. Trying it out on older versions would be especially appreciated
(should work for 3.0 through current...).
http://caseyconnor.org/srsbdnr.xpi
If no one responds, or people respond positively, I'll post it to AMO in the next couple days.
Thanks for the help!
-c
On 12/07/2010 11:26 AM, Andrew Sutherland wrote:
Another solution which *might* have worked would be to catch the
function that fires up the glodaFacetView.xhtml tab and wrap it in a
function of yours that adds an extra onload handler on the tab, and does
what you need once the facet view is loaded...
What I did in the end was add the RSS feeds for the concerned files in
my RSS reader and watch the changes and make sure I backport them all
(spoiler: in a few months' time, there were none).
Anyway congrats for your work!
jonathan
PS: sample RSS feed:
http://hg.mozilla.org/comm-central/atom-log/tip/mail/base/content/multimessageview.xhtml
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
That's one reason why I think HTML is not (yet) ready for UI development
(another being that it doesn't support native look as well as XUL at
this time).
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
I don't know enough about this world to have a relevant opinion :-) but I do again wonder aloud why there isn't a chrome.manifest "patch"
overlay type, where you can overlay raw lines of code of any file (like an XUL overlay, but more brute). I'm sure it's not there for a reason,
but it would have made my extension a lot simpler (one entry in manifest, and one patch file to change 4 lines of code.) Bonus points if I can
use regex and other special sauce in the patch file to reduce the number of different versions as the file changes over time.
> Another solution which *might* have worked would be to catch the function that fires up the glodaFacetView.xhtml tab and wrap it in a function
> of yours that adds an extra onload handler on the tab, and does what you need once the facet view is loaded...
Thanks, i.e. glodaFacetTab.js? I decided not to because a) if I was going to override something, I figured I might as well do it as close to the
change point as possible, b) both files were about the same size, and thus roughly as big a deal to copy and paste and maintain in an override,
and c) by replacing the .js function I could effect my change (of a variable assignment) before any initialization took place, thus obviating
the need for a refresh, etc etc. Not sure if this was sound reasoning.
> What I did in the end was add the RSS feeds for the concerned files in my RSS reader and watch the changes and make sure I backport them all
> (spoiler: in a few months' time, there were none).
Oh, that's a good idea, thanks. Suffering through the many very inefficient ways I was working (though I'm sure there are ways around all of
them), I was indeed wondering "how am I going to keep this current going forward?".
Thanks for the feedback,
-c
> I've been trying to overlay xhtml files just like you, and it turns out
> there's no easy way to do this. Even the style directive in
> chrome.manifest files doesn't seem to take effect for xhtml files. Quite
> a shame there's no easy way to extend this...
XBL works for me although not exactly pain free.
Phil <- uses this in Flashblock
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Yes, this is a better way. More kudos! :)
> ....works like a champ. Seems so easy in retrospect. Almost... too easy.
> :-) Any problems with that?
It might be more problematic if there was much more development of the
current faceted search UI implementation expected anytime soon, but
there's not.
Having said that, if you wanted to follow-up on this victory with a
patch to core that makes the relevance/date setting persistent via a
preference that gets toggled when you toggle the UI mode, you could
obsolete your own extension. It seems like a reasonble behaviour to me;
I'll ping clarkbw the UX dude for whether he would sign-off on that.
Andrew
Sorry, I really can't devote any more time, but if I someday get an itching to dive back in to Thunderbird world, I will definitely remember the
idea (sounds correct to me, too).
-c
Ok, if anyone is still reading this thread :-), here's the extension to achieve this:
https://addons.mozilla.org/en-US/thunderbird/addon/265079/
Let me know if you have any problems with it; website:
http://caseyconnor.org/jl/srsbdnr
I'd appreciate any comments or rating on AMO.
Thanks,
-C
Dan
Hopefully it proves to be a persistent itch :)
For posterity, clarkbw signed off on the idea.
Andrew