Re: [DQSD-Devel] autodetection, atomic selection, roadmap

[Monty Scroggins]

Shawn K. Hall wrote: Hi Monty, Personally I think all the special handling should be removed unless it is needed for the toolbar to function properly. Most of the special handling is left over from when the toolbar only had a few builtin searches with no searches directory full of search xml files. People should not have to memorize 325 different search terms. of course not.. is anyone even attempting this?  nah.... If I put a mathematical equation into DQSD, I expect it to return the result. 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. If I type a phone number I want the reverse lookup result. If Why?  Why is a phone number lookup a special function?   Its important to you, but why is it a standard feature?  I cant remember the last time I did a phone number lookup..  and if I need to do one, I would most likely go to the help menu to see the prefix to use to do it.. 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? Sure there are searches to provide that functionality, but I'd much rather not have to prepend what I'm already typing with another 5 characters or so for no good reason. well if typing a few chars in is a problem I suppose they could be aliased to a single character.. I *seriously* rely on the auto-handlers for most of my use of DQSD. Phone numbers, IP addresses, and URL's make up at least 90% of my searches. So much so that I seriously considered replacing the 'default' search with ARIN because I use it far more than Google. But that's just me. The way I see it, if the content can be reliably presumed to be a specific type (ip address, CIDR, mathematic equation, URL, phone number, currency... These should be parsed and treated appropriately. 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? Should we automate the timer and alarm features?  nah.. make the core bundle as lean as possible and allow another layer of features to added in. I use the calendar constantly too..  and there was talk at one point of moving it into an add-on because it adds so much bloat, and not everybody cares about having a calendar..  I would have to go through more install process to get it enabled, but it is something I find valuable and that makes it worth it..  If someone wants *alternative* features they can prefix with "gg " for google or the search term for the other search they want to use. By providing hooks for searches to be explicitly enabled and disabled as auto-handlers it would effectively give more atomic control over the exposed functionality, making it a better tool. However, I think removing the auto-handlers altogether, especially after having them as part of the core of DQSD for so long, is really hurting our users. Perhaps a global preferences variable for people that want to disable all of them without having to know what they are, something like: autodetect_use = false; What I envision is autohandlers being enabled by default for searches just by having the search turned on. If the user wants to disable a specific handler, like phone number detection, they can use: autodetect_phone_use = false; Or: autodetect_ip_use = false; 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?  allows me to disable the auto-search functionality of a drag+drop, but what I'd really like is for it to be handled just like a def() so I don't have to take three extra steps to prevent it from googling for an IP address, for example. Ultimately, what I'd really like is to be able to have a design mentality within the searches that provides for allowing preferences to override natural behavior or set new default behavior for nearly everything that happens. All user interaction; all the events. There are searches that I alias to themselves just so I can set specific parameters I'll *always* use, since the searches don't provide a simple way of exposing atomic selection within default options. 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.  FWIW... Monty