DonationCoder.com Forum

DonationCoder.com Software => Find And Run Robot => Mouser's Zone => FARR Plugins and Aliases => Topic started by: ewemoa on December 15, 2008, 03:04 AM

Title: FARR plugin: Akete
Post by: ewemoa on December 15, 2008, 03:04 AM
Akete - FARR-specific file associations

Purpose

  FARR enables customization of the browser and/or file explorer used to "launch" URLs and files/folders respectively.  This plugin generalizes this idea for files based on filename extensions.  

  The original motivation for this plugin was to enable one to make use of and transport file associations without getting involved with the registry -- e.g. for portable application types of settings -- well, at least for files launched via FARR :)

Usage

  To customize the handling for a specific file extension, first ensure that FARR's "Program Options -> Lists -> User Variables" setting has an [Akete] section.  

  Then create a line in that section of the form:

    <extension>=<executable-path>

where <extension> stands for the (typically 3-letter) file extension in question and <executable-path> is an appropriate path to an appropriate executable.

  For example, to handle PDF files using SumatraPDF, one might use the following sort of text (assuming here that SumatraPDF.exe is the name of the executable and that it lives in D:\Apps\):

    [Akete]
    pdf=D:\Apps\SumatraPDF.exe

  If all goes well, FARR should now launch all files that end in '.pdf' using SumatraPDF.

Credits

  Thanks go out to:

    mouser
    ecaradec
    phitsc
    Plugin authors that provided source and/or comments on the forums
    DC Forums participants
    DC Supporters

Download

  Stable (http://ewemoa.dcmembers.com/Plugins/Akete/Akete.zip) MD5: 1c2fb4e40841437c48cf3f5070d9fa66
  Experimenting (http://ewemoa.dcmembers.com/Plugins/Akete/Akete-1.0.1.8.zip) MD5: 58ebf5cc5a6b2ffa1a3c76a3348fccc1

If trying the Experimental version, please make sure to install the plugin in FARR's Plugins folder and name the folder for the plugin "Akete".

  
README for Experimental Version
Akete - FARR-specific file associations

Introduction
------------

The main point of this plugin is to be able to customize how files
with particular file extensions are opened.  To achieve this end,
the user is expected to provide a configuration which specifies
associations between file extensions and corresponding methods of
opening files with those extensions.

The plugin provides additional functionality including support for:

  * multiple possible methods of opening files via context menu items

  * default context menu items (i.e. always appear in context menu)

  * overriding of method to open files via an appropriate keyword

Configuration
-------------

The Akete plugin may be configured by using FARR User Variables.

FARR User Variables are accessible via "Program Options" ->
"Lists" -> "User Variables" in FARR's Options dialog box.  The section
for Akete (may not exist unless manually created) begins with the
string [Akete].  (For more information regarding FARR User Variables,
in FARR's .chm Help File, see the section titled "User Variables -
Advanced Use" under "Advanced Use".  The rest of the text assumes
familiarity with the FARR documentation content.)

Configuration details will be demonstrated through a series of examples.
After each example a general rule will be stated possibly followed by
some related notes.

Example 1

A configuration to get files with the extension 'txt' to be opened using
Wordpad might be:

  [Akete]
  txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

Rule 1: <file-extension>=<path-to-executable>

Notes: The path to the executable may contain FARR Virtual Folder
names (see the FARR help file).  Also, file extensions do NOT contain
the period character.

Example 2

A configuration to get files with the extension 'txt' to be opened by
(possibly additional instances of) Notepad++ might be:

  [Akete]
  txt=%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

Rule 2: <file-extension>=<launch-template-string>

Notes: The launch template string allows specification of command line
arguments.  The plugin replaces the string $$1 by the path to the file to
be opened.  Do NOT use the vertical bar character in a launch template
string -- the reason for this should become clear below.

Once a file extension has been associated with a path or launch template
string, it is possible to leverage this association so that any file
specified via FARR's text edit field is opened using the associated
path or launch template string.

For the examples above, if the text in FARR's text edit field looks like:

  C:\boot.ini +withtxt

"launching" via FARR will open the file with path C:\boot.ini using
Wordpad in the case of the first example, and Notepad++ in the case of
the second example.

Notes: The keyword is assembled by prepending the file extension with the
string "with" (the default keyword prefix string).

Example 3

A configuration to override the default keyword prefix string with the
string "open" instead of "with", might be:

  [Akete]
  Options.KeywordPrefix=open

Rule 3: Options.KeywordPrefix=<keyword-prefix-string>

Notes: The user variable name is the fixed string "Options.KeywordPrefix".  
The user variable value should probably be kept to a string composed of
numbers and letters -- other values such as spaces, pluses, and the like
are not likely to work.  It may also be safer to not use uppercase letters
in the user variable value.

Example 4

A configuration to get files with the extension 'doc' to be opened using
whatever is configured for 'txt' might be:

  [Akete]
  txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe
  doc=txt

Rule 4: <file-extension>=<file-extension>

Notes: For simplicity of configuration and implementation, if a file
extension appears on the right hand side of an equals sign, it may not
appear on the left hand side of the equals sign.  Another way to phrase
this is that only one level of indirection is supported.

Example 5

A configuration to get the context menu of a file with extension 'txt'
to show context menu items for opening via Wordpad and Notepad++ might be:

  [Akete]
  txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

Rule 5: <file-extension>=<list-of-paths-or-templates>

Notes: The items in the list may be paths or launch string templates.  
The vertical bar character is reserved for separating the items so it may
not be used in a path (doesn't tend to work in Windows anyway?) or a
launch template string.  Opening of files via FARR's text edit field will
be handled using the first item in the list.  It may be worth noticing
that a single path or launch template string might be viewed as a list of
one item.

A configuration to get the context menu of a file with extension 'txt'
to show context menu items for opening via Wordpad and Notepad, but leaves
handling of opening of such files untouched if done via FARR's text edit
field might be:

  [Akete]
  txt=|%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|C:\Windows\System32\notepad.exe

Notes: One can think of the list as having an empty first item.

Example 6

A configuration to get a file without a file extension to be opened by
Emacs might be:

  [Akete]
  Options.NoExtension=%PROGRAMFILES%\Emacs\bin\runemacs.exe

Rule 6: Options.NoExtension=<file-extension-or-list-of-paths-or-templates>

Example 7

A configuration to get the context menu of any file to show context menu
items for opening via Wordpad, Notepad, and Emacs might be:

  [Akete]
  *=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|C:\Windows\System32\notepad.exe|%PROGRAMFILES%\Emacs\bin\runemacs.exe

Rule 7: *=<list-of-paths-or-templates>

Notes: One can think of the asterisk character as similar to a wildcard
pattern character.

In summary, the types of user variable names (strings to the left of the
equals sign) that may be specified include:

  1) file extension
  2) Options.NoExtension
  3) *
  4) Options.KeywordPrefix

