ThreeFingerDragOnWindows synthesises a macOS-style three-finger drag on Windows

The gesture works by holding the left mouse button for you

The problem this app solves is small, specific and annoying. macOS lets you drag a window or select text with a three-finger swipe on the trackpad. Windows Precision touchpads do not offer that, and the workarounds people reach for, such as the tap-and-drag setting, behave differently enough to be unsatisfying. The project aims to bring the macOS-style three-finger dragging functionality to Windows Precision touchpads.

The mechanism is emulation rather than a new gesture recogniser. As the README describes it, the app lets you drag windows and select text by emulating a cursor drag by holding down the left mouse button. The application reads the touchpad directly, recognises the three-finger contact, and then drives the mouse as if you had pressed and held the left button and moved the pointer.

That design has a consequence worth thinking about before you install it. The app is synthesising a mouse gesture, so it sits in the same input path as the mouse, and it competes with whatever Windows already does with three fingers. The README is direct about that: to make the drag work without interferences, you have to disable the Tap twice and drag to multi-select behaviour and all of the default three-finger swipe behaviour through Touchpad settings in Windows preferences. The gesture is therefore not additive to the built-in behaviours, it replaces part of them.

The scope is a desktop utility, not a driver or a system service, and the project says the drag works with a simple touchpad gesture, with the specific benefits being window dragging and text selection.

Raw touchpad input comes from RawInput.Touchpad

To see a three-finger contact, the app cannot use the normal pointer events, because Windows turns three-finger input into swipes and navigation before an application ever sees it. It needs the raw report from the touchpad device.

That is where emoacht/RawInput.Touchpad comes in. The README lists it as the library that allows the app to get the raw input of the touchpad, and notes that it is included in the source code as TouchpadHelper.cs rather than being pulled in as a package dependency. The repository layout confirms the shape of the project: a Visual Studio solution, ThreeFingerDragOnWindows.sln, with the main application in a ThreeFingerDragOnWindows/ directory and a separate ThreeFingerDragElevator/ directory.

The second directory is the interesting part of the architecture. The app needs to control the left mouse button system-wide, which is a privilege a normal desktop application does not have. The README lists dahall/TaskScheduler as one of the libraries used and says it is used for the skipUAC, which refers to the elevation helper. The separate elevator project and the task scheduler library together suggest the design: a small elevated component is scheduled through the Windows Task Scheduler so that the user is not prompted with a UAC dialog on every launch, while the main WinUI 3 process stays unelevated.

The interface layer is WinUI 3, built on the Microsoft.UI.Xaml library, which is what produces the three-tab configuration window shown in the README screenshots, with a Touchpad tab, a Three Finger Drag tab and an Other Settings tab.

Windows defaults have to be turned off or the gesture fights itself

The single most common way this app disappoints a new user is documented in one line of the README, and it deserves more attention than that. Make sure to disable the Tap twice and drag to multi-select behaviour and all of the default three-finger swipe behaviour via Touchpad settings in Windows preferences, for the drag to work without interferences.

Think about what that means in practice. Windows assigns three-finger input to navigation gestures, and the app wants three-finger input for dragging. Both cannot own the same physical gesture. Disabling the Windows behaviours means losing things like the three-finger app switch and the three-finger workspace swipe in exchange for the macOS-style drag. For some people that is a good trade, and for others it is a bad one, particularly if the person navigates by keyboard shortcut and rarely uses those swipes anyway.

The tap-to-drag setting is a separate conflict, and a subtler one. It already provides a drag gesture from a different input, and if it is enabled, the two paths can fight over the same interaction.

There is a second limitation that is about hardware rather than settings. The project targets Windows Precision touchpads, and the app is not presented as working on any touchpad. On a laptop with a basic clickable touchpad, or on a device with no touchpad at all, the raw input the app depends on will not arrive, and there is nothing in the README describing a fallback.

For a reader evaluating this, the settings conflict is a precondition, not a troubleshooting step. Get it wrong and the app looks broken.

Installation runs through the Microsoft Store

There is no command line install path here, and no package manager entry in the README. The distribution channel is the Microsoft Store, with the store listing linked from the homepage and the README badge.

https://apps.microsoft.com/detail/9MSX91WQCM2V?

That is the store page for the app, and it is also the direct download link the README embeds for the installer badge. For a user, the path is the Store, find the app, install it, and then look for its tray icon.

One failure mode is documented, and it is a common one for modern Windows applications. If the installation fails, your computer might need to have the Windows App SDK redistributable installed, and the README links the Microsoft download page for it. WinUI 3 applications depend on that runtime being present, and on a stripped-down or older Windows installation it will not be there by default.

https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads

