GNOME Bugzilla – Bug 541234
Re-implement Search form for local browsing using JavaScript
Last modified: 2009-08-20 10:12:55 UTC
Doxygen allows users to search for terms, but search.php only works when the page is served from an HTTP host that understands PHP. It is common for Doxygen material to be delivered to users as locally stored files. I would like to suggest that search.php be re-implemented in JavaScript. This will work in typical browsers. If we use XMLHttpRequest objects to open search.idx with partial GET, then it will work both locally and across HTTP, although opening many files will be slow across HTTP. So I suggest keeping search.php and making this an option (it will need a change to the HTML generated for each normal page). A limited work-around is to generate Windows HTML Help .CHM files and use the search feature built in to that browser. This requires Windows for the build platform, amongst other limitations. I may be able to help in implementing this.
Hi, I am going to start working on this next week. Regards, Mitchell
Note that this http://labs.trolltech.com/blogs/2008/06/20/introducing-doxygen2qthelp-create-qch-files-from-doxygen-finally/ is another solution that is mostly complete now and works across platforms.
Hi, We decided to continue with implementing the search in Javascript, and I now have it working. I have added a new option to the Doxyfile, LOCALSEARCH, that switches on or off the ability to search the HTML output when accessing it directly from the filesystem. With SEARCHENGINE and LOCALSEARCH both set to YES, the search box appears on all output HTML pages as usual. When the user enters their search query and hits return a Javascript 'onSubmit' event is triggered and runs chooseSearch() to decide whether the file has been opened via an HTTP server or directly from the filesystem. If it has been opened directly from the filesystem the action of the search form becomes "local-search.html". If it has been opened via an HTTP server, or if javascript is disabled in the browser, the action remains as "search.php" and the request is processed in the usual way. The file local-search.html is generated by Doxygen and contains <script> references to the search index in the form of some Javascript arrays and the search algorithm implemented in Javascript. Its body has an 'onLoad' event that runs the search and outputs the results, being careful to preserve the headers and footers. I have also edited search.php to display an error message to the user (and hide the php source) if they do try to search HTML output being accessed directly from the filesytem when this capability has not been switched on. I have tested with the following browser versions: IE 7 Firefox 2.0.0.16 Firefox 3.0.1 Opera 9.21 When the index becomes very large (eg 38MB) all browsers but Firefox 3 fail to run the javascript search and either report no results, or a javascript syntax error. No doubt Firefox 3 has its limit too. I look forward to any comments and suggestions you may have on my patch. Regards, Mitchell
Created attachment 115194 [details] [review] Patch to provide a local search facility
I don't know if it is something wrong with my patch, or with the build system, but when I applied it to a clean check-out of the trunk it failed to build the .h versions of the javascript files. I had to manually add the dependencies: local-search-globals_js.h \ choose-search_js.h \ local-search_js.h on htmlgen.o in Makefile.libdoxygen
This bug report had the version set to "latest". Since this is a moving target I changed it to 1.5.7.1. If you happen to see that the problem is fixed in 1.5.8, then please close it.
FYI: The next release of doxygen will feature a javascript based search engine (you can already get a first version from subversion). It uses a different approach allowing to search for symbols and show the results while typing. It also avoids big javascript files containing the full search index by splitting them in smaller index pages per letter.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.0. Please verify if this is indeed the case and reopen the bug if you think it is not fixed (include any additional information that you think can be relevant).