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.

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. If I type a phone number I want the reverse lookup result. If
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).
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.

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. 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";

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"
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 looked around the DQSD and SF sites and don't see a roadmap. Are
there any milestones for releases beyond the next one "to include
support for XP-SP2?

Regards,

Shawn K. Hall
http://12PointDesign.com/
http://ReliableAnswers.com/

'// ========================================================
       To err is human.          To correct is debugging.




-------------------------------------------------------
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

Reply via email to