FARR Plugin Idea Holy Grail - DQSD (400 searches)

[joes_garage]

Hi all.

There's this launcher kind of a tool that I've been using for years now that is called Dave's Quick Search Deskbar (http://www.dqsd.net/).
The nice thing about this launcher is the hundreds (391 as of version 4.0.0.3) of web based searches it includes!!!  Some of the searches include, but are not limited to: IMDB, All Music Guide, CNN, MSDN, patent search, amazon, eBay, UPS tracking...  The list goes on and on and on...
These searches are written in javascript, and there seems to be some xml format to fully describe them.
So, I don't know if it would be possible to write an abstraction layer to be able to leverage all these searches, but that would be awesome!

cheers,

[mouser]

that's a very interesting idea.. worth looking into.

having gone and looked at all the searches available, i think this is a great idea, and should be done.
the only question is whether support for the dqsd searches should be built into FARR core, or should be done as a plugin for FARR (ie a plugin that knows how to load a bunch of dqsd search files and use them).

because the dqsd's use javascript, this might be a good candidate for czechboy's insane plugin coding skills using ecaradec's javascript plugin sdk for farr..

[mouser]

We should start a new thread for this dqsd plugin idea and start by begging czechboy and/or ecaradec to work on this.

The dqsd search addons consist of a standalone xml file which includes a description and then some javascript that knows how to execute the search.  You can download and look at them here: http://www.dqsd.net/...dqsdtoc/searchtoc.pl

An example of a really simple but useful one is jsx.xml which simply lets you execute any javascript code you type in the search box.

A more complicated one with arguments is dmda.xml which demonstrates how forms are used to get user input, etc.

The nice thing about writing a plugin to handle dqsd search xml files is that it would then open up FARR scripting to be even EASIER for others to write javascript plugins using this interface.  It's sort of one step removed and simplified from the original javascript sdk for FARR by ecaradec.

A wonderful idea, i hope we can convince ecaradec or czechboy (or even someone new) to go for this.

Since I'm back to coding on FARR as we speak, I stand ready to help add any functionality to FARR that is needed.  One thing that might be desired is to add an html-rendering view mode for the FARR window as an alternative to the richview memo view mode -- might be useful for this project and others.

[nitrix-ud]

Since I'm back to coding on FARR as we speak, I stand ready to help add any functionality to FARR that is needed.  One thing that might be desired is to add an html-rendering view mode for the FARR window as an alternative to the richview memo view mode -- might be useful for this project and others.

html-rendering view mode is a must
showfile is good but showhtml is even better

i already imagine some nice aliases, for example a google image search

showhtml http://images.google.com/images?as_q=$$c&hl=en&output=images&svnum=100&btnG=Google+Search
it would show the images right into FARR !

or one could use http://www.tiddlywiki.com/ as a note manager right into FARR

one could use it as a start page like opera quick dial...

applications are endless...

while you are at it mouser, please fix a small pb concerning showfile and showmemo
if you have a showfile or showmemo command as a second result of an alias (or third, fourth, etc.)
the ESC does not select the search box... so you cannot close FARR by using ESC twice, you have to use the mouse ! to reselect the search box...
very annoying

cheers, nitrix

PS: for the showhtml command, i think that handling links should be closely considered...
my opinion is that new windows should open in the default browser while regular links should open in FARR
and shift+click should force the opening of the page inside the default browser...

one last suggestion there should be a switch when invoking a showhtml command to tell FARR if it should close on click or not
showhtml ....htmlfile.... \CLOSEONOPENINGNEWWINDOW

[joes_garage]

The nice thing about writing a plugin to handle dqsd search xml files is that it would then open up FARR scripting to be even EASIER for others to write javascript plugins using this interface.  It's sort of one step removed and simplified from the original javascript sdk for FARR by ecaradec.

A wonderful idea, i hope we can convince ecaradec or czechboy (or even someone new) to go for this.

-mouser (May 05, 2008, 09:35 PM)

Being a coder myself, I can try to spare some time on it if neither czechboy nor ecaradec is interested.  I don't want to step on somebody's toes here.

[joes_garage]

The dqsd search addons consist of a standalone xml file which includes a description and then some javascript that knows how to execute the search.  You can download and look at them here: http://www.dqsd.net/...dqsdtoc/searchtoc.pl

-mouser (May 05, 2008, 09:35 PM)