and the types of user variable values (strings to the right of the equals
sign) that may be specified include:

  1) list of paths and/or launch templates
  2) file extension

Bugs
----

Probably ;)

Credits
-------

Thanks go out to:

  mouser
  ecaradec
  phitsc
  raybeere
  Plugin authors that provided source and/or comments on the forums
  DC Forums participants
  DC Supporters




git repository (http://ewemoa.dcmembers.com/git/Akete.git) containing code with various changes and restructuring

README.txt
Akete

Purpose:

  To enable one to create, edit, make use of, and transport
  FARR-specific file associations.

Requirements:

  Tested with:

    - Windows 7 - may work for other versions of Windows

    - FindAndRunRobot 2.203.01 - may work for other versions

Example Usage:

  To get FARR to handle PDF files using SumatraPDF:

    Method 1:

    1. Bring up FARR's main window.

    2. Type the following in to the text field: .pdf

    Assuming FARR can find some PDF files, this should result in
    a number of FARR results representing PDF files.

    3. Bring up the context menu for one of the PDF file results.

    4. Choose the "Edit file assocation: pdf" menu item.

    FARR should switch to a view with a form requesting a path.

    5. Enter the full path to SumatraPDF.exe in the text field
       and click the button labeled "update".

    Method 2:

    1. Bring up FARR's Options dialog box.

    2. Select the Program Options -> Lists -> User Variables section.

    3. If there is no [Akete] section, add one.

    4. Under the [Akete] section, add text similar to:

         pdf = c:\apps\SumatraPDF\SumatraPDF.exe

       where the portion to the right of the equals sign is an
       appropriate path to the SumatraPDF.exe file.

  Subsequent to such configuration, in FARR, launching a file whose
  name ends in .pdf should use the SumatraPDF application do open the
  file.

Notes:

  There are other under-documented features including:

    1. Specifying more than one executable for a particular file
       association.

       Multiple paths are separated by the | character.

       For example:

         txt = c:\windows\system32\notepad.exe|c:\apps\Notepad++\notepad++.exe

       The first one mentioned is what FARR will use when launching
       normally.

       If a context menu for a result is displayed, each of the listed
       paths should appear as options for opening the file with.

    2. Specifying a "template" instead of an executable file path.

       A "template" to be filled in with the path of a FARR result
       may be specified -- the "slot" is represented by $$1

       For example:

         zip = c:\apps\NirLauncher\NirSoft\HashMyFiles.exe /file "$$1"

    3. A wildcard may be specified as a file extension so particular
       executable paths or templates will always show up on a FARR file
       result's context menu.

       The * character is used to represent the wildcard file extension.

       For example:

         * = c:\apps\Notepad++\notepad++.exe

    4. Specifying executable paths or templates for operating on FARR
       folder (not file) results.

       For example:

         Folder.* = c:\NirLauncher\NirSoft\HashMyFiles.exe /folder "$$1"
   
    5. Specifying the path to certain applications' ini files to utilize
       file association information configured for those applications.

       For example:

         IniPath.QDir = c:\apps\Q-Dir\Q-Dir.ini
         IniPath.Xenon = c:\apps\XenonPortable\Data\settings\assoc.ini

Credits:

  Find And Run Robot

    mouser

  FScript

    ecaradec

  Discussion and Testing

    JaneDC
    komtak
    mouser
    nitrix-ud
    phitsc

  Icons

    https://www.fatcow.com/free-icons

  General Thanks

    Plugin authors that provided source and/or comments on the forums
    DC Forums participants
    DC Supporters

Title: Re: FARR plugin: Akete
Post by: phitsc on December 15, 2008, 04:42 PM
Hi ewemoa. Good start :Thmbsup:. The plugin doesn't work as expected on my system though unless I assign something (anything, that is) to aliasstr. This reminded my of the problem I had when I was working on my (never released) OpenWith plugin. The onSearchBegins function was never called because I had left the default alias empty (because the plugin didn't need an alias). Maybe it's the same with onProcessTrigger?

Anyway, speaking of my never released OpenWith plugin. I think we've already concluded that the OpenWith plugin and your Akete plugin are similar. Maybe it would be a good idea to extend your Akete plugin to allow definition of "open with" keywords (using FARR's +keyword syntax) to launch files having the same file extension with different applications (what the OpenWith plugin does). I imagine something like this:

  [Akete]
    pdf=D:\Apps\SumatraPDF.exe
    OpenWithNpp=C:\Program Files\Notepad++\Notepad++.exe

and Akete not only launching .pdf files but also something like this: c:\My cool project\Config.xml +OpenWithNpp

I explained why I would like to have this functionality here (https://www.donationcoder.com/forum/index.php?topic=13633.0) by the way. The reason I never released the OpenWith plugin is that FARR keyword modifiers can't have spaces, i.e. something like +openwith=c:\program files\blah\blah.exe doesn't work. But by using defined keywords this would obviously not be a problem. With Akete doing this I could ditch the OpenWith plugin and would have something less to take care of ;)

Philipp
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 15, 2008, 08:15 PM
Thanks for the feedback and sharing of ideas :)

