Tom, Monty, You might want to check out the qsfreq.xml [1] search I submitted a couple of weeks ago. I created it for exactly the problem to which you're referring. I finally got annoyed enough about the fact DQSD was loading 300+ searches, and I was only probably only using a handful, to do something about it.
A few times I started to go back through my history file to determine which searches I actually used, but it was too much work to organize and determine the searches used just from the history log, so I never finished it. So, this qsfreq.xml tool records my actual search usage frequency. Attached is a screenshot of it displaying the searches I've used in the last 10 days or so. Now, the cool thing is that qsfreq will let me disable the unused searches at any point with the /disable_unused switch. If I find that I need a search that I've disabled, I can call qsfreq with the /enable_all switch, execute the switch, and then call qsfreq /disable_unused again. The search I just used won't be disabled because it will be in the qsfreq log. It 'disables' the searches by renaming them to '.disabled' instead of '.xml'. Of course, this completely removes them from the search help. I also changed the install to remove any of the disabled searches, so that after all installs, the complete set of searches would be re-enabled. Of course, the qsfreq log would still be there, so that you could disable unused searches immediately after a new install. You can enable qsfreq by setting the variable (qsfreqLogSearchFrequency) documented in preferences.js [3]. The search isn't completely autonomous, because it requires a small change to search.htm [2]. BTW, if someone wants to take the time to add a 'locale' property to the searches as Tom suggested, it's probably a good idea. At the point when we finally add a real enable/disable capability, it would be nice to have this locale property. I'd recommend just adding a <locale/> element, with the default being <locale>en</locale>, or something similar. Thoughts? Glenn [1] http://cvs.sourceforge.net/viewcvs.py/dqsd/dqsd/searches/qsfreq.xml?rev=1.3&; sortby=date&view=log [2] http://cvs.sourceforge.net/viewcvs.py/dqsd/dqsd/search.htm?r1=1.190&r2=1.191 &sortby=date [3] http://cvs.sourceforge.net/viewcvs.py/dqsd/dqsd/preferences.js?r1=1.61&r2=1. 62&sortby=date > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:dqsd-users- > [EMAIL PROTECTED] On Behalf Of Monty Scroggins > Sent: Monday, February 20, 2006 9:39 PM > To: dqsd-users@lists.sourceforge.net > Subject: Re: [DQSD-Users] A more easily customisable search menu... > > Tom Corcoran wrote: > > As more and more searches get added I am concerned about the clutter > > on my dqsd menu. When I am looking to remind myself what searched I > > have forgotten about I do not want through though ones I will never > > use. [Maybe memory should be a concern but since I got rid of the old > > machine a few years ago I have not looked into performance gains by > > disabling a bunch of the searches] > > > > I know we can use the script generator > > http://www.master-minds.net/cgi-bin/disablesearches.cgi > > to disable scripts, and maybe that's enough but ideally would it not > > good to have something more fluid? > Yeah there has long been a need to have some kind of mechanism of > disabling searches that arent needed.. The performance gains of not > loading 300+ searches is pretty noticeable.. My script renaming > utility was meant only as a crude workaround.. > > > A problem exists, in that all of the searches have to be parsed > initially to be even available on the menu for enabling or disabling.. > The search code doesnt have to be loaded to memory but the xml would > still have to be parsed on startup... So I guess if there was some sort > of on-the-fly enabling and disabling of searches, the startup time would > still be kind of slow.. Memory would be gained though... > > Maybe there could be a built in mechanism that would allow the user to > create a snapshot of the searches which are available and unavailable > and store the data to a file that could be loaded at dqsd startup before > any search xml files are parsed. The file would control which searches > are loaded, and could contain enough information about *all* the > searches that the help menu items could still be created without parsing > all the xml files. This would speed the startup since all the searches > wouldnt have to be parsed anymore. The user would only have to go > through all the searches once to get the configuration set. > > > Good Idea? Bad Idea? > > Monty > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > To unsubscribe visit: > https://lists.sourceforge.net/lists/listinfo/dqsd-users > DQSD-Users@lists.sourceforge.net > http://sourceforge.net/mailarchive/forum.php?forum_id=8601
qsfreq_display.png
Description: PNG image