BTW, I don't know what it would mean to you mouser, but all of the searches seem to be distributed on the GPL.     I'm pretty sure it means that you will not want to build support for it in FARR itself, but I'm not sure that building support for it in a LGPL plugin would be safe enough for you.  You might want to weigh in on that.

cheers,

[mouser]

that the searches are gpl will have no effect on how this is done -- we aren't going to be modifying the searches at all, or even trying to distribute them here -- the goal is simply to build a compatible sdk that can load these files and use them as is.  gpl would only be an issue if we were modifying the search files themselves and then attempting to keep that closed source, which would be silly.

Being a coder myself, I can try to spare some time on it if neither czechboy nor ecaradec is interested.  I don't want to step on somebody's toes here.

great.  i really do think this will be a very cool thing, not just because it will make all of these existing search scripts available to farr users, but because it provides a pretty easy way to let other people write intermediate custom scripts.

[czb]

Well, I am not going to code it. I am not coder and it seams pretty complex to me So go ahead joes_garage

[mouser]

Well, I am not going to code it.

[mouser]

I am not coder

what on earth are you talking about?

[mouser]

maybe ecaradec can get us started on this.. as i really think this needs a javascript person at the wheels, which rules me out.

the basic functionality of the dqsd meta plugin would be like this:

• read in all the .xml search definition files in some subdirectory of the plugin
• parse these files and record the the keywords used by each
• when farr informs of a new search string, check if it matches any of the keywords of any of the xml search files
• if so, execute the javascript contained within the search xml file

that's really it for the basics.

extra functionality would be:

• when user just types name of a search keyword, display the description from the xml file in memo/html mode of farr
• expose a few extra functions using javascript that the search file javascript code wants to call occasionally.

[joes_garage]

• read in all the .xml search definition files in some subdirectory of the plugin
• parse these files and record the the keywords used by each
• when farr informs of a new search string, check if it matches any of the keywords of any of the xml search files
• if so, execute the javascript contained within the search xml file

-mouser (May 06, 2008, 12:28 PM)

Just an idea: Don't you want to prefix these searches with something else, as to avoid clashes with other plugins? i.e. "DQ amaz /books javascript" instead of just "amaz /books javascript".

The advantage I see to that is when dealing with a dqsd search, we could display the possible switches and their meanings in it the FARR panel (e.g. in the case of the amazon search: /books /arts /dvd, etc... )

What do you think?

[mouser]

Don't you want to prefix these searches with something

yes, that makes sense.

we could display the possible switches and their meanings in it the FARR panel

yes exactly, this is easily done by simply sending the description block from the matching xml search file to the FARR memo view.

also, typing "dq" could display a list of all known search xml alias keywords so it would be easy to search for them.  even better,  allow partial searching for keywords so typing "dq a" would show all dqsd search keywords starting with the letter a.

[mouser]

I think ecaradec would be the perfect person to take on this challenge if he could be convinced to do it.. as he already has the knowledge of how to execute javascript and interface it with FARR.  I will add the html view mode to make it easier to display search descriptions, etc. and run the search+display entirely from within FARR if desired.

[czb]

I was going through the code on their page and I was completely lost with it. Seems to complex for me. I also did not realy get what those XML are for. But to be honest I did not spend much time on it.
So I ment that if there is any real JS coder, it would probably be better to let him code this. But if there is nobody then I will try to code

BTW: I am really not a coder. I have never ever studied any kind of coding and those JS plugins are just a hobby for me. (just take a look at my codes and you will see how messy they are )

[mouser]

im sorry czb, but hobby or not, you are a coder.  and you should be proud of what you've created.  of course there is always more to learn, that's true for every programmer.

as far as being confused by the the xml search files... there is nothing really to it once you understand the idea -- the xml file is just a couple of sections.  some sections are just html code which describes the plugin -- that text would just be given to FARR function to display it when appropriate.  And then the main section is just pure javascript -- there is nothing to be done with that except to "run" it.  so the dq meta plugin really doesnt have to do anything clever here, just "execute" or eval() the javascript block when appropriate.

like i said it may be that ecaradec would want to write this dq meta plugin by writing it in c++ and executing the javascript the way he does it with his javascript sdk already.  BUT i think you've really done more complicated plugins than this already, or at least very close.

i think the important thing to realize is that the dq metaplugin doesnt have to care very much at all what is in these xml files, there is very little in there that it has to be concerned with.  it just has to read the xml files in to learn which search words are available, and then send certain blocks in the xml (there are xml helper functions built into JS) to the FARR memo mode (or html mode), and execute certain blocks using JS eval() command.

[joes_garage]