The plugin doesn't work as expected on my system though unless I assign something (anything, that is) to aliasstr.

Strange.  What version of FARR are you using?  I just tested it locally with 2.34.01 and it looks like it works for me without modification.  Hmmm...

This reminded my of the problem I had when I was working on my (never released) OpenWith plugin. The onSearchBegins function was never called because I had left the default alias empty (because the plugin didn't need an alias). Maybe it's the same with onProcessTrigger?

Good question.

Anyway, speaking of my never released OpenWith plugin. I think we've already concluded that the OpenWith plugin and your Akete plugin are similar.

It is thanks to your generous sharing earlier that contributed to the birth of Akete ;)

Maybe it would be a good idea to extend your Akete plugin to allow definition of "open with" keywords (using FARR's +keyword syntax) to launch files having the same file extension with different applications (what the OpenWith plugin does). I imagine something like this:

  [Akete]
    pdf=D:\Apps\SumatraPDF.exe
    OpenWithNpp=C:\Program Files\Notepad++\Notepad++.exe

and Akete not only launching .pdf files but also something like this: c:\My cool project\Config.xml +OpenWithNpp

I think I follow this suggestion.  I intend to consider and experiment with trying to implement this.  I have been wary of using keywords in FARR because I have experienced difficulties working with them.  May be I can use this as an opportunity to improve my understanding.

Thanks for posting!
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 15, 2008, 10:58 PM
I've thought about this a bit more and I think there may be at least one difficulty w.r.t. implementing the proposal.  IIUC there isn't an easy way to programmatically enumerate the names of variables in User Variables (yet). 

I suppose I could try to parse FARR's ini file, but I don't think I want to go that route.

Another possibility is to use a different form of configuration in User Variables.  If all of the pairings of "OpenWith<X>", "<Path>" were stored in a different format -- e.g. as a kind of associative array under a single name -- then there would be no necessity of determining variable names because there would only be one hard-wired one.  I believe czb has applied this method in at least one (may be two or more) of his plugins -- through the use of JSON.  One potential drawback to this approach is that editing of User Variables becomes much more complex.
Title: Re: FARR plugin: Akete
Post by: mouser on December 15, 2008, 11:12 PM
IIUC there isn't an easy way to programmatically enumerate the names of variables in User Variables (yet).

i can add this easily in the new version to be released this week.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 15, 2008, 11:41 PM
i can add this easily in the new version to be released this week.

That'd be great!

Upon further reflection on the matter though, I think it is the case that enumeration may not be necessary.  If the plugin can access the current set of keywords (which I believe it can via Search.keywords), it can attempt to access User Variables of specific names based on the set.

I intend to try this idea out.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 16, 2008, 12:49 AM
Below is an initial implementation -- all that is needed to try it is to replace the content of the existing fscript.js.  Ah, and depending on one's environment, perhaps it is necessary to fill in aliasstr (still don't know what the issue is with that).

I was surprised to see that retrieving keywords via Search.keywords seems to give lowercased keywords.  Consequently, it looks like it's currently easier to use "openwith<string>" (all in lowercase) inside User Variables -- in fact, the current Akete code assumes this.

Code: Javascript [Select]
  1. /*global FARR, dan */
  2. var displayname = "Akete",
  3.     versionstring = "1.0.0.4",
  4.     releasedatestring = "Dec 16th, 2008",
  5.     author = "ewemoa",
  6.     updateurl = "",
  7.     homepageurl = "",
  8.     shortdescription = "Akete",
  9.     longdescription = "FARR-specific file associations",
  10.     advconfigstring = "",
  11.     readmestring = "FScript",
  12.     iconfilename = "Akete.ico",
  13.     //
  14.     aliasstr = "",
  15.     regexstr = "",
  16.     regexfilterstr = "",
  17.     keywordstr = "",
  18.     scorestr = "";
  19. // SEE THE BOTTOM OF THE FILE FOR MAKING GLOBAL ENTRY POINTS
  20. //
  21. // dan - (d)estructuring (a)ssignment (n)eeded :)
  22. // XXX: why the parens surrounding the function () { ... } below?
  23. //           seems to help notepad++'s Function List plugin
  24. // XXX: dan is not preceded by 'var' because then delete will fail...
  25. dan = (function () {
  26.       // emitResult() / onProcessTrigger() types
  27.   var UNKNOWN = 0, FILE = 1, FOLDER = 2, ALIAS = 3, URL = 4,
  28.       PLUGIN = 5, CLIP = 6, ALIASFILE = 7,
  29.       // postprocessing for emitResult()
  30.       IMMEDIATE_DISPLAY = 0, ADD_SCORE = 1, MATCH_AGAINST_SEARCH = 2,
  31.       // search state
  32.       STOPPED = 0, SEARCHING = 1,
  33.       // trigger results
  34.       HANDLED = 1, CLOSE = 2;
  35.   function onProcessTrigger(path, title, groupname, pluginid, thispluginid,
  36.                             score, entrytype, args) {
  37.     var i, ma, apppath, launchstr, kwds, owre, uvname;
  38.     switch (entrytype) {
  39.       case FILE:
  40.         kwds = FARR.getStrValue("Search.keywords").split(" ");
  41.         owre = /(openwith[^=]+)/;
  42.         for (i = 0; i < kwds.length; i += 1) {
  43.           ma = owre.exec(kwds[i]);
  44.           if (ma !== null) {
  45.             uvname = ma[1];
  46.             break; // XXX: end on first match
  47.           }
  48.         }
  49.         if (uvname === undefined) {
  50.           // XXX: dot inside square brackets escaping?
  51.           ma = /\.([^\.]+)$/i.exec(path);
  52.           // XXX: in general, better to handle an alias string w/
  53.           //      $$1-style interpolation, but not doing that yet
  54.           if (ma === null) {
  55.             return;
  56.           }
  57.           uvname = ma[1];
  58.         }
  59.         try {
  60.           apppath = FARR.getStrValue("uservar.Akete." + uvname);
  61.         } catch (e) {
  62.           // XXX: log or feedback?
  63.           return;
  64.         }
  65.         // XXX: check whether path makes sense?
  66.         if (apppath !== "") {
  67.           launchstr = apppath + " " + "\"" + path + "\"";
  68.           FARR.setStrValue("launch", launchstr);
  69.           return HANDLED | CLOSE;
  70.         }
  71.         return;
  72.         //break;
  73.       default:
  74.         return;
  75.     }
  76.     return;
  77.   }
  78.   return [onProcessTrigger];
  79. } ());
  80. // defined entry points
  81. var onProcessTrigger = dan[0];
  82.  
  83. // jslint complains, but mdc documentation on delete suggests this should work
  84. delete dan;
  85.  
  86. // Local Variables:
  87. // c-basic-offset: 2
  88. // End:
