Re: [DQSD-Users] A more easily customisable search menu...
Monty & Glen, Glenn Carr wrote: You might want to check out the qsfreq.xml [1] search... 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. 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]. Cool. I like the thinkingI know I would want more on the menu than I regularly use though. How about if disabled searches were renamed with a prefix (disabled_) rather than a postfix and so still remain xml files. If the file name begins with the prefix the parser code could just get the help tags from the xml but not parse the search itself, that would only be done for the non disabled searches. I assume this would make things quicker while still having some info about the disabled searches, eg. the disabled searches could then be displayed under a sub menu or something, so they could be looked at if desired. If this was possible this would still not give the ability to toggle on and off individual searches. Could this be done via a file like Monty talks about, that is rebuilt on each load and would list the enabled status for each searchhow to get an interface to this to toggle the searches though 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 element, with the default being en, or something similar. If there was work being done on a real enable/disable capability, I would be happy to take on this rather tedious task :-) Cheers, Tom. --- 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
RE: [DQSD-Users] A more easily customisable search menu...
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 element, with the default being en, 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 > > > > > > > --- >
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
[DQSD-Users] A more easily customisable search menu...
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? Ok, I'll start throwing out an ideaeverything is built on the fly from xml files so it might be hard to get something more ingrained. A bunch of searches will not be used unless someone is interested in accessing information for the USA, Australia, UK, etc. How about having a country tag in the xml files if they are not generic? I know this would mean touching a bunch of the xml files before the next release., but I think it might improve dqsd. If you decided not to see the uk searches I do not know how this would disable the relevant xml files, the only way of doing that seem to be changing the extension (with the script generator). Could be entries in localprefs.js to specify what country searches to see? That's not going to stop them loading though is it ...maybe it would be just a matter of adding this country option to the script generator page? Or maybe it's just a matter of going though the xml files before the next release and cleaning the categories up. If the search is country specific, then add the country as the primary category... Any thoughts? Cheers, Tom. http://www.moonbade.com/stuff --- 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
