Renaming with Textfiles

As stated on the main page, I've added textfile support to the Rename Master. While the current implemenation is simplified to just 3 options, there's a visualization problem with the implementation. There's no visual link between loading the textfile into meta-variables and further more there's no visual link between the Scripting Steps and inserting the new ?textN? style meta-variables.

The first plan is to visually display a row of the data. This will help with 2 visual problems and show how the data is separated and the names of each of the meta-variables used for each field. This will also show if the effect of the "skipped lines".

The second plan is to add a new "Textfile" popup item for the insert popup menu to automatically insert ?textN? meta-variables.

MouseWrangler, under the hood

For a peek at how MouseWrangler works, hold shift and click the main form in an empty area. The top/left 2 values represent the change in X and Y direction since the last sample. These X and Y values are changed to percents of the monitor's width and height and changed to a resolution independant value - these represent mouse speed. The 4 following values represent the number of times the same direction is detected sequentially when the X/Y speed is over a threshold value. The bottom center number represent the detected angle of movement (from 0 to 360) and the top center numbers represents the current mouse position and the last position since a direction change was detected.

The X and Y deltas and the counters use exponential smoothing, that is to say, they don't increase or decrease immediately. They work similar to how an estimated download time works using a history of values to present a current value. These numbers are represented by the "Speed required" and "Distance required" configuration settings for Gestures. Lower values means the current value is used much more than historical values and higher values means that historical data is used much more that current values. The "Slower" and "Shorter" values trigger much sooner, but are less accurate.

The counters and X/Y deltas detect direction changes and store important mouse positions, but ultimately direction is determined by comparing the last important stored mouse point and the current mouse point. Using good old trigonometry and right triangles, the length and angle of the movement is calculated. If mouse movement becomes long, but the movement is slow enough not to cross thresholds, the direction will be calculated no matter the X/Y deltas and counters. This "slow" movement uses a multiple of the "Minimum length" configuration setting to trigger.

Things get more complicated when Diagonals are enabled. I've already explained below about the dead zone used to ignore angles that aren't unique enough to be conclusive, but once these are long enough the movement will no longer be ignored. Certain angle combinations are not legal and are ignored to remove the most common errors. For example, a Down cannot be followed by a SouthEast or SouthWest movement. When changing from Down to Left, for example, it's very easy to move at a diagonal of SouthWest instead of making a very clean right angle change.

Once the Right-Click is released, the series of movements is reported and the gesture lookup begins. At first, exact matches are found but when diagonals are enabled and no exact matches are found, similar gestures are found and ordered by similarity. A similar gesture has 1 direction different than the performed gesture, or is missing 1 direction. Gestures that begin the same are considered more-similar and placed first in the suggestions list. When the Suggestions Popup is enabled, this list is shown and the user can close or select the correct gesture. When Auto-corrections are enabled, the program will search the suggestion list and find one incorrect direction that is neighboring the correct direction and automatically execute the first very similar correct gesture.

MouseWrangler almost ready

Before MouseWrangler is officially released, there are two last issues that I need to deal with.

The first issue is the "Dead Zone" - used when diagonals are enabled. The program defines a small area evenly between normal directions and diagonal directions as undefined. While moving at this angle, no directions is declared or detected. When the direction movement is small, the program will wait until the angle isn't inside the dead zone before declaring a direction. Even a long and fast movement won't be declared in this zone. The program needs to override the dead zone once a long enough movement has been made (some multiple of the "Required length" configuration setting). While moving in the dead zone, it just currently looks like the program isn't working.

The second issue is the auto-correction. Currently, only suggestions are shown when an incorrect gesture is made. There is no option for the program to fix a single direction so that it matches an existing defined gesture. For example, if Down+Right+Down is defined, but Down+Right+SouthWest is detected, the program should allow for a configuration so Down+Right+Down will be executed if the angle of the movement is "close enough" to be a just a sloppy Down that's a little too slanted. If the angle is between a Down and a SouthWest, it can qualify for correction, but if the angle is between a SouthWest and a Left, it will not qualify to be corrected as a Down movement.

MouseWrangler Scope

I'm getting close to having to make the "scope" decision. That decision is, 'what is not the job of the mouse gesture program'. It's easy to just add more and more features, but there has to be a golden rule to know when not to add a feature. By default, I don't add any features that interfere with the main function of the program and its normal usage.

MouseWrangler can't compete with all the macro and macro recording freeware that's already available, and I don't think that's its job. MW, however, does have to communicate with other programs to get tasks executed. Currently, MW can simulate keystrokes to activate common Windows hotkeys or to activate shortcuts that are located in the StartMenu or on the Desktop. I've included common examples for the Keystroke and Multiple Keystrokes edit windows to help show some keystrokes that work in almost all Windows programs. Currently, it's not very intuitive to connect running a shortut with a global hotkey and simulating the hotkey with a gesture.