Title: Re: FARR plugin: Akete
Post by: phitsc on December 16, 2008, 05:04 AM
Works perfectly! Even with an empty aliasstr now which is really strange.

Concerning parsing FARR's ini file: I agree that it's probably not a good idea. I am nevertheless doing it currently in my never released Windows Search plugin to query the max. entries to display values. It would really be good to have an officially supported way to query some FARR settings (sorry, just wanted to use this chance to repeat that yet again ;))
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 16, 2008, 06:30 AM
Glad to hear it's working for you!

I have my fingers crossed for the enumeration feature :)
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 23, 2008, 11:07 PM
With the latest FARR beta (2.42.03), it is possible to have custom context menu items per result.

I have modified Akete to make use of this functionality.

If anyone is interested, I can upload my latest -- if there is no hurry, there may be a few more things I might attend to before releasing another version.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 25, 2008, 04:58 AM
I added a few more things -- and there is an updated README.txt ;)

If interested, please see attachment.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 25, 2008, 07:47 AM
Incorporated some feedback from mouser, removed a bug, and gave it a bit of polish.
Title: Re: FARR plugin: Akete
Post by: mouser on December 25, 2008, 01:19 PM
It's confusing to have the download in the first link and also attached..
Maybe best is to always update the one linked to in the first post, and then later on in the thread you can always just say:
"download the latest from the link in the first thread" instead of attaching?
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 25, 2008, 09:49 PM
I wanted to make a distinction between what I considered more-or-less usable (what's in the first post) and what I considered more-or-less speculative :)

I suppose I could put 2 links in the first post...
Title: Re: FARR plugin: Akete
Post by: mouser on December 25, 2008, 09:54 PM
I suppose I could put 2 links in the first post...
better!
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 25, 2008, 10:05 PM
Ok, ok -- it is done :)
Title: Re: FARR plugin: Akete
Post by: raybeere on January 09, 2009, 04:21 PM
This is a great idea, but from my point of view there are two things that keep it from being useful when run from a USB stick. (At least from the description. I haven't tried it out yet. The last time I played around with anything on my stick, I was very, very sorry.) First, I'd like to see a simple way to turn it on and off, so when I wanted to use my own machine's associations, I could. (I do this when setting up a stick on my machine to keep the programs on it from running, so I get less reads / writes to the stick.) Second, I'd like to see a way to specify the relative path from the root without needing to specify a drive letter. After all, if I have to use my stick on another machine, I have no idea what letter it will be assigned - and if I'm doing that, nine times out of ten I'm in no mood to go in and change a bunch of settings right then.

Two other nice features would help out, a lot. One would be a chance to specify two options, by keyword, such as Open and Edit. I think the point there should be pretty clear. The other one is a workaround for a particular program I use, Liquid Story Binder XE. It is a great writing program, but it has one quirk. All files are arranged in a "library" by "book" - each book is a folder under one user-specified folder for the library. Each book actually contains a whole set of files. So, to open a "book" in LSB, you have to run LSB with the book's folder specified in the command line or shortcut. Is there any way to let the user specify such behaviour? (Open X app with the path of the selected file specified, but strip away the filename...)
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 10, 2009, 05:42 AM
First, I'd like to see a simple way to turn it on and off, so when I wanted to use my own machine's associations, I could.

I have an idea or two about this -- I intend to figure out whether they are practical.

Two other nice features would help out, a lot. One would be a chance to specify two options, by keyword, such as Open and Edit. I think the point there should be pretty clear.

If it doesn't have to be by keyword, there is already a way to specify multiple paths for each file extension -- this information is used in augmenting the context menu for a search result by a context menu item per path (you end up seeing something like "Open with myapp.exe" for each path).  I think I documented this feature in the README.txt of the plugin, but I don't recall at the moment.

The other one is a workaround for a particular program I use, Liquid Story Binder XE. It is a great writing program, but it has one quirk. All files are arranged in a "library" by "book" - each book is a folder under one user-specified folder for the library. Each book actually contains a whole set of files. So, to open a "book" in LSB, you have to run LSB with the book's folder specified in the command line or shortcut. Is there any way to let the user specify such behaviour? (Open X app with the path of the selected file specified, but strip away the filename...)

Currently, this is not supported.  mouser made a similar suggestion and we have discussed the possibility of support for something like what one can specify for an alias string.  So for example, you might be able to express something like:

  %PROGRAMFILES%\Something\Another.exe /p /e "$$1"

and $$1 would get filled in with the file identified via FARR and %PROGRAMFILES% would get resolved to the relevant path.

I intend to investigate this further too.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 13, 2009, 09:34 AM
I am drafting some documentation for a newer version and thinking that it may act as a specification.  This post should contain my first attempt.  Feedback is welcome ;)

