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.

Feature Freeze

Both ArsClip and Rename Master public betas will now only be updated for bugfixes until they are officially released.

Both programs will include a new optional Setup program [already included in the last RM public release]. I might rename the Setup.exe to Setup(Optional).exe or something like that because even though the word "OPTIONAL" is shown in all caps on the information screen of the setup, I'm sure I'll catch some grief for it.

For RM, the majority of the changes are bug fixes and most of the bug fixes are for the Scripting View. For new features, there's one new renaming Step, a new default view, improved Scripting View visuals, and a new Format Variable dialog.

For AC, the changes are much less and include only a few bug fixes. For new features, the most notable changes are the new right-click trigger and the "(Column Break)" option.

Rename Master - a new default view

One of the biggest challenges for the new Scripting View is converting older users that don't want to re-learn how to use the program. My first attempt was a Scripting View toggle button. The toggle button lets the user switch to the older renaming options interface. This lets them use something familiar to do tasks, but my hope was that they'd learn the new interface and see it's actually much more powerful and still pretty easy to use once the initial learning time has been invested.

This is not the case. Some users didn't even find the new toggle button and switched back to older versions of the program. As some noted OS developers have stated, there is a group of users that do not like changes - even when the change is better. I try not to make any drastic changes and at least make an option to revert when the change is major, but this isn't always enough.

With the latest Public Beta, I've added more features that may help easy the transition to the new view. First, a list of each step type is automatically generated [in a disabled state] for the Default script (the script that is loaded every time the Rename Master is started). This is more similar to the previous interface where the user searches through a list of renaming options and enables only the items he wants to use.

This new default view has many advantages for learning. First, the user can quickly explore each item without having to add each step one at a time. This makes for an easier way to discover and explore all options. Second, this gives the user time to discover later that you can have multiple steps of the same type and you can order the steps any way you want [something the user couldn't do previously]. The user doesn't even have to learn to use the "New Step" button this way. Also, all the previous renaming options have been condensed into only 9 separate steps, where before the user would have to search thru over 20 items to find the operation the user wants.

The look has also been altered to be less cluttered. Each step used to show 4 buttons on the right side for moving, disabling, and deleting the step. In the new view, these buttons are only shown when the step is expanded or the right-most part of the step is clicked (this is currently not documented and has no visual cue). The Scripting Steps are designed to mimic how the "Security Center" works where a title is shown for each item and clicking on it expands it to show further details. This control design isn't too common yet, but it's now a standard guideline for showing information in the most recent Windows operating systems and should be normal sooner than later.

Also, the text is now set to grey when the item is disabled since the Enable/Disable button is not shown by default. This look is also more consistant with how items in Windows are shown to be disabled. Changing a setting will automatically enable the step; otherwise, it would be confusing to change the item and have no effect of the filename.

Drop me a line and let me know what you think of the latest Public Beta. I, personally, think it's better and should help not only previous users but also new users understand the new Scripting View. Unfortunately, I'm only one person, so my opinion is rather limited.