Author Topic: NANY 2009 Release: Keyser (Read 46642 times)

ewemoa · « **on:** December 03, 2008, 06:45 AM »

NANY 2009 Entry Information

Name of Application	Keyser FARR Plugin
Version	1.0.1.7
Short Description	Access Web Browser Searches via FARR
Supported OSes	WinAll
Web Page	n/a
Download Link	http://ewemoa.dcmembers.com/Plugins/Keyser/Keyser.zip
Checksums	MD5: b0b8514fc69fc45cfc6abcae835183a0, SHA1: 839198124f7fee0a898f4e2da97c2f77c49bd297
System Requirements	Requires Find and Run Robot (FARR) at least version 2.34.01
Version History	None yet
Author	ewemoa

Description
The initial motivation for this plugin was to enable FARR to reuse the searches already available in one's local installation of Firefox -- those available via its Search Bar / Search Box. Firefox makes use of OpenSearch plugins to provide this functionality. OpenSearch plugins are used by Firefox, IE 7, and other apps to allow one to search various sites more conveniently and quickly. For those interested, there is more OpenSearch-related info at:

http://mycroft.mozdev.org/
http://www.opensearch.org/Home

As it stands now, the plugin has some level of support for the following browsers:

Firefox 3 (2 might work, but I didn't test)
IE7 (8 may end up working, but who knows?)
K-Meleon (not as customizable as the other two)

I haven't decided whether to continue developing this plugin at this point. Whether I continue may depend on the level of success I have with cleaning up the existing code

Screenshots

Usage

Installation

The installation flow is the same as other FARR plugins:

Unpack the archive (probably a zip file) into FARR's Plugins directory
If FARR is running already, tell it to reload plugins (e.g. via the 'goreload' alias)
If FARR is not running, start it up

Configuration may be necessary to indicate to the plugin where to look for browser-maintained searches. There is a detailed README.txt included in the plugin.

Using the Application

Bring up FARR.
Type: ks Amazon:little schemer
Choose one of the results (e.g. via numeric keypad).

The usage is modeled after the SokuGin Alias -- more details are available for that at its forum thread.

Uninstallation

One way that may work is:

Quit FARR
Find and delete the plugin's folder from FARR's Plugins directory

Perry Mowbray · « **Reply #1 on:** December 03, 2008, 06:56 AM »

Teaser -- Keyser ??

I can hardly wait!

ewemoa · « **Reply #2 on:** December 04, 2008, 04:09 AM »

Ah, I missed that as I had been thinking of the following when naming:

https://secure.wikim.../en/wiki/Keyser_Soze

But, this is actually a good thing in this case because there is a bit of recursive weirdness going on here...well, at least there is in my mind

Anyway, hope to have something for people to test soon!

mouser · « **Reply #3 on:** December 04, 2008, 09:28 PM »

Been testing this with ewemoa privately, all i can say is: wow!!
this is something farr users asked for quite a bit and the implementation is great.

deviantopian · « **Reply #4 on:** December 05, 2008, 02:41 AM »

Ah, I missed that as I had been thinking of the following when naming:
https://secure.wikim.../en/wiki/Keyser_Soze
-ewemoa (December 04, 2008, 04:09 AM)

Heh... guess what I was thinking of when I chose the name of my website:
http://theunusualsuspect.com/

Great minds think alike.

ewemoa · « **Reply #5 on:** December 08, 2008, 09:04 AM »

A test release is available.

This version was repackaged to not use FSubScript for various technical reasons.

There is a fairly detailed README.txt file included.

Feedback welcome

mouser · « **Reply #6 on:** December 08, 2008, 09:10 AM »

Note that i think Keyser might require a new version of FARR that people dont have yet, to work optimially; i will update FARR today.

ewemoa · « **Reply #7 on:** December 08, 2008, 06:57 PM »

Ah, good point.

I've uploaded a version with a work-around and tested it locally -- I think the newly uploaded version should work w/o upgrading FARR beyond 2.33.02.

ewemoa · « **Reply #8 on:** December 09, 2008, 12:39 AM »

After some more testing I discovered a problem. I've made a fix and uploaded a new version of the plugin. Now it looks like at least FARR 2.34.01 [1] is necessary for the plugin to work correctly.

[1] I checked right before posting and this version looks available for download - thanks mouser

ewemoa · « **Reply #9 on:** December 09, 2008, 01:12 AM »

I've changed the topic title from "Teaser" to "Release", updated some info, and uploaded some screenshots.

czb · « **Reply #10 on:** December 09, 2008, 10:52 AM »

Hi,
I can not extract the zip file. It looks like it is corrupted.

ewemoa · « **Reply #11 on:** December 09, 2008, 08:32 PM »

How strange...

I just downloaded and extracted w/ the following browsers with no difficulty:

Iron 0.3.155.0
IE 6
K-Meleon 1.5.1
Firefox 3.0.4

I wonder what the problem is.

I've added checksum information for MD5 and SHA1 to the original post, so may be you can check what you get on the file you download.

deviantopian · « **Reply #12 on:** December 10, 2008, 02:24 AM »

The MD5 checks out okay, but I also get "does not appear to be a valid archive". Could your compression software be zipping it in a non-standard way?

Perry Mowbray · « **Reply #13 on:** December 10, 2008, 02:56 AM »

It's an odd zip file

Download manager extracts it OK
Compressed Folders fails
Nexus opens the file but it's empty

...very odd

ewemoa · « **Reply #14 on:** December 10, 2008, 04:43 AM »

All: sorry for the hassle w/ the compressed file and thanks for taking the time to try so far.

I've uploaded a new version, this time compressed using different options (thanks deviantopian, perhaps that did the trick) and I verified decompression using Compressed Folders (thanks, Perry for listing what you tried).

Also, thanks czb for the feedback about the downloaded file not working for you originally

The new version has removed some limitations and provides some enhanced functionality via the kstools alias -- if interested, please see the included README.txt.

ewemoa · « **Reply #15 on:** December 11, 2008, 08:59 AM »

I haven't uploaded the following yet, but I think I have some support for IE7 working -- thanks to ecaradec's efforts on enumerating keys in the registry via FScript.dll.

Of the browsers mentioned in the original post, the hardest one to do is likely to be Chrome -- I'm not sure if that's even practical.

K-Meleon and Opera both look doable though. I don't suppose there's anyone who has a preference

Perry Mowbray · « **Reply #16 on:** December 11, 2008, 07:51 PM »

No, you've covered my needs

Though if I had a further preference I would have said Crome

ewemoa · « **Reply #17 on:** December 11, 2008, 09:28 PM »

Thanks for the feedback -- just curious, have you happened to have tried the plugin out and if so, does it work for you?

Regarding Chrome: I've been using Chrome (actually, I'm currently using Iron) as my main browser since pretty much when it was announced so I'd like to support it too. Unfortunately, I don't yet see a good way to achieve the end in question.