Draft
  Introduction
  ------------

  The main point of this plugin is to be able to customize how files
  with particular file extensions are opened.  To achieve this end,
  the user is expected to provide a configuration which specifies
  associations between file extensions and corresponding methods of
  opening files with those extensions.

  The plugin provides additional functionality including support for:

    * multiple possible methods of opening files via context menu items

    * default context menu items (i.e. always appear in context menu)

    * overriding of method to open files via an appropriate keyword

  Configuration
  -------------

  The Akete plugin may be configured by using FARR User Variables.

  FARR User Variables are accessible via "Program Options" ->
  "Lists" -> "User Variables" in FARR's Options dialog box.  The section
  for Akete (may not exist unless manually created) begins with the
  string [Akete].  (For more information regarding FARR User Variables,
  in FARR's .chm Help File, see the section titled "User Variables -
  Advanced Use" under "Advanced Use".  The rest of the text assumes
  familiarity with the FARR documentation content.)

  Configuration details will be demonstrated through a series of examples.
  After each example a general rule will be stated possibly followed by
  some related notes.

  Example 1

  A configuration to get files with the extension 'txt' to be opened using
  Wordpad might be:

    [Akete]
    txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

  Rule 1: <file-extension>=<path-to-executable>

  Notes: The path to the executable may contain FARR Virtual Folder
  names (see the FARR help file).  Also, file extensions do NOT contain
  the period character.

  Example 2

  A configuration to get files with the extension 'txt' to be opened by
  (possibly additional instances of) Notepad++ might be:

    [Akete]
    txt=%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

  Rule 2: <file-extension>=<launch-template-string>

  Notes: The launch template string allows specification of command line
  arguments.  The plugin replaces the string $$1 by the path to the file to
  be opened.  Do NOT use the vertical bar character in a launch template
  string -- the reason for this should become clear below.

  Example 3

  A configuration to get files with the extension 'doc' to be opened using
  whatever is configured for 'txt' might be:

    [Akete]
    txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe
    doc=txt

  Rule 3: <file-extension>=<file-extension>

  Notes: For simplicity of configuration and implementation, if a file
  extension appears on the right hand side of an equals sign, it may not
  appear on the left hand side of the equals sign.  Another way to phrase
  this is that only one level of indirection is supported.

  Example 4

  A configuration to get the context menu of a file with extension 'txt'
  to show context menu items for opening via Wordpad and Notepad++ might be:

    [Akete]
    txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|%PROGRAMFILES%\Notepad++\Notepad++ -multiInst "$$1"

  Rule 4: <file-extension>=<vertical-bar-separated-list-of-paths-or-templates>

  Notes: The items in the list may be paths or launch string templates. 
  The vertical bar character is reserved for separating the items so it may
  not be used in a path (doesn't tend to work in Windows anyway?) or a
  launch template string.  Opening of files via FARR's text edit field will
  be handled using the first item in the list.

  A configuration to get the context menu of a file with extension 'txt'
  to show context menu items for opening via Wordpad and Notepad, but leaves
  handling of opening of such files untouched if done via FARR's text edit
  field might be:

    [Akete]
    txt=|%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|C:\Windows\System32\notepad.exe

  Notes: One can think of the list as having an empty first item.

  Example 5

  A configuration to get the context menu of any file to show context menu
  items for opening via Wordpad, Notepad, and Emacs might be:

    [Akete]
    *=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe|C:\Windows\System32\notepad.exe|%PROGRAMFILES%\Emacs\bin\runemacs.exe

  Rule 5: *=<vertical-bar-separated-list-of-paths-or-templates>

  Notes: One can think of the asterisk character as similar to a wildcard
  pattern character.

  Example 6

  A configuration to get the plugin to recognize a keyword to override
  opening behavior for opening a particular file via FARR's text edit
  field might be:

    [Akete]
    openwithnpp=%PROGRAMFILES%\Notepad++\Notepad++.exe

  Subsequently, specifying a file along with the 'openwithnpp' keyword in
  FARR's text edit field (and "launching" for example, by pressing the
  Enter key) should lead to an attempt to open the specified file using
  Notepad++.exe.  The contents of the text edit field might look like:

   C:\boot.ini +openwithnpp

  Rule 6: openwith<string>=<path-or-launch-template-string>

  In summary, there are three types of user variable names (strings to the
  left of the equals sign) that may be specified:

    1) file extension
    2) string of the form openwith<some-string>
    3) *

  and two types of user variable values (strings to the right of the equals
  sign) that may be specified:

    1) list of paths and/or launch templates
    2) file extension



Edit: Updated draft
Title: Re: FARR plugin: Akete
Post by: mouser on January 14, 2009, 04:18 AM
great stuff ewe, very clear and great functionality!!
the only thing that would be nice is maybe to think of something shorter than "openwith" as the prefix needed for that function.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 14, 2009, 06:38 AM
Thanks for taking the time and making the effort to read the draft -- I really appreciate it!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.

Oh no, don't say we should be able to configure what the keyword starts with via FARR User Variables! ;)
Title: Re: FARR plugin: Akete
Post by: phitsc on January 14, 2009, 06:57 AM
I agree with mouser, looks very good!

As to the keywords that begin with "openwith", I chose this based on phitsc's example and am not particularly attached to it -- except that if it's changed, I guess trying to maintain backward compatibility might be something to consider.
And neither am I. Wouldn't give me a lot of work if you changed it. I'm no big fan of abbreviations though, so I still think openwithnpp would be clearer than something like e.g. ownpp.

What about just using the same definition as used for extensions, e.g. if one specified something like:

txt=%PROGRAMFILES%\Windows NT\Accessories\wordpad.exe

then it would open .txt files with Wordpad, but one could also do this:

C:\boot.ini +txt

and it would also open with Wordpad.

I could then choose whatever definition I liked (even openwithnpp ;) ) and since there are no files with an extension of .openwithnpp it would just work with this C:\boot.ini +openwithnpp. You would have to check if it might give problems with other keywords though.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 14, 2009, 07:59 AM
Thank you phitsc, for also taking the time and making the effort to read the draft and comment on it :)

The idea you suggested sounds interesting.  As you pointed out, there does seem to be a potential issue with keyword collision and I am mulling over what might be done about that.  Perhaps allowing a configurable prefix (which defaults to something) for the keyword and reusing the definitions from file extensions as you suggested might work out.

