I think changing the extension is a good idea, but independent of enabling/disabling searches. We talked about this long ago, and the primary reason was to allow an app/action to be associated with them. I.e., there may be some application that makes sense to be invoked if a user double-click on a .qs file (or whatever is chosen). But, nobody every came up with a compelling action to perform when double-clicking on the file. More later.
Regarding the enabling/disabling, I think it doesn't make sense to carry state around with the search files by renaming them in order to disable them. The filenames should remain the same. That renaming was only done as quick hack, it's not a solution. E.g., I wouldn't want to forward some 'disabled' searches to someone, that would just be weird. Anyway, wrt to default actions for a quick search file type, here are some ideas: Search [default] - Fire the search, prompting for paramters in toolbar or independent of toolbar Enable/Disable - Fire a dqsd app (or rundll.exe with dqsd.dll) to enable the search Help - Fire a dqsd app to display the help for the search Check for Update - Get latest version of search from some web-based central repository I'm sure there are more and better ideas, but I really don't think they'll even be used much, since very few people probably frequently browse the installation directory. So, I don't think it's that big of a deal to have these... IMO. Glenn ----- Original Message ----- From: "Monty Scroggins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 27, 2004 1:59 PM Subject: Re: [DQSD-Devel] Search names > my $.02 > > > > Does anyone mind changing the file extension to a custom dsqd type > > extension? I figure: > > *.qs = Quick Search Definition > > *.qsd = Quick Search (Disabled) > > > > Since *.xml is already a common name (and since we're not including > > the <?xml?> header anyway, it's not technically valid) and > > *.xml_disabled is just a bit too long (as well just unweildy)... I > > Unwieldy? how so? > > I find it helpful to be able to tell what file is by looking at the name. I > dont see why it matters programmatically. > > > think we ought to consider using our own extension. It would also > > provide the ability later on for auto-installation or toggling state > > of searches by assigning a content-type and/or file association > > (logic: if called file is in \*searches then toggle state, if > > elsewhere copy it over (to install); then restart dqsd). > > This whole business of having the searches renamed to disable them is not, > and was never meant to be, a viable solution to the problem of the toolbar > loading all searches. The method was always just a workaround. To me, the > solution is to maintain a list of enabled searches, and have the toolbar > query the list before loading the search. The toolbar would have to manage > the list, and the searches would never be renamed. If the search doesnt > exist on the list, it isnt loaded. The help window would still need to parse > the full directory of searches as it does now, to allow disabled searches to > be enabled etc., and upon exit, would have to be able to re-write the > enabled searches list. > > FWIW anyway.. > > > Monty > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > DQSD-Devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dqsd-devel ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
