Hi Monty, > > People should not have to memorize 325 different > > search terms. > > of course not.. is anyone even attempting this? nah....
I don't think anyone uses more than a handful of the existing searches, which is why auto-searches are so important. Please note that my desire is to provide the OPTION of enabling or disabling the auto-handlers in addition to the searches. Currently the only way to disable an autohandler is to completely disable a search. That would not be necessary if the autodetection scheme used a 'registration' type method for appended the autohandlers to the queue. > > If I type a URL I expect it to open a browser to > > that page. > > The URL auto-detection to me is part of the core > functionality. I would not be in favor of removing > it. Do you object to providing the *option* of passing that URL through a search instead of just opening the browser? > > If I type a phone number I want the reverse lookup > > result. > > Why? Why is a phone number lookup a special function? > Its important to you, but why is it a standard feature? I lookup at least 2 phone numbers a day. Sure I can # it to find out the reverse, but it's nowhere near as efficient as just putting in the number. Again, what I want is *not* to make DQSD less useful, but to make it more user-configurable. If you don't want the autodetections, turn them off, but don't eliminate the whole possibility of autohandling query terms. That would just suck. Right now you can't even disable them. I wouldn't object to disabling all of the autohandling by default ***if we could enable them with preferences or a GUI***. I also don't like the pre-defined aliases that are one character long. It drives me crazy when I try to google for something and end up on mapquest or an archive.org error page. > > I type in an IP address I'd like to return information > > about that address (and the DNS IP tools do seem to be > > a better fit for it). > > again.. why? Because I function that way. It's more efficient for me than having to dig through the menu or retype "arin <paste>" or even "a <paste>" all day long (I do ARIN lookups at least 50 times a day). > Hey I use the calculator feature constantly.. and I love > it.. but I have to admit it isn't a core function that > needs to be automatically handled. Is it really a big deal > to prefix an expression with a few letters? Yes. Especially when the majority of our users probably don't have enough ram to load the menu to find the search they want to use with any amount of speed. I've got 512mb on a P4-1.6ghz and it takes over 3 seconds to initialize the menu each time I click on the chevron, and an additional second for each submenu. ARIN would be ">>" > Computers > Networking > ARIN, or a total of five seconds minimum to find the search. Multiply that by 50/day and you're looking at a waste of 4 minutes on a tool that is supposed to make things faster for me. > Should we automate the timer and alarm features? nah.. I wouldn't object to providing the option in a search. It'd be more useful to people that use them frequently to skip typing the search name and just use "15:00 whatever". This ought to be an OPTION though, just like everything else. > > Some searches, like 'dns,' have so many options that > > you might want to also specify parameters to be used > > when an autodetection is raised: > > autodetect_ip_options = "/cidr /ipwhois /spam"; > > (cringe..) > I use CTRL+ENTER to hit .com's from a base name all the time. > Likewise, I drag and drop stuff into DQSD all the time. If it > weren't for the "select, drag, shift, drop, click, > enter" I might > have a much more enjoyable time of it. Yes, "dragdropautosearch" > > > How much of the select,drag,shift,drop,click,enter would you > be eliminating with the auto-handlers? Half of it, the shift, click and enter - though it wouldn't be a matter of disabling the auto-handler, but swapping it with something else, or providing the option of disabling it and enabling it at will. I imagine a syntax like: configure autohandlers=false; ...where configure alone would popup an interactive options window. > > Am I alone in these goals? > > I dont know if you are alone.. but you have to admit > what you described isn't exactly run-of-the-mill > usage. > > I am just leery of bloat. I'm afraid of bloat, too, but more concerned with making sure DQSD is useful to everyone and that the options exposed are useful in making sure each user gets the experience they want. To that end, I think providing programmatic access to everything is the ideal solution. A GUI should be created to provide people that have no interest or capacity to work with the code directly. Variables do not have to be explicitly defined in a search or in the parser, javascript allows you to reference variable and function names dynamically which can be based on the search name (which I think is the best way to handle it). And as far as bloat, I don't see how removing 20 lines from search.htm and replacing it with one line in each of 6 search files (a difference of -14 lines) can be considered bloat. Regards, Shawn K. Hall http://12PointDesign.com/ http://ReliableAnswers.com/ '// ======================================================== Drop your carrier ... we have you surrounded! ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Archive: https://lists.sourceforge.net/lists/listinfo/dqsd-devel
