avatar image

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

Login with username, password and session length
  • Tuesday November 24, 2020, 9:18 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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - JohnJ [ switch to compact view ]

Pages: [1]
Living Room / Re: Godmode
« on: August 09, 2014, 07:09 PM »
Just a note on godmode. I tried it on Win 8.1 x64 and it worked fine. I then created another folder called 'c:\godmode shortcuts' and mass created a shortcut to every entry in the godmode folder by selecting all and then right-click drag and drop. I then added the 'c:\godmode shortcuts' folder to FARR along with a 'god' alias to search that shortcut folder. That worked fine.

Also, using Win+S to open the search charm is very useful. You can find anything you want concerning windows using the search charm which is very well designed.

I have found that weighting interactions can get quite complex so, as I am sure you already know, you can just create a quick alias for common items (e.g., 'mus' in this case) when this problem arises and not worry too much about it.

If a particular similar problem frequently arises a careful examination of your custom weighting rules helps.

Find And Run Robot / Re: Folder Modifier Bug?
« on: July 19, 2014, 01:48 PM »
To add to my above response. I am aware of modifiers, which can be very useful. However, they would be very cumbersome to use in the manner I found so useful in Keybreeze which automatically treats every item added as aliased and the alias not the original item is used for searches. All I am looking for is a method to optionally automatically interject a searchable 'alias' for every item and that alias is then used in my search. For example I might alias the program MS Word to be 'Word Editor Write' or even intentionally misspell words to create a particular order in results (e.g., an alias of 'w ord' (with the space) might always bring Word to the top of results by simply typing 'w'). There are simple hacks to naming certain aliases that you pick up over time in the same way you might adjust scores in FARR but the results can be much more focused, far easier to maintain and will not 'break' as often.

Find And Run Robot / Re: Folder Modifier Bug?
« on: July 19, 2014, 01:24 PM »
That is a good suggestion. However, my main observation is that it can be very valuable to easily assign an optional searchable custom keyword to each alias/action which now cannot be done in FARR. In that way you can search the keywords that only you defined and allowed into your search universe (which keyword could still be the original file name, a shortcut alias version of the name, several keywords together, or any combination). In that way, your searches will be of your customized keyword universe not limited to the original file/folder names. This can be very useful.

Obviously, there are different ways to implement keyword based weighting, e.g., adding a keyword to aliases or the quick and dirty method I used with shortcuts that are placed in a separate folder and that folder is heavily weighted in searches.

Along that shortcut line, it occurred to me that simply adding a menu item to the context menu in search results that creates a shortcut (which you rename to your keyword or keep the original name as is) in a %FARR_Shortcuts% folder also 'implements' a keyword weighting system. You then weight that folder to emphasize the degree of constraint your keyword universe imposes on searches. Constraining sharply limits the "breaking" of searches as files changes and keywords make your searches much more efficient over time as you add them to your "system". I create many such 'aliased' shortcuts to my key autohotkey scripts, folders I use a lot, folders or other items that are currently important to me (e.g., I might call a shortcut 'current project' and change its target as my projects change). I know that currently FARR can accomplish focusing on certain items by scoring but you still have the problem of a search applying to your entire universe of folders and the fixed names assigned to files/folders, as opposed to having your own custom alias/keywords substituting for those fixed file names and your search limited to only the universe you create over time.

Find And Run Robot / Re: Folder Modifier Bug?
« on: July 18, 2014, 01:23 PM »
Mouser, another thought.

I was looking at Keybreeze to try to isolate what I liked about it and realized the difference between it and most other launchers is that it limits its normal search to only keywords and when matched takes the desired action (aka FARR results box). It does have 'functions' which somewhat similar to FARR aliases only for web searches.

The advantage I found was the ability to strictly limit what went into the search universe by controlling the keyword/action pairs I used. There is a provision to import all start menu items but I did not want to confuse the search universe so I ignored it. Since I only allowed my important items into the search universe and used creative names in the keyword (including ad hoc keywords) all my searches were instantly focused and rarely 'broke', a failing I found with other launchers that search a much larger universe that changes constantly. I still had Windows start menu search box (and the new Win8 search charm is great) and Everything Search for less common tasks.

A quick way for any FARR user to see if such a focused search universe is useful is to create a separate folder and just add normal shortcuts or url links to that folder. Give that folder a high search weight. You can, if you want, change the names of the shortcuts. You now have an ad hoc keyword/action system similar to Keybreeze where those shortcut names float to the top of search results and the targets can then be launched. I found such focused searches very useful in normal day to day use since it avoids the constantly shifting search universe that requires constant fine tuning of searches to keep what you want at the top of results.

If FARR was to ever be updated to add the ability to have a searchable keyword associated with every alias you could have an extra 'keyword' entry for each alias that is system-wide searchable and a weight score for all keywords. The user could keep the reqular target filename or substitute useful keyword(s) in the keyword field. Possibly, after a keyword floats to the top of results you could then allow a comma that would internally replace the keyword so far typed with the alias itself so that regEx works normally for everything typed after the comma. A user can now tightly constrain his/her search universe simply through the keyword weight score.

I do believe the ability to tightly constrain a keyword based search universe can be very useful for usability purposes for many. It was for me.