My impression at the moment is that having a particular prefix helps in picking out an appropriate keyword from the query.  Supposing that there is no particular prefix string for the keywords this plugin should handle, if a query contains multiple keywords, I am not sure how to decide which keyword (possibly multiple?) should be selected by the plugin.

Regarding a default keyword prefix, "open" or "with" seem like possibilities to me.

What do folks think?
Title: Re: FARR plugin: Akete
Post by: mouser on January 14, 2009, 08:18 AM
both prefixes seem good to me, or even use "ow" as a prefix (for open with)
so
+owtxt
would open with whatever is configured as txt editor.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 15, 2009, 08:38 AM
I think I'll go with a default of "with" as the prefix, provide a way to change the prefix, and leverage any existing file extension association configuration so that it may be used with a keyword (e.g. if you have an association defined for 'html', then the plugin should recognize the keyword 'withhtml').

I discovered that one can use period-separated names for both section names (e.g. "Akete.Options") and variable names (e.g. "Options.KeywordPrefix") in FARR User Variables.  Also, that:

  [Akete.Options]
  KeywordPrefix=test

ends up being the same (?) as (at least as far as requesting the value from FARR is concerned):

  [Akete]
  Options.KeywordPrefix=test

I'm currently leaning toward suggesting the use of the variable names in the official documentation.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 15, 2009, 10:47 PM
I'm thinking of providing a way of handling files with no file extension.

My current candidate for doing this is via the user variable Options.NoExtension.  Possible associated values should be the same as for a file extension.
Title: Re: FARR plugin: Akete
Post by: phitsc on January 16, 2009, 02:24 AM
I think I'll go with a default of "with" as the prefix, provide a way to change the prefix, and leverage any existing file extension association configuration so that it may be used with a keyword (e.g. if you have an association defined for 'html', then the plugin should recognize the keyword 'withhtml').
sounds good to me.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 16, 2009, 05:44 AM
Thanks for the feedback -- I really appreciate it :)
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 21, 2009, 01:11 AM
I've put together a new experimental version -- the first post of this thread should contain an updated download link as well as the associated README.txt in the spoiler section.

I think I have made initial attempts at all of the features discussed in this thread.

If you give it a try, I'd appreciate knowing how it works (or doesn't ;) ) for you.
Title: Re: FARR plugin: Akete
Post by: phitsc on January 21, 2009, 02:23 AM
I'm afraid it's a 'doesn't' for me. See attached screen shot.

[ You are not allowed to view attachments ]
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 21, 2009, 03:07 AM
Thanks for the report.

Hmm...May I ask how you performed the installation of the plugin and what version of FARR you are using (I'm using 2.45.01)?

FWIW, the new plugin has some code split out into a separate file so upgrading is no longer a matter of replacing fscript.js -- on the off-chance that that's what was going on :)

Edit: I managed to reproduce the error -- investigating now :)
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 21, 2009, 03:37 AM
Terribly sorry -- completely my fault.  Sorry to have wasted your time.

I have uploaded a version with a work-around [1] -- this time I tested the installation from the downloaded file (like I should have done to begin with!).


[1] I had code for determining the directory of the plugin that was specific to my atypical set up -- as I understand it, a future version of FARR should make the work-around unnecessary (though I'll need to update the plugin to make use of the feature).
Title: Re: FARR plugin: Akete
Post by: phitsc on January 21, 2009, 04:35 AM
Thanks. Works perfectly now!

Can I disable the 'Failed to look up value for' popping up for non-configured file types somehow? (not all files want to be opened by Akete ;) )

Now if only mouser could fix the 'wildcard matching not working anymore in alias result' problem...
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 21, 2009, 05:10 AM
Thanks for testing again and noticing the issue with non-configured file types.  Very good point :)

I tested a change I made to address the issue and it seems to be working here.

I've uploaded a new version and I have my fingers crossed.

Edit: there may be an issue w/ right-clicking on a result which has an extension that has not been configured -- looking into this now.
Title: Re: FARR plugin: Akete
Post by: ewemoa on January 21, 2009, 05:35 AM
Ok, I think the "right-clicking on a result which has an extension that has no related configuration" issue has been addressed -- hopefully in an appropriate manner.
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on February 17, 2009, 08:20 AM
very nice plugin  :D
plugins that enhance core FARR features are great  :Thmbsup:

let me suggest the following feature that i would love to see :

what if we could specify what application to run based on the file's folder

[Akete]
    C:\_joker\lnk=C:\Program Files\Notepad++\notepad++.exe

would mean every file inside C:\_joker\lnk should be opened with notepad++

that would gives us even more power !

Keep up the good work
nitrix
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 17, 2009, 08:36 AM
Interesting idea.

If this were to be implemented, I wonder if it might work better to do it with something like:

[Akete.Folders]
C:\Documents and Settings\Administrator=C:\Program Files\Notepad++\notepad++.exe

One thing to consider is what to do about files in subfolders...

On a tangential note, I wonder if having something like:

[Akete.Variables]
$np=C:\Program Files\Notepad++\notepad++.exe

might allow one to do something like:

[Akete.Folders]
C:\Documents and Settings\Administrator=$np

If this were doable, it might make some of the existing functionality a little nicer.  That's off the top of my head though -- probably a good idea to explore the consequences and practicality a bit more.
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on February 18, 2009, 04:23 PM
any implementation would please me  :D

my goal is to simplify my workflow when using FARR ...

i have several aliases with action and folder modifiers (ex : Favorites search $$1 | dosearch +folder_fav +open_fav -alias $$1)
having this folder-based configuration would remove the need for those aliases...
and therefore remove the need for the few first characters (to trigger the aliases...)

so much power, i would feel like a super hero  :-*
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 19, 2009, 03:59 AM
I might consider working on an implementation, but at a minimum I think I'd like to convince myself of a coherent design.  If I don't understand how it is supposed to work, I'm not going to have an easy time getting it to work, nor maintain :)