After installation, the app lives in the notification area rather than in a window you launch from a shortcut. To open the configuration pane you click the ThreeFingerDragOnWindows tray icon on the Windows taskbar. That design is deliberate for a background utility that intercepts input, and it is also the first thing to check if someone tells you the app is not running.

Tray icon and scheduled task are the two moving parts

Two of the three third-party libraries exist for a single reason: to make a background Windows utility behave properly. H.NotifyIcon is listed as the API for the Windows taskbar tray icon in a WinUI app, and it is the piece that lets the application exist in the notification area and be reopened from there.

The other one, dahall/TaskScheduler, is used for the skipUAC. Since the app has to synthesise mouse input for the whole session and may need to run a helper above the user's normal privilege level, the natural Windows mechanism is a scheduled task, which can be registered once and then started without a per-launch elevation prompt. The separate ThreeFingerDragElevator/ directory in the repository is the counterpart of that mechanism on the code side.

The library list is short, and the project is written in C# against Microsoft.UI.Xaml. For a reader deciding whether to fork it, that is a comfortable stack: a WinUI 3 desktop app, a touchpad raw input helper vendored into the tree, a notification area icon library, and the Task Scheduler interop.

The privacy side of the project is also documented rather than implied. The repository carries a PRIVACY.md at the root next to the LICENSE, and the fact that a small input utility ships a privacy statement is a reasonable expectation for something that reads your input devices.

One more build detail for contributors: the app can be built and run in Microsoft Visual Studio or Jetbrains Rider, which is the practical requirement for anyone who wants to change the touchpad handling.

MIT licensed, and the author has stopped using Windows

The licence is MIT, and the repository has a LICENSE file at the root. You can use, modify and redistribute the code, including commercially, provided the copyright notice and the licence text are retained. That is a licensing fact rather than legal advice, and it matters for a project of this size, since a fork that fixes a Windows update breakage can be shipped without a negotiation.

The maintenance record needs reading carefully, because the project status section is unusually candid. The README says the main goal of this project has been achieved, and the app is stable and usable, but that there are still a lot of potential improvements and features that could be added in the future, and a lot of platform-specific issues that could be investigated and fixed.

Then the sentence that matters for the long term: the author, Clément Grennerat, is not anymore using Windows as his main OS, but will continue to maintain the project and is open to contributions from the community. That is an honest statement of what maintainer continuity means in practice. The commits still land, the last push was on 2026-09-26, and the repository is not archived, but the person who writes the code is testing on a machine that is no longer his primary system.

The release history supports the same reading. Version 2.0.7 was published on 2025-12-20, after 2.0.6 on 2024-07-29 and 2.0.5 on 2024-07-23, so the shipped build is recent while the tag cadence between 2.0.5 and 2.0.6 was short. A useful consequence of the MIT licence is that a community fork is a realistic path if a future Windows update breaks the raw input path, and the vendored TouchpadHelper.cs makes such a fork straightforward.

The alternative is to keep the Windows gestures and give up the drag

There are two honest alternatives, and neither is really equivalent.

The first is to accept what Windows already offers. Touchpad settings provides tap to drag, and the built-in three-finger swipes cover app switching and workspace navigation. Using those means no extra software, no store install, and no conflicts, at the cost of not having the macOS-style three-finger drag. For a user who drags windows rarely, this is the right answer, and it is the one the README assumes you have already considered.

The second is to move the interaction to a different device or platform. A Mac gives the gesture natively. A KVM-style hardware solution, where the gesture is handled by a separate device rather than by software on the host, also sidesteps the software conflict entirely, though it adds hardware to buy and manage.

The difference in approach between those and this project is where the recognition happens. Windows decides what three fingers mean before an application sees the input, so this app goes to the raw device report instead and synthesises the mouse behaviour itself. That is why it needs the raw touchpad library, why it needs the elevated helper, and why it needs you to switch off the built-in gestures. An approach that stayed inside the normal pointer event path would not conflict with the system gestures, but it would also not be able to claim the three-finger drag.

So the choice is not really drag versus no drag. It is software plus configuration against the built-in gesture set, with the software route buying one specific interaction at the cost of a few others.

Editorial conclusion

ThreeFingerDragOnWindows fits a Windows Precision touchpad user who wants the macOS three-finger drag without changing operating system, and who is willing to disable the built-in tap-to-drag and three-finger swipe behaviours that otherwise intercept the gesture. It does not fit a user of a non-Precision touchpad, a user who wants to keep the default Windows gestures, or anyone looking for a project with an active roadmap, since the maintainer states the main goal has been achieved and that he is no longer using Windows as his main OS. Before installing, disable Tap twice and drag to multi-select and the default three-finger swipes in Touchpad settings, then confirm the app starts from its tray icon.

Frequently asked questions

Official sources

1. ClementGre/ThreeFingerDragOnWindows on GitHub
2. License: MIT
3. Project website
4. README
5. Releases