AFAIU, Chrome makes use of SQLite a fair bit and from what I understand so far, the way it accesses some (or perhaps all) of the SQLite dbs seems to complicate access to them. While Chrome is running I haven't yet succeeded in interfacing with the specific SQLite db that contains the information which would be relevant to Keyser.

I'm hoping there is something I'm missing and that it is a straight-forward matter to address.

There is also the matter of how to read information from the SQLite dbs (assuming access is possible [1]) -- I haven't determined a good way to do this just yet.

[1] An ugly work-around might be to try to access (or copy) the relevant db in question when Chrome is not running, but...ewwwwww!

mouser · « **Reply #18 on:** December 11, 2008, 09:36 PM »

i think working hard to support chrome searches is way overkill..
the real power of keyser seems to be the ability to use these generic opensearch configurations; even if keyser never was able to find the firefox installed searches, as long as you could manually download new opensearch configuration files, that would be 99% of what is beneficial about keyser.

Perry Mowbray · « **Reply #19 on:** December 12, 2008, 03:24 PM »

i think working hard to support chrome searches is way overkill..
-mouser (December 11, 2008, 09:36 PM)

I have to agree with mouser

, especially as I generally always use FF. There are a number of reasons I don't use Chrome all the time (this is just another one)

Thanks for the feedback -- just curious, have you happened to have tried the plugin out and if so, does it work for you?
-ewemoa (December 11, 2008, 09:28 PM)