Mouser, where do you think the main difficulty here? it seems to me that there's really not much JS coding to be done!  It's mainly traversing the script directory, parsing an xml file, displaying a bit of info, and launching the actual chunk of code contained in the xml file.  Am I missing something here?

[mouser]

I don't think there's all that much more to it, but i've simplified the description of all the steps, and i do think the nature of what's happening with dynamically running snippets of javascript is unusual enough that it could be a little tricky.

There are two additional things i glossed over:

• There are a few javascript functions that the blocks of search code call to interface with the main program -- these have to be discovered and implemented.  these are mainly functions to actually load the desired url, but there are some other helper functions.
• Some of the search xmls define an html form, and invoke it -- i'm not sure exactly how that works -- i think it's probably something very close to how some of the existing FARR javascript plugins present a form.

In summary -- there are enough little tricky and unusual pieces that i suspect it will require some effort to get it working.  Definitely a challenge, but not an insurmountable one.

[ewemoa]

Question 3.2 of the DQSD FAQ seems to have some detailed information regarding forms and how they fit in with creating your own searches.  A portion of 3.2 follows:

• Take a look at the original HTML form for the search, and create your own HTML form to do the same thing, but where you make all the input fields hidden instead of visible (i.e., change the type to "hidden"). Be sure to be explicit about the "action" of the form (it has to be an absolute URL).
• Write a JavaScript function that takes one text parameter and assigns values the hidden fields of your form, and then submits it. By convention, if the text parameter is blank, you should open a window into a useful page that helps you launch the search -- typically the home page of the search. If there are multiple fields in the form, then your JavaScript should use a regular expression of some kind to pull apart the single text field to fill in the multiple form fields. The easiest way to do this is with the 'parseArgs' function, which will handle the parsing for optional 'switches' and their values.
• Paste your new HTML form and your new JavaScript function into its own XML file (SEARCHNAME).xml - copy the bits of xml from an existing search xml file - and include the attribute indicating your JavaScript function name, a short name for the search, a long description, a link to a description of the search engine, your name, and so on. Be sure to follow XML rules - all your attributes need to be quoted, remember the trailing slash in the INPUT tag, etc...

At the end of 3.2, concerning the xml file there is the following:

• Your search will be callable using the function="..." name. E.g., if function="foo" then you can do the search saying "foo bar". So pick a good short name for your JavaScript function.
• Every search's NAME attribute will be displayed if the search is put on the menu, so keep it short and descriptive, like a menu item.
• If you include a LINK attribute, then the link will appear in the ? help box for the search.
• The DESCRIPTION attribute is also included in the ? help box.
• The CATEGORY attribute defines the name of the category in which the search appears in the ? help box.
• The CONTRIBUTOR attribute is for your name, and the EMAIL attribute is for your email address.

A casual browsing of some of the searches have turned up the following regarding pieces of the xml file:

• name
• category
• contributor
• link
• email
• description
• form
• script
• copyright
• created_by

"copyright" and "created_by" don't appear to serve technical purposes and the rest of the bits seem like they are described at least a bit.

Regarding the dqsd-specific javascript functions, I started making a list of candidates.  I'm not confident about these yet, but FWIW, here's what I've got so far (this was done by manual inspection of various searches):

• nullArgs
• parseArgs
• submitForm
• setSearchWindowText
• openSearchWindow

[mouser]

ewe, i've also looked again at dqsd since i believe that the work that ecaradec and you have been doing on FSubScript has made dqsd implementation infinitely more likely.

my reading is that in fact the ability to use dqsd searches is likely to be implemented in the near future and will not be that hard to do.

the last part of your post is the most helpful -- those dqsd-specific functions.. that's great that you've started making a list of those -- i didn't find any documentation yet which describes them so this is really useful. 

[ewemoa]

Some additional notes:

• parseArgs is described a bit in some of the searches - I think I came across it 8 times (search for 'usage' among the searches)
• There is at least one search that defines multiple forms - blingo.xml

That's it for the moment -- 100 searches is enough for one session (only 300 to go!), don't you think? 

[spoirier]

Just wondering if any work has been done on this.  I wish I knew how to program so I could contribute the DQSD functionality.  I hope someone here can do it. 

[joes_garage]

I got severely side tracked from my original idea to write it. There's no work from my part done on this. :-(
Mouser mentions FSubScript and the work of ecaradec. I wonder what's the status.

At this moment, I still use DQSD and FARR in conjunction, but just like last year, I would be extremely happy to be able to use only FARR.