How many turns of the wheel in a day

Reading long documents, working through source code, moving down a page and then another page — the index finger accumulates a remarkable distance over a working day. The wheel was designed for small adjustments, not for several hundred consecutive rotations, and the complaints that follow from doing it anyway are familiar to anyone who types for a living. The browsers solved this years ago: press the middle button, get an anchor, move the mouse away from it and the page scrolls with the distance, release and it glides to a stop. That solution exists inside a browser window and nowhere else.

FlowWheel takes that behaviour out of the browser and makes it global. The source is published, the licence is permissive, and the platform coverage is honest rather than ambitious: Windows, and only Windows.

What it does when you press the middle button

In any window, pressing the middle button places a small anchor on screen. Move the pointer away from the anchor and the content begins to scroll, faster the further away it goes; bring it back towards the anchor and the scroll slows to a crawl. Release the button and the motion continues briefly under its own momentum, decelerating until it stops. The physics is not decorative — it is the point, because a scroll that starts and stops abruptly is only marginally better than turning a wheel.

Five acceleration curves are provided: linear, exponential, logarithmic, and an S-shaped curve, plus a custom one for people who know exactly what they want. The choice matters more than it sounds. A linear curve suits scanning a page quickly; a logarithmic one gives fine control at short distances with coarse movement further out, which is what reading dense text requires. And the default behaviour of stopping when the button is released can be changed to a toggle: press once to start scrolling continuously, press again to stop, which is the mode people use when both hands are needed elsewhere.

Small tool, longer feature list

Multi-monitor scrolling is the feature that is hardest to find elsewhere. With two screens side by side, one holding code and the other holding the document it implements, a single drag in the middle scrolls both at once, in step. That is not the same thing as a split view, because the two windows do not have to belong to the same application or even be arranged by the same program — they simply scroll together because the pointer is between them.

Settings are remembered per application, so a code editor can use a slow logarithmic curve while a browser uses a fast linear one, and the switch happens automatically when the window under the pointer changes. The anchor fades out while scrolling and returns when the motion stops, so it does not sit in front of the text you are trying to read. Applications that should never be scrolled this way — games, video players, anything with its own pointer handling — can be excluded, and the list can work in the other direction as well, allowing the feature only inside specified applications.

The privacy position is stated plainly and is the right one for a utility that installs a global mouse hook: no telemetry, no network access, settings stored locally, and the code published under a permissive licence so that the claim can be checked rather than believed.

Where it actually helps

Source code is the clearest case. A file of several thousand lines used to mean turning the wheel until the finger ached; now it means holding the middle button and drifting the pointer downward while the code moves past at a constant rate. The eyes stop chasing the cursor and the attention goes to the logic, which is the whole argument for smooth scrolling in one sentence.

Long documents and papers benefit for the same reason: the reading position moves at a rate you control with the distance of your hand rather than in discrete jumps, and a page becomes a continuous surface instead of a series of steps. And the side-by-side case — a specification on one side, the implementation on the other — is where the multi-screen feature stops being a novelty, because keeping two views aligned by hand is a small chore repeated dozens of times an hour.

What to know before using it

Three things, none of them fatal. It is Windows only: the other platforms have their own ways of achieving something similar through system-level input configuration, but their native support is a different conversation and this tool does not pretend to cover them. The trigger takes a little learning — the default middle-button drag does not feel exactly like the browser version, though the trigger can be rebound to the side buttons, which most people find more comfortable once they have tried it. And it needs administrator rights, because a global mouse hook is what makes the whole thing possible; the code is available for inspection, but the permission prompt the first time is still a moment of hesitation, and it should be.

This does one small thing: it redesigns a gesture that everybody performs hundreds of times a day into something the hand does not have to fight. The project is young and the audience is still small, but the release history shows steady work rather than a weekend experiment. If reading documents and code occupies more than a couple of hours of your day, the improvement is immediate and the cost of trying it is a few minutes.

The honest summary

The engineering is modest and the effect is not: a global hook, a physics model for deceleration, a small set of curves and per-application memory. What makes it worth installing is that the operation it improves is one you perform constantly and never think about, which is the category of change that produces the largest improvement for the smallest effort. The limits are the ones stated above — one platform, an unfamiliar trigger at first, and a permission request that deserves a moment's thought. None of them is a reason to skip it; all of them are reasons to know what you are installing.