Sorry: it certainly does! I got a little confused with "choose the result" as there isn't a result list from the search, just which search to choose. I thought there was a way in FARR to add to the search field? When I select one of the search items, it does not add the websearchname to the string in FARR (which would be very useful), it opens the search page.

It's not possible to use the results from xml? for example the firefox search can return an xml file from: https://addons.mozil...ss/?q=context+search

ewemoa · « **Reply #20 on:** December 14, 2008, 03:24 AM »

I got a little confused with "choose the result" as there isn't a result list from the search, just which search to choose.
-Perry Mowbray (December 12, 2008, 03:24 PM)

Aha. I have updated the README.txt to try to be a bit clearer. Thanks for mentioning this.

I thought there was a way in FARR to add to the search field? When I select one of the search items, it does not add the websearchname to the string in FARR (which would be very useful), it opens the search page.

Let me see if I understand appropriately. Suppose that the following steps are taken:

1. Bring up FARR
2. Type 'ks' (w/o the quotes)
3. Select one of the results

What happens now is that the selected web search is opened - since no query term has been specified the result of the action may not be viewed as all that useful. IIUC, the suggestion is that instead of what happens now, FARR's text field should get updated w/ the name of the web search followed by a colon. Subsequently, one may enter a query term and proceed w/ a search.

Does that seem like a fair understanding?

It's not possible to use the results from xml? for example the firefox search can return an xml file from: https://addons.mozil...ss/?q=context+search

Do I understand correctly that the suggestion is to have the results from performing the web search appear in the results window of FARR?

Perry Mowbray · « **Reply #21 on:** December 14, 2008, 04:27 AM »

Let me see if I understand appropriately. Suppose that the following steps are taken:

1. Bring up FARR
2. Type 'ks' (w/o the quotes)
3. Select one of the results

What happens now is that the selected web search is opened - since no query term has been specified the result of the action may not be viewed as all that useful. IIUC, the suggestion is that instead of what happens now, FARR's text field should get updated w/ the name of the web search followed by a colon. Subsequently, one may enter a query term and proceed w/ a search.

Does that seem like a fair understanding?
-ewemoa (December 14, 2008, 03:24 AM)

Yes: that's it exactly!

Is that possible, I thought that was part of FARR functionality?

Also, if you've forgotten the text string that has to be used in the query, it would be neat to have that text string included somewhere (as a reminder).

It's not possible to use the results from xml? for example the firefox search can return an xml file from: https://addons.mozil...ss/?q=context+search

Do I understand correctly that the suggestion is to have the results from performing the web search appear in the results window of FARR?
-ewemoa (December 14, 2008, 03:24 AM)

Yes: you are either very clever or we're on the same wavelength

I thought that this would be very handy, but I guess it would require knowledge of the xml results url?

ewemoa · « **Reply #22 on:** December 14, 2008, 05:06 AM »

Yes: that's it exactly!

Is that possible, I thought that was part of FARR functionality?
-Perry Mowbray (December 14, 2008, 04:27 AM)