Another potential issue that occurred to me is precedence.  It's not clear to me yet whether a folder setting should take precedence over a file extension setting or vice versa.  If "it depends", then coming up with a way of expressing which setting "wins" for a particular situation or for certain situations seems like a possible way out.

It seems to me that the idea (as I currently understand it) is not well-defined enough for an attempt at an implementation.  Perhaps I'll think of something -- or may be someone else will ;)
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on February 19, 2009, 08:34 AM
you are right about precedence and in general about the fact that it is not trivial

the way i see it, is a bit dumb i must admit ;)

i simply told myself : that is a nice plugin ! what if we could trigger what application to run based on the file's path

it could be a completely different plugin with no connection whatsoever

when using Akete plugin, we are talking serious fine tuning and i believe that people that use it, know what they do
i will not ask for a refund if it creates some after effects ;)
 

as a simple example, please consider the following :

i have a folder named snippets with all sorts of code snippets inside...
i'd like to use FARR to search for one of them then copy its content to the clipboard thanks to an homemade .exe

with the Akete.folders ;) plugin i just do :

[Akete.Folders]
C:\Documents and Settings\My Snippets=C:\Program Files\copytoclip.exe
 
of course i could do it now with Akete, by specifying a special extension :
[Akete]
.snip=C:\Program Files\copytoclip.exe

but for some reason i would rather not go this path


so my suggestion is : if you do it, do it any way you see fit  :D


PS : It could also be part of FARR core-functions right within the Search folder interface...
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 21, 2009, 09:58 AM
it could be a completely different plugin with no connection whatsoever

It's not clear to me that doing it in a separate plugin will help -- it might, but it isn't clear to me how yet (if it indeed is helpful).

i will not ask for a refund if it creates some after effects ;)

Well, you might not, but it's not entirely unlikely that it would bother me -- I use the plugin too and at least currently, I look after the code.  I think it would be kinder to the current and potential future maintainers if the plugin's design and implementation are clear and coherent ;)

with the Akete.folders ;) plugin i just do :

Actually, this wasn't meant as a separate plugin -- user variables under [Akete.Folders] are accessible to any plugin as far as I understand.  I had thought that placing the settings in a separate section might simplify the design and configuration.

so my suggestion is : if you do it, do it any way you see fit  :D

I do not see a way that is fit just yet -- however, who knows what the future may bring?
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on February 22, 2009, 05:43 AM
i'll keep using my aliases then  :D
Title: Re: FARR plugin: Akete
Post by: ewemoa on March 13, 2009, 04:12 AM
if AketeFolder plugin was first then the same questions about precedence would have arised with Akete plugin  :D
My leaning on this issue so far has been not to do a separate plugin -- it may have seemed like it because of the configuration example, but actually that configuration example would work fine from a suitably modified Akete plugin.

The motivation for me to split the configuration sections into Akete and Akete.Folders was because my impression is that handling the configuration is clearer -- I think that everything living in the Akete section makes for a mess in terms of design as well as in terms of users specifying configurations.

with an hyper complex filtering system where you could see things like :

(if the extension of the file is xxx
AND
if the file is in Folder yyyy
AND
file has been modified within zz hours)
then open with notepad++

Do you think you could start spelling out specifically how this kind of thing would be specified by a user?
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on March 13, 2009, 08:57 AM
maybe this could be done like the directory file opus filter system :
http://www.dopus.com/manual9/NetHelp/default.htm?turl=WordDocuments%2Ftheopusfilefiltersystem.htm (http://www.dopus.com/manual9/NetHelp/default.htm?turl=WordDocuments%2Ftheopusfilefiltersystem.htm)

however this should??/could??/must?? be much much simpler ;)
Title: Re: FARR plugin: Akete
Post by: ewemoa on March 13, 2009, 04:46 PM
I took a look and my initial impression is that I very much doubt I have the resources or inclination to try to make something like that -- if FARR provided some way for plugins to easily provide configuration panes that integrated with the existing Options dialog, I might consider it, but AFAIK that doesn't exist currently.

I think the kind of thing that might be practical is doing something within the existing User Variables mechanism -- so imagine a potential user is going to be specifying their configuration via the User Variables pane in FARR's Options dialog box.  With this approach we've got:


As I understand it, those are our practical building blocks.  Do you have any ideas that can be expressed well using these pieces?

May be there are other practical approaches that don't involve creating basic configuration-related building blocks...I know there is some support available via FARR/FScript for handling INI files, but as I understand it, that's not too different from what User Variables supplies.

If you have any thoughts regarding other approaches, I'm happy to hear them :)
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on March 13, 2009, 07:22 PM
i completely agree that the existing User Variables mechanism is the way to go...

as i said i would be very happy with a plugin that does not try to handle precedence
because basically, i think a Akete.Folder plugin (as a standalone one or as an extension of the current one) would help people to simplify aliases.
i see immediate applications...

i don't see immediate applications for a more complex version where you could specify different applications to run depending on extension or/and path

with much more complex criterias (attributes, modified date, size, ...), i can see applications, that would even be fun to play with ;) BUT that would be a LOT of work
and as you said, FARR does not provide the configuration power to do it...

I'm sure that it wouldn't take too long to do a simple version as opposed to one that would try to achieve perfection ;)
and maybe this simple version would cover 80% of our need

in anycase, keep up the good work ewemoa !
and thanks again for the Akete plugin  :Thmbsup:



Title: Re: FARR plugin: Akete
Post by: ewemoa on March 14, 2009, 01:06 AM
as i said i would be very happy with a plugin that does not try to handle precedence

As I understand it, it's a problem to not address the precedence issue.

Perhaps one useful way of looking at this situation is to see that multiple plugins trying to handle file extensions is potentially murky.  If you've got two such plugins installed and both either are configured or set up to handle a particular file extension, which one should end up doing it?

May be I'm misunderstanding how things work in FARR -- perhaps mouser could clarify :)
Title: Re: FARR plugin: Akete
Post by: nitrix-ud on March 14, 2009, 03:47 AM
one would handle files based on its path
the other one based on its extension

