Powertoys: Alt+Drag or Windows+Drag to move windows

Created on 6 Sep 2019  路  35Comments  路  Source: microsoft/PowerToys

Summary of the new feature/enhancement

Moving windows using the mouse relies on hitting a small target, especially on high-resolution screens. Add an option to move entire windows by alt-dragging or windows-dragging them, anywhere on the window except perhaps the resize area.

Proposed technical implementation details

Stefan Sundin has done great work on AltDrag: https://stefansundin.github.io/altdrag/ . With permission, I'd use this as an initial reference.

Alt+Drag or Windows+Drag could be implemented as part of FancyZones, activated with a toggle.

Help Wanted Idea-New PowerToy In progress

Most helpful comment

Thanks for suggesting this @mattroyal. I am ok with AltDrag being used as a reference.

Maybe when it is done and AltDrag becomes somewhat obsolete, then maybe Microsoft can send me a donation. Or at least buy me lunch (I live in Seattle now). 馃槈

All 35 comments

Alt+Drag would be nice, but also Alt+Resize would be just as helpful. Especially if the window snaps to borders.

Alt+Drag and Alt+Resize with snapping is my dream for windows management on Windows system.
Unfortunetely AltDrag (app) doesn't play along with my current AutoHotKey "Keyboard Second Layer" (uses LAlt), as it eventually start acting up and I have to close and reopen it. Having this funcionality in PowerToys would be wonderful.

Thanks for suggesting this @mattroyal. I am ok with AltDrag being used as a reference.

Maybe when it is done and AltDrag becomes somewhat obsolete, then maybe Microsoft can send me a donation. Or at least buy me lunch (I live in Seattle now). 馃槈

@stefansundin
if you are interested, you may consider adding your awesome tool as a PowerToys module.

@stefansundin
also, consider that it will be possible to put a link to your web page in the powertoys settings with a text like "Donate to author", so users that want to donate for your work will know how to do it.

I鈥檝e decided to take a stab at this PowerToy.

Hi @loligans
great to hear!
It would be nice to make the 'Alt' key configurable since in some apps 'Alt drag' is actually used for other purposes. You can take a look at the FancyZones code for an example of how to make a key configurable through the settings.
If you have any question don't hesitate to ask.

Yeah I've been utilizing the fancyzones project as a frame of reference. They share very similar functionality, so it's made it easier to get started. It's open for discussion, but for an initial version here are the settings that can be modified.

enum class Action
{
    /* No action will be performed. */
    Nothing,
    /* Move a window. */
    Move,
    /* Resizes a window. */
    Resize,
    /* Minimize a window. */
    Minimize,
    /* Lower the window. */
    Lower,
    /* Make a window topmost. */
    AlwaysOnTop,
    /* Center a window on the screen. */
    Center,
    /* Close a window. */
    Close
};

/*Whether the window should be focused while dragging*/
bool focusWindowWhenDragging = false;
/*Middle clicking the title bar sends it to the back*/
bool lowerWindowByMiddleClickingTitleBar = false;
/*Snap to monitor borders*/
bool snapToScreenBorders = false;
/*Snap to borders of other windows*/
bool snapToOutsideOtherWindows = false;
/*Left mouse button action*/
Action leftMouseButton = Action::Nothing;
/*Middle mouse button action*/
Action middleMouseButton = Action::Nothing;
/*Right mouse button action*/
Action rightMouseButton = Action::Nothing;

/*Hotkey to activate the module. Defaults to ALT*/
PowerToysSettings::HotkeyObject activationHotkey = PowerToysSettings::HotkeyObject::from_settings(false, false, true, false, VK_MENU, L"");

Hi @loligans
I should let you know that we have already plans for a "Always on top" module with a specific UI in mind.
My suggestion is that you start with implementing just the Alt-drag functionality and then we can chat about adding more functionalities.
Sounds like a plan?
Thanks you.

Yeah that's fine. @enricogior

Is there a way I can reference the branch I'm working on in this github issue? That way I can get feedback from the other engineers on this feature.

Hi @loligans
fork this repo, create a working branch on the forked repo and post here the link to that branch.

Here is the working branch from the forked repo: https://github.com/loligans/PowerToys/tree/dev/loligans/altdrag

Just wanted to document this here:

I added a low level mouse hook since I'll need to process mouse position while the module activationHotkey is pressed. According to the LowLevelMouseProc documentation if the hook procedure takes longer than the LowLevelHooksTimeout timespan defined in HKEY_CURRENT_USER\Control Panel\Desktop the hook procedure will timeout and be silently removed without being called.

The implementation is nearly identical to the keyboard hook we have set up already.

