GNOME Bugzilla – Bug 599974
bring back search.php
Last modified: 2009-12-30 13:39:07 UTC
While the new javascript search engine is a good thing, for smaller projects or projects without a webserver running php. It has some disadvantages in big projects, the js search is slow and unusable (yes I'm using a modern browser, FF3.5.4). There are also some guys who reject to even use javascript, they can't use it. So there should be an alternative solution, it is hopefully not that much work to revive the search.php. You may make it optional through a parameter in the doxyfile. WBR Danny
Could you give me an indication about the size of the search results files? i.e. a listing of sizes of html/search/all*.html would help me to get an idea. There are also alternatives already to create searchable doxygen output: - Qt help: a platform independent indexer and browser - HTML Help workshop: compiled html help including a search index. Compiler is windows only, chm viewers are available for multiple platforms. - DocSets: for XCode integration on Mac OS X. Did you consider using any of these alternatives?
No I didn't considered one of these Alternatives, as it should be usable over web. Generating the complete documentation takes a lot of time. Feel free to test the search for yourself: http://doxygen.reactos.org/ Here is the list. 1135 Nov 7 05:07 all_30.html 2371 Nov 7 05:07 all_33.html 1129 Nov 7 05:07 all_34.html 1129 Nov 7 05:07 all_35.html 1426 Nov 7 05:07 all_38.html 2850 Nov 7 05:07 all_3a.html 5813856 Nov 7 05:07 all_5f.html 5104291 Nov 7 05:07 all_61.html 3461647 Nov 7 05:07 all_62.html 10263570 Nov 7 05:07 all_63.html 13399489 Nov 7 05:08 all_64.html 4100170 Nov 7 05:08 all_65.html 5926207 Nov 7 05:08 all_66.html 8332901 Nov 7 05:08 all_67.html 5062697 Nov 7 05:08 all_68.html 9873623 Nov 7 05:08 all_69.html 500658 Nov 7 05:08 all_6a.html 2312490 Nov 7 05:08 all_6b.html 5827746 Nov 7 05:08 all_6c.html 7133636 Nov 7 05:09 all_6d.html 5495998 Nov 7 05:09 all_6e.html 3464620 Nov 7 05:09 all_6f.html 9242606 Nov 7 05:09 all_70.html 453060 Nov 7 05:09 all_71.html 6641897 Nov 7 05:09 all_72.html 11899214 Nov 7 05:09 all_73.html 6797403 Nov 7 05:10 all_74.html 7698035 Nov 7 05:10 all_75.html 2822833 Nov 7 05:10 all_76.html 4556461 Nov 7 05:10 all_77.html 4385318 Nov 7 05:10 all_78.html 340551 Nov 7 05:10 all_79.html 333096 Nov 7 05:10 all_7a.html 323133 Nov 7 05:10 all_7e.html
Thanks for the info. I agree that is quite slow (but not completely unworkable). It took about 5-30 seconds before the results appear. I did notice a couple of problems with the way the search is embedded on your site: - the search results window appears right aligned with the search box, making most of the search results appear outside of the window! I suggest to try to copy the behaviour shown when you enable GENERATE_TREEVIEW. - on pages within a sub dir, the searchBox variable cannot be found, probably the search.js script is searched at the wrong location (i.e. the custom header does not use $relpath for the search script). Meanwhile I'll see what it takes to reintroduce the old search engine.
I'll reinterduce the old search engine under the SERVER_BASED_SEARCH option in the next subversion update.
Will wait for it too! JS-based solution has one more flaw: it does not perform string search inside item's name, it performs silly strings match check starting always from the first char of item name. If you type "SSA" it will find "SSAData", but will not "Tm_SSAData". IMHO such approach is close to useless. :(
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.2. 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).