It might be. I haven't thought through how it might be done. On the one hand it does seem like friendlier behavior to me -- on the other hand, that's not how SokuGin behaves currently (which is one of the things I've been using as a model of behavior). I would be inclined to try to do this if I could make SokuGin do the same

Also, if you've forgotten the text string that has to be used in the query, it would be neat to have that text string included somewhere (as a reminder).

Is the suggestion here about giving a reminder as to what the syntax is for using the plugin?

Yes: you are either very clever or we're on the same wavelength

Well, there is at least one more possibility -- I remember there is a phrase like "Every dog has his day" and in this case, it might apply to me being canine-like today.

I thought that this would be very handy, but I guess it would require knowledge of the xml results url?

There are a number of potential issues IIUC. One is that I don't think that every place that has an OpenSearch plugin provides results in XML format (a guess). Another is that a number of search-providing places take a dim view of scraping their search results (e.g. the last time I checked, Google wasn't crazy about this w/o one jumping through a bunch of hoops which I'm not sure are practical to jump through and I'm not sure I'd want to either). Yet another is, to accomplish this, it seems that one would end up having to custom-process results from each different search provider. There may be more, but this ~~margin~~ post may be too narrow to contain them

Perry Mowbray · « **Reply #23 on:** December 14, 2008, 06:36 AM »

Also, if you've forgotten the text string that has to be used in the query, it would be neat to have that text string included somewhere (as a reminder).

Is the suggestion here about giving a reminder as to what the syntax is for using the plugin?
-ewemoa (December 14, 2008, 05:06 AM)

Yep; which I guess is also the object of the previous suggestion

Yes: you are either very clever or we're on the same wavelength

Well, there is at least one more possibility -- I remember there is a phrase like "Every dog has his day" and in this case, it might apply to me being canine-like today.
-ewemoa (December 14, 2008, 05:06 AM)

I'm pretty sure that's more in reference to being "Top Dog", which I think is kinda appropriate for this Plugin: the more I play with it the more I like it!!

I thought that this would be very handy, but I guess it would require knowledge of the xml results url?

There are a number of potential issues IIUC. One is that I don't think that every place that has an OpenSearch plugin provides results in XML format (a guess). Another is that a number of search-providing places take a dim view of scraping their search results (e.g. the last time I checked, Google wasn't crazy about this w/o one jumping through a bunch of hoops which I'm not sure are practical to jump through and I'm not sure I'd want to either). Yet another is, to accomplish this, it seems that one would end up having to custom-process results from each different search provider. There may be more, but this ~~margin~~ post may be too narrow to contain them
-ewemoa (December 14, 2008, 05:06 AM)

Yes, I don't disagree with you at all (in general I would have thought that the results url would not be part of the OS definition, and so couldn't be incorporated in your Plugin [a guess]), but also, I'd think that if a site provides an xml view of a search result then that is not scraping their results at all. But I'm not certain and happy to be corrected $:-\$

ewemoa · « **Reply #24 on:** December 14, 2008, 08:11 AM »

Also, if you've forgotten the text string that has to be used in the query, it would be neat to have that text string included somewhere (as a reminder).

Is the suggestion here about giving a reminder as to what the syntax is for using the plugin?
-ewemoa (December 14, 2008, 05:06 AM)

Yep
-Perry Mowbray (December 14, 2008, 06:36 AM)

Although I may be mistaken, I have this vague memory that there might be some upcoming changes to FARR that make it easier to get help on the currently functioning plugin. I'm thinking that may be I can leverage those when they come about. I agree it would be good to quickly find out what the syntax is -- I just don't currently have what I consider a good way to achieve this. The key is the word "somewhere" in the original suggestion

Yes, I don't disagree with you at all (in general I would have thought that the results url would not be part of the OS definition, and so couldn't be incorporated in your Plugin [a guess])

I may be mistaken about this, but I was under the impression that the specification provides something along these lines, but it is optional (I believe there is something about RSS and something about Atom for returning results).

I'd think that if a site provides an xml view of a search result then that is not scraping their results at all. But I'm not certain and happy to be corrected $:-\$

It has been a while since I checked, but IIRC in Google's case there was quite a bit on this [1] -- including having a "key" to make use of their XML results.

I didn't mention another potential technical issue -- in theory it sounds neat to be able to work w/ results inside FARR, in practice though, imagine what happens after you request that a search is performed. You end up waiting -- and while you are waiting, if FARR is involved, it makes it difficult to use FARR for something else (as I understand it, FARR isn't designed to work on multiple tasks simultaneously, especially if they all involve the FARR window). I think letting a web browser handle the request works out ok for the most part -- I usually want to view the individual result pages in a web browser (perhaps I am missing use cases you have in mind -- would you mind elaborating a bit on this point?). Also, it's harder to revisit the lists of results from inside FARR whereas w/ a web browser I find this is much easier (especially w/ tabs and opening recently closed ones).

[1] http://www.google.com/accounts/TOS
http://www.google.co...terms/api_terms.html