Because the mouse will be sending in a flood of events compared to the keyboard, we'll likely want to minimize the amount of processing done on the hook. For now I'm gonna do everything on the hook and measure if we are well below the LowLevelHooksTimeout threshold.

If we're reaching close to the LowLevelHooksTimeout threshold then we may want to only process as much as necessary on the hook and then before returning trigger an event on a worker thread.

Thoughts? @enricogior

Hi @loligans
excellent point. We also need the low level mouse hook for other PowerToys, so I opened a dedicated issue to track the technical details of its implementation https://github.com/microsoft/PowerToys/issues/638
Feel free to add your considerations there.
For now I suggest you continue on the assumption that there will be a mouse hook that will guarantee to not exceed LowLevelHooksTimeout.

while this could be associated with FancyZones, i think they are distinct different asks. I think we should track work that spans both and understand it may be the same/shared engine under the hood but i don't think we should merge the two as a holistic entity.

Status on this?

This is not something we are currently planning for a v1. Great idea and if a community member wants to partner with us, happy to merge it in sooner. It is a great idea

@ent3r This issue is currently blocked on https://github.com/microsoft/PowerToys/issues/638.

@loligans
we changed the way we handle low level hooks, since there were several problems with centralizing the hooks in the runner.
Now each module has to implement its own hooks.
Let me know if you need more information.
Thanks.

Alt+LMB Drag anywhere inside a window and Alt+RMB Drag to resize is literally _the only_ UI conceit that I miss from certain Linux desktop GUIs.

Since we're already resizing windows in FancyZones, could the mouse hooks be rolled into that?

@RexQuantum , I agree with the idea of ultimately rolling it into the PowerToys bundle, however https://github.com/asvc/altdrag plays nicely with the latest PT build.

For what it's worth, I am using Win as the control key.

I love altdrag, but the way in which it resizes windows somehow creates (entirely cosmetic) rendering errors in the resize animation.

If at all possible, I'd love for the powertoys implementation of altdrag to use a method which does not hurt the resize animation!

test

While it works fine with most applications there is indeed some where it's flaky (as in the capture above) or totally buggy as with LibreOffice 7.

I don't' know why is there multiple way for a Windows application to be resized but the way/API LibreOffice uses is not compatible with AltDrag.

LibreOffice 6 was slightly flaky (small latency for rendering) but worked. With version 7 it's unresponsive (have to kill LibreOffice).

So yes, a PowerToys implementation could be a good thing :-)

@C-Duv , I have experienced the same. Glitches can be reduced down to the "Libreoffice 6" level by turning off Skia. I do keep OpenCL enabled though.

So, at this point in time, is it really possible to use AltDrag and FancyZones together?

Personally I was not successful.

@acicovic , it is indeed possible, but not without glitches/artefacts. In other words — experience is subpar compared to *nix window managers, but tolerable in overall.

Could anyone post screenshots of the AltDrag and PT settings?
I cannot make it work.

@C-Duv , I have experienced the same. Glitches can be reduced down to the "Libreoffice 6" level by turning off Skia. I do keep OpenCL enabled though.

Thanks! LOv6 level is bearable :)

@crutkas @enricogior I am working on it. If you have any rough spec for this feature, I'd love to take a look at it馃槉.

@crutkas Is there a way to compile only the selected powertoys in the msi installer. I have made a working prototype (drag only) and would like to test the installer, but I don't think my PC can handle compiling the whole project馃槄. Pls help.

Umm, not really/easily. Do a full release compile of the project, get a coffee then iterate. If you don't do a full rebuild, should be fine. The installer itself is pretty quick to compile. KBM takes the longest typically to compile.

Worth noting: AltDrag breaks with a couple "modern" apps (not necessarily UWP). Like MS Teams.

AltDrag breaks

Could you elaborate? I don't experience any _major_ issues.

I hope this is right place: I think AltDrag suggests "alt" as default modifier but actually it's bit "risky" to use alt as default modifier key. Many 3D/graphic/design apps use alt+left. Please take a look here https://forum.kde.org/viewtopic.php?f=83&t=139423. Now, after long time Plasma uses meta(win) as default modifier: https://bugs.kde.org/show_bug.cgi?id=399375.

Maybe both default "alt" modifier key and name should be changed? People will use "win" anyway IHMO.

@Eneen , that's right, I shall just note that AltDrag is rather configurable:

image

Was this page helpful?
0 / 5 - 0 ratings

Related issues

saahmedm picture saahmedm  路  3Comments

Martin-Hausleitner picture Martin-Hausleitner  路  3Comments

anish-94 picture anish-94  路  3Comments

SWinxy picture SWinxy  路  3Comments

21cpDev picture 21cpDev  路  3Comments