New version was posted on 15th of April 2005!

Have you ever paid attention to striking difference in the thickness of forefingers in X11/Unix and MS Windows users, respectively? The latter have much more muscular forefingers that often suffer from chronic aches in their joints. They also much more often develop mouse arm, pain in the neck and shoulders, and other troubles known as Repetitive Stress Syndrome and associated with excessive usage of a pointing device. Why?

The explanation is simple: all X11 users benefit from the fact that no significant effort is needed to place a selected chunk of text into the clipboard and to fetch it from there. Unfortunately, this is not the case in MS Windows. Moreover, different applications require different procedures. For example, to simply copy the selected piece of text to the clipboard, you may need to
- choose Edit -> Copy from the menu
- press a button with two pieces of paper on it
- use keyboard shortcuts Ctrl-Insert or Ctrl-C.

But this is only the beginning of the story. How do we paste the contents of the clipboard into an X-application? By middle-clicking once. (Note how the middle or the ring finger get their fair share of exercise.) How do they paste in Windows? In yet more ways than they copy:
- choose Edit -> Paste from the menu
- press a button with a piece of paper on a clipboard
- press a button with a brush
- press a button with a bottle of glue
- Shift-Insert, Ctrl-V or Ctrl-P
and so on.

Besides that, the X11 users don't have to click-click-click with their mice only to move the focus from one window to another or to lower/raise a window - simple operations that require lots of clicks or just are impossible (lower!) in MS Windows.

Over the years Microsoft (being under the user community pressure) has undertaken some half-hearted attempts to bring the fewer-clicks functionality to Windows. Yet the most far reaching TweakUI (see PowerToys for Windows XP for XP version) goes only about one fifth of the way. Indeed, to an average X11-user the expression "X-Mouse" means the following:

1. Keyboard focus follows mouse pointer instantly (the only one that can be achieved with TweakUI, annoyingly enough accompanied by the "quality" to raise the window upon click).

2. Marked text is placed into the paste buffer instantly on left button release.

3. Pasting is done with a single middle button click. (The latter two are implemented in couple of applications - only to feel more acutely the lack of it in the rest of the windows!)

4. Ability to lower windows with right button click on window decoration.

5. Autoraise (if engaged) is delayed relative to input refocusing.

All of the above is what this "True X-Mouse Gizmo" is about:-)

Recommended usage. Download [any place], make a shortcut to TXMouse.exe and move the shortcut to your start-up folder. To uninstall, remove the shortcut from the start-up folder [and remove TXMouse.exe]. When upgrading from previous version, stop it if running and replace TXMouse.exe. For try-out purposes first-time users can as well just "open" the executable directly in their web-browsers.

The Gizmo is designed to work on 98/Me/2000/XP/.NET/2003. However, it has not been tested on 98/Me as thoroughly as on 2000/XP.

Usage is free, but only those who have sent a postcard^(*) are entitled for support:-) Postcards with a view over your home-town or other local sight signed with encouraging words and your E-mail address are to be sent to

Andy Polyakov
Sven Hultinsgata 12a
Chalmers University of Technology
Gothenburg
SE-412 96 SWEDEN

: the X-cursor, visual feedback

In order to facilitate text replacement (i.e. mark, copy, mark elsewhere, paste to replace), a heuristic algorithm to determine when not to perform X11-ish copy is implemented. Namely, when you select a chunk of text in order to replace something else by it, you naturally expect it to be copied to the clipboard. But the next thing you do, when you select the text you want to "write over," you don't expect clipboard content to be zapped upon middle button release! To avoid the latter, you should copy your text in the traditional way, by means of Edit -> Copy, Ctrl-C, etc (an alternative, better way is described in the end of this section). In this case when you select the text to replace right after that, TXMouse notices that the clipboard content has been changed by someone else (you), and assumes that this time the selection will not be copied to the clipboard. After pasting by clicking the middle button, TXMouse is happy to copy things on marking again.

