topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday December 13, 2024, 10:49 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: FARR plugin: Akete  (Read 71181 times)

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
FARR plugin: Akete
« 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 MD5: 1c2fb4e40841437c48cf3f5070d9fa66
  Experimenting 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 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

« Last Edit: January 19, 2013, 08:00 PM by ewemoa »

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #1 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 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

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #2 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!

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #3 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.
« Last Edit: December 15, 2008, 11:00 PM by ewemoa »

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #4 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #5 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #6 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:

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #7 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 ;))

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #8 on: December 16, 2008, 06:30 AM »
Glad to hear it's working for you!

I have my fingers crossed for the enumeration feature :)

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #9 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #10 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #11 on: December 25, 2008, 07:47 AM »
Incorporated some feedback from mouser, removed a bug, and gave it a bit of polish.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #12 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?

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #13 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...

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #14 on: December 25, 2008, 09:54 PM »
I suppose I could put 2 links in the first post...
better!

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #15 on: December 25, 2008, 10:05 PM »
Ok, ok -- it is done :)

raybeere

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 94
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #16 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...)
« Last Edit: January 09, 2009, 04:23 PM by raybeere »

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #17 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #18 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
« Last Edit: January 14, 2009, 03:45 AM by ewemoa »

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #19 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #20 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! ;)

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #21 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #22 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?

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: FARR plugin: Akete
« Reply #23 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.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FARR plugin: Akete
« Reply #24 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.