Find And Run Robot / Re: Folder Modifier Bug?
« on: July 17, 2014, 06:32 PM »
Yes. It is a good start. However, the very subject touches on one issue I see as a new user of FARR. The current organization of aliases is somewhat complex and can confusing to a new user in terms of real useability. The user has to first understand the system before he/she can use it effectively. The idea you propose fits in with what I believe would greatly improve usability, that is, provide 1) a quick way to simply add any alias (keyword)/action pair (whether a file launch or triggering another alias) and 2) to view all of those keyword/action pairs in one place (this is very important). Both those items should be on the same form so rapid modifications can be quickly done.

Let's say you extend the simplicity idea of the special tab to every alias in the system and have a single listbox (a front end to a non-expert mode?) with one line per alias and cols such as: the alias (keyword); the main regEx; the results box; an 'is Active' checkbox; the alias file name(?); and if unchangeable then the row is greyed. Each col. is sortable. A double click on a line gets you to the alias. There could be an 'Add' button at the top and maybe a 'Add Simple Alias' button which only allows adding an alias name and a simple results box entry (which could be another alias). That simpler new alias button form could hide a special keyword such as 'alias' that goes into the actual underlying alias results box to signal the result is another alias. You now have a very simple front end to all aliases that makes the alias system far more usable to the normal user and allows creating simple 'quick and dirty' keyword/action aliases, including an alias to an alias, without changing the underlying alias system.

Just an idea.

Find And Run Robot / Re: Folder Modifier Bug?
« on: July 16, 2014, 05:05 PM »
Mouser: Correct.

Actually, as I stated, that bug led me to a solution (use shortcuts as multiple alias) that solved another problem that frustrated me with FARR. I was always a happy user of Keybreeze because it has a simple and effective alias interface (and way to keep track of the aliases) where every link was located only through its alias. This allowed me to create effective variations on file names (to access to the many tasks I do repetitively) via the use of creative aliases resulting in only 3 or 4 easy to remember keystrokes for my common tasks. FARR appeared to have that potential but presents a more complex interface so I never could quickly duplicate what I was doing in Keybreeze. For example, actually viewing and editing all aliases I create in FARR is more challenging and the scoring method is powerful but can lead to hard to track reasons why certain results occur. In short, it requires more effort on my part! This is not a criticism but only an observation of the pros and cons of a more powerful system.

Discovering the technique of simply placing shortcuts to my common tasks in a single folder and naming them in the same manner I was using in Keybreeze quickly duplicated what I liked about Keybreeze so much. Unfortunately, with the latest release in Win 8.1, Keybreeze is forever 'broken' and appears to be moribund which is why I turned to your great program. The work-around fixes I came up with, i.e., use the path directly not a modifier, and use a shortcut folder, makes the bug effectively irrelevant and/or easy to work around in the rare cases it appears with some unrecognized extensions.

Find And Run Robot / Folder Modifier Bug?
« on: July 16, 2014, 03:46 PM »
There appears to be a bug in launching certain filetypes using an alias (in this case files with an '.ahk' extension) when a folder modifier is used instead of the direct file path in the result box. Here is a simple example that fails for autohotkey '.ahk' files:

I create two simple alias: the first uses the autohotkey path directly and the second uses a defined folder modifier 'ahk' that has that same path

1. alias: 'ahk1'
    regex: ^ahk1 (.*)$
    result box: ahk1 $$1 | dosearch c:\autohotkey\ $$1

2. alias: 'ahk2'
    regex: ^ahk2 (.*)$
    result box: ahk2 $$1 | dosearch +ahk $$1
The folder modifier 'ahk' is defined simply as the same directory used in 1) above: i.e., an ahk modifier definition for directory: c:\autohotkey

When I use the above formats for normal files, e.g., .exe, .lnk etc. the above two formats perform identically and work correctly. But for the above ahk example case 2, the search acts normally and finds the correct file and that file will launch correctly if I launch it from the context menu. But if I hit enter or try to double click on the found result a new search simply occurs and i only see 'Searching c:\ ...' and the file does not launch. This only happens in the case of the .ahk extension. All normal extensions work perfectly. I tried every possible launch option and the error still occurred.

It appears that in the case of an unrecognized extension (here 'ahk') the launch routine, only when a modifier is used, gets confused with that unrecognized extension. I am using x64 Win 8.1 and have associated the .ahk extension with autohotkey and, as I said above, the launch works fine as long as I use the path itself in the alias result box instead of the folder modifier +ahk.

I also tried creating a separate folder and add shortcuts (.lnk) to the '.ahk' files and then tried version 2 above using a modifier; those shortcuts worked fine. There was no problem with FARR recognizing the .lnk file to the .ahk file and then correctly launching the .ahk file when I used a folder modifier to that lnk directory.

For the time being I am simply using that second .lnk directory to launch .ahk files. Incidentally, this appears to be a good technique to quickly create multiple 'alias' names for a single file since the shortcuts can each be differently named. If you create a new folder modifier to that shortcut folder, those new alternate file ('alias') shortcuts can then be used to access the same file using multiple aliases ... very convenient!.

Pages: [1]