As you see, things are getting a little complicated. This is why a visual feedback is provided, so that you can always know the status of your copy-paste business. Whenever a copy on left button release is about to be performed, a tiny X next to the cursor (as depicted above) appears as soon as the mouse is moved with the left button depressed. If you don't see this X next to the cursor when you click and drag, then no copy will be performed and the content of the clipboard will remain intact.

Another thing to look at is an X icon in the system tray. If it looks light red or "happy:" , TXMouse is ready to copy on mark. However, if you have manually copied any content to clipboard, the icon changes as soon as you move the mouse. The X flips and changes its hue, in other words "turns its back on you." This means that copy-on-mark is temporarily off - until you paste the clipboard content with the middle button click (but see even below).

Now, what if you are suddenly not happy with the state of your mark-copy affairs? You have started to drag the mouse, and you see that TXMouse is/isn't going to copy what you are marking! Relax, there is an instant way to turn copy-on-mark on or off without even lifting your finger from the left mouse button: a click on the middle button toggles between the two modes. If you want to copy what you mark and there is no X next to the cursor or the X icon in the system tray is showing you its grim back side, just click on the middle button, and the cursor, the system tray icon, and the readyness to copy to clipboard will change in an instant. Or, if you want to mark something for replacement and see the X-ized cursor and the shining red X icon, click on the middle button, and the marking will not be copied on the left button release.

Tweaking the Tweaker

There is no program that is good in all situations (even though TXMouse comes pretty close to that:-). Some applications have certain semantics for click-and-drag events and interfering with them the way TXMouse does might have undesirable effects, graphic editors being obvious notable example. X servers for Windows, obviously, do not need this functionality, because it is already available in X11. In short, we want to exempt some windows from True X-Mouse behaviour. And of course we want to be able to tweak some basic parameters, like button emulation and double-click intervals.

This is achieved by adding a new key to the HKEY_CURRENT_USER hive. We all know that Microsoft officially discourages to touch The Registry, threatening that your system will go down for ever. The reassurement comes from the following facts:

• The key is optional. If you don't want to add it, don't do it.
  
• It is created on the per-user basis (in HKEY_CURRENT_USER, which does not affect boot-up procedure or other users).
  
• You are not modifying any existing keys.
  
• You can always delete it.
  

Here is an example of a registry script that creates the registry items read by TXMouse:

Note that what appears in this particular example is actually not needed - these are the defaults that are hard-coded into TXMouse. If (and only if) you want to change them, download TXMouse.reg and modify it to your liking with any text editor (for example, with Notepad). After that you can double-click on the (modified) file and confirm that you want this information to be written to the registry. For the new settings to take effect, you have to either restart TXMouse or double-click the X icon in the system tray and close the window that pops up. The settings are re-read on window closing (the purpose of the window itself is discussed below). Alright, but how do you know what all those values are?

AutoRaiseDelay. If set to non-zero value, window auto-raise is enabled (which DK hates from the bottom of his heart). The value is amount of milliseconds (in hexadecimal notation!) to elapse before window which has the input focus is brought to the top in the Z-order hierarchy. Why to delay at all? Well, because you don't want an awful lot of windows to pop up on you along the path of your cursor whenever you move your mouse. If you don't enable auto-raise, the only way to make a window front-most is to click on any part of window decoration. This is another quality which distinguishes this gizmo. TXMouse prevents windows from raising when you click inside them! Absolutely great if you have three of four partially overlapping windows and want to work with them, yet keep the current Z-order. This is very useful feature for the poor bastards who are forced to use MS Excel at work, as the only way to get anything done in Excel normally giant window is to click somewhere.

RapidClickInterval. But how about sinking windows down to the bottom of desktop? This unique feature is a true crown jewel of TXMouse! (At least according to DK.) To sink a window, you can right-click on any part of the window decoration. You still can access window menus that are normally opened by a right-click on the title bar. This can be achieved by the means of a "long right-click" (clicking-holding-letting go). RapidClickInterval is the amount of milliseconds (hexadecimal) that you have to hold down the right button before you let it go in order to access the title bar menu instead of sinking the window. The default hexadecimal 0x14D is 333 ms which works pretty well in most situations.