The program should work well by itself and should also not need a secondary program to do the most common tasks. "Does a mouse commonly do this job in all programs?" isn't a good enough rule to define the scope. For example, the gesture program won't be able to resize windows nor does it make the task easier. The gesture program can switch between 2 programs (ALT+TAB), but it can't find the correct program. The gesture program can select all (CTRL+A), but it can't find specific items in a list. Currently, the gesture program can't execute programs, but I think that might fall under its scope because clicking on shortcuts on the Desktop and in the Start Menu is a very common task.

I think the "scope" of the program is to help bridge the gap between what you can do with a keyboard and what you can perform with a mouse. So, executing keystrokes is definitely part of the scope and executing shortcuts seems to fit this scope as well. Running a program with command line arguments may also be needed as a way for more advanced users to expand functionality with external macro programs.

MouseWrangler Diagonals

I've been expirementing with detecting diagonal mouse movement and how it effects normal movements. While I can correctly identify the exact angle of mouse movement, a sloppy or fast movement can be angled enough to be detected as diagonal even when the user likely meant to do another direction.

I'll prefer simple movements that work over more movements that I'll accidentally do incorrectly. My decision is that any diagonal movement would have to be optional. The Up,Down,Left,Right movements just work too well at detecting movements even as they angle diagonally.

To help auto-correct accidental movements, MW will use a system of heuristics to determine when a movement is likely to be incorrect and replace it with the correct movement. For Exaple, if the Gesture is "DOWN+RIGHT" but "DOWN+NE" is detected, the program will look at the angle of the NorthEast direction and determine if it's much less North direction than East. When an auto-correction is made, the program will either show a popup of the most likely choices to choose from, or it will automatically fire the most likely gesture. This will also be a configuration option since both choices are likely to annoy some people.

I was also thinking about limiting movements when diagonals are enabled. I was thinking that a Down movement couldn't follow an Up movement and an Upwards movement couldn't follow an Up movement. This limits the combinations to UP+LEFT, UP+RIGHT, UP+SE, UP+SW [where UP+DOWN,UP+NE, and UP+NW wouldn't be allowed].

When testing combinations, I found that "Z" styles shapes were much easier to do right consistantly than "N" or "M" shapes because a quick "N" is usally made by moving NE+DOWN+NE instead of "UP+SW+UP". I also found that ">" and "

Mouse Wrangler is Beta

The program is now fully functional, but now I'm adding tweaks and new features. Currenty, the program is a little barebones but most of the major work is done. In the future I plan on adding:

- a system tray icon
- a configuration screen [to tweak some settings]
- a "scratchpad" [a small window, usually hidden, that can be triggered to draw on]
- a new action type that will run files
- per-program gestures

Mouse Wrangler Alpha 2

The new test version actually looks like a program. There's more to play with since this verison will actually create a gesture and associate it with a keystroke. The GUI supports right-clicking items to edit them, but the "Delete" command doesn't work yet.

When the defined mouse gesture is detected, it will show a message and show the keystroke associated with it. The actual keystroke simulation doesn't function yet.



Example motions

Mouse Wrangler Alpha

I've created a new program that currently barely does anything. This is the start of research for creating a Mouse Gesture program. I've been testing the sensitivity of the program's ability to detect Up, Down, Left and Right directions while the right mouse button is held down.

The program detects sharp changes in direction to classify motion as either vertical or horizontal motion. Currently, smooth motion is more likely to trigger direction detection rather than fast motion but it seems either is detected rather well. Curved movements and diagonal movements will cause the most errors in detection.

So, why upload it at all? I need you to tell me how well it can detect your motions. I've been testing it will a very sensitive laser mouse, but I'd like to here how it works with other mice, trackballs, and tablets. Once you release the right mouse button, the program will generate a list of detected movements as follows:

Direction DOWN
Direction RIGHT
Direction DOWN

The "defaults.ini" contains a lot of cyptic variables but the most important one will probably be the XPixelThreshold. This variable is the number of pixles the mouse must move either before a direction change is allowed. 30 pixles is a little more than the height of the average command button, so even some small movements can be detected, but it's meant to detect around an inch of movement with a decent acceleration.

My ultimate goal is to allow the user to define a list of directions that will perform a keypress or a series of keypresses (like ALT+F4 to close the current program/page or ALT+SPACE M to minimize the current program). At first, the list will be global, but I'll be moving toward custom gestures for specific programs.