as i said previously, Akete  would not exist, you could very well have created Akete.Folder

and THAT plugin would suit me (personnaly as of today, i would only use Akete.Folder so there would not be any precedence issue...)

however i perfectly understand that having two plugins that could lead to unexpected behavior is not confortable for you

you are right maybe mouser could clarify...
Title: Re: FARR plugin: Akete
Post by: JaneDC on December 27, 2011, 11:15 PM
files launched are not added to the history list? Any way to change the behaviour?
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 28, 2011, 02:39 AM
I don't think there is a way at the moment.

May be mouser could comment on whether this should be doable from a technical standpoint.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 28, 2011, 05:02 AM
Some experimentation here has the following results:

Title: Re: FARR plugin: Akete
Post by: ewemoa on December 28, 2011, 05:11 PM
I've tried modifying the stable version which doesn't include context-menu-related behavior.

If the stable version is what you are using, please let me know how the attached version works for you.

MD5: bff3767734f5e7d995881b40e24d5bff

[ You are not allowed to view attachments ]
Title: Re: FARR plugin: Akete
Post by: JaneDC on December 29, 2011, 03:12 AM
Thanks for the reply and the modified version. I'll get back here as soon as i try it.

I'm using farr portably, even on my main computer, and together with total commanders internal file associations, this should be the best way of launching files.

I actually launch everything using your plugin, so with things not showing up in the history, i'm pretty much missing a lot.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 29, 2011, 03:48 AM
Do you happen to know how Total Commander stores file association information?  I've been thinking that being able to import such information into Akete (or have Akete utilize such info) might be handy.
Title: Re: FARR plugin: Akete
Post by: JaneDC on December 29, 2011, 10:57 PM
Ok i've tried the modified version and it's working just the way i want it too. Launched files are now being shown in the history. Very cool. Thank you!
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 29, 2011, 11:08 PM
Thanks for reporting back.

I hope it continues to function appropriately :)

Thanks to mouser for making it possible to achieve this functionality via plugins in FARR  :Thmbsup:
Title: Re: FARR plugin: Akete
Post by: komtak on February 04, 2012, 09:46 PM
Akete exactly is one of the best FARR plugins which improves productivity.   :up:

However, I found  the following problems in the latest experimental version 1.0.1.8:
(1) The regular expression for detecting no-extension file name works unexpectedly when the folder path containing the target file includes dot (.) characters.
(2) When a short cut (*.lnk) is resolved to be a folder path, Akete reports "File not found" error.
(3) When using Akete association, two launching processes seem run redundantly, one via Akete and another via the default association; e.g. when I launch a text file having extension 'txt', both the text editor associated to the extension 'txt' by Akete and a notepad via default file association open the file, respectively.

I made minor changes to fscript.js as attached, which should fix (1) and (2), but I can not address the cause of (3). Does this happen only to me? Does anyone have some idea to fix it?
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 04, 2012, 10:12 PM
Thanks for the report and patch.

I will try to look into these matters further.

On a side note though, I've been thinking about not pursuing the direction explored in the experimental version.  From a certain perspective, it essentially proceeds to produce a new mini-language for configuration, and that doesn't seem like such a good idea to me at the moment.

As an alternative, I've been considering providing hooks by the plugin which can be leveraged by users via JScript.
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 05, 2012, 12:55 AM
komtak:

I've successfully reproduced the 3 points you mentioned.

At the moment, what you propose as a fix for the first point seems good.  Thanks!

I'm still processing the second and the third points.

Thanks again for reporting.
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 14, 2012, 02:49 AM
(3) When using Akete association, two launching processes seem run redundantly, one via Akete and another via the default association; e.g. when I launch a text file having extension 'txt', both the text editor associated to the extension 'txt' by Akete and a notepad via default file association open the file, respectively.

komtak,

mouser investigated the issue and has prepared another version of fscript.dll.  Perhaps you can try it out and let us know if it addresses your third issue?  It seems to work for us.

Please find it attached to this post (note: its version is a bit odd -- once we are comfortable with a fix, I hope we can release a version which is more appropriate).

dll's MD5: 0742d6c85db9ec153c7d6b22634d4544
Title: Re: FARR plugin: Akete
Post by: komtak on February 19, 2012, 01:31 AM
ewemoa,

I have tested the new fscript.dll and found the problem (3) being removed. Thanks a lot!

I have also found that the correction for the problem (2) in my patch, Akete-diff-1.0.1.8-1.0.1.8a.txt, does not work properly.  I am trying to fix it, but the behavior of Windows shortcuts seems rather complicated to me.  (I have to study more...)
Title: Re: FARR plugin: Akete
Post by: ewemoa on February 19, 2012, 02:26 AM
komtak:

Thanks for testing the new dll and reporting back :)

I have also found that the correction for the problem (2) in my patch, Akete-diff-1.0.1.8-1.0.1.8a.txt, does not work properly.  I am trying to fix it, but the behavior of Windows shortcuts seems rather complicated to me.  (I have to study more...)

Good luck on this!



FWIW, there was some discussion in the past regarding Akete and folders, but we did not come up with any satisfactory design / idea.
Title: Re: FARR plugin: Akete
Post by: ewemoa on December 23, 2012, 04:57 AM
Got some experimental support for utilizing Q-Dir's file association information via its ini file.

Title: Re: FARR plugin: Akete
Post by: ewemoa on January 19, 2013, 07:58 PM
Tentatively made a git repository (http://ewemoa.dcmembers.com/git/Akete.git) available containing code with various additions, removals, etc.

Changes include:


See first post for README.txt.
Title: Re: FARR plugin: Akete
Post by: yjs14 on September 29, 2013, 09:37 AM
FARR always reports "File not found" error!!!
Title: Re: FARR plugin: Akete
Post by: ewemoa on September 29, 2013, 07:57 PM
Please share information about:


Thanks.