ExemptedClasses. In terms of Win32 programming interface, each window is of a certain class. Without going into detail about what these classes (or programming interfaces) are, let us see how we can find out what class a particular window belongs to. If you double-click on the X icon in the system tray, True X-Mouse Tracking and Debugging Window appears. All open windows are listed there along with their class names and titles. Hopefully you can identify the concerned windows by their titles. For example, Hummingbird eXceed windows have classes that all look like EXCEEDW:MWCLIENT0. The part after the colon may vary, but the class always starts with "EXCEEDW:." By adding "EXCEEDW:*" ("*" means "anything") to the value of ExemptedClasses, you exempt all eXceed window from being ever touched by TXMouse (why? because eXceed is an X11 server, and the X-functionality is already there). Besides of eXceed, the default list of exempted classes covers Starnet X-Win32 X server, AT&T VNC viewer, Citrix ICA client, various versions of Microsoft RDP client, MS Paint, Basilisk Macintosh emulator, and Win9x command.com window (the latter just has to be there because of some bugs in it; note that 2000/XP command window cmd is of a different class). Remote session software should be exempted because of the chance that the remote session is running its own TXMouse in which case the input to the remote applications gets clobbered. Also, the remote session might run an application that TXMouse doesn't suite very well - like a graphic editor where clicking-and-dragging is used for drawing, not for copying. And that's why MS Paint is also in the default list. Another good candidate for exemption is MS Excel where you often have to click-and-drag in order not to copy but to change colour, formatting, etc.

ExemptedModules. Unfortunately the mechanism described above is not universally applicable, as some applications "borrow" their window class names from toolkits they utilize. Most notably, VMware shows as AfxFrameOrView42, a widely used MFC widget. Then ActiveX mojos are embedded/subclassed and cannot be recognized by ExemptedClasses code. That's where ExemptedModules become handy: this code identifies windows by owner modules - .exe, .dll, .ocx, etc. If you feel slightly confused by the the contents of this paragraph or want to know more about the connection between, say, MS RDP and mstscax.ocx, please read the license and support section again ;-)

TwoButtons. This is not a third button emulation (as XFree86 users might expect)! However, if you have a two-button mouse, you can still benefit from TXMouse. Set "TwoButtons"=dword:1, and all the TXMouse functions of the middle button, namely, paste and toggle copy-on-mark, will be transferred to the right button. The other right-button functionality - sink windows and access title bar menus - is still preserved.

Caveat lector/Annoyances

• X-cursor doesn't show up in console/cmd windows (nor RunAs windows). Windows design does not permit to replace cursor in such windows.

• Console/cmd windows are brought up in Z-order hierachy upon mouse click inside window. Windows design does not permit to override this behaviour.

• When certain applications "owning" clipboard contents are terminated, tray X icon turns its back on you.

• When you're marking text in Acrobat[Reader], cursor can't be flipped. As soon as you release left button tray X icon turns its back on you. Sometimes it also complains about "an error while copying to the clipboard." All this is due to the fact that Acrobat, for unknown reason, consumes all available CPU power when you're marking text. The point is that it goes into a polling loop and effectively stops recieving asynchronous events which get queued and congest at button release.

• Properties dialogs in Visual Studio and Folder List in MS Outlook are hard to "catch," they just disappear when you try to slide cursor their way. This is a "generic" annoyance that comes with Active Window Tracking. To work around pick an element by clicking on it, slide the cursor to where you expect the properties dialog to appear, press Alt-Enter and , "pinpoint" the dialog.

Credits

GUI is slightly modified Paul DiLascia's TRAYTEST sample published in March 1996 issue of Microsoft System Journal. All modifications are tagged with #if[n]def DiLascia preprocessor directives.

Jim Tilander stands for counseling on MFC programming matters and clickable URL in About dialog.

This page is written by the mystery DK person. Well, except for the licensing terms section...