PowerToys
PowerToys copied to clipboard
microsoft
Maximize/Full Screen window within a zone (virtual monitor)
Maximize window within the zone
Maximizing the window currently maximizing it to the whole desktop. It would be useful if it has the ability to maximize within the zone
Adding reference to the full screen suggestion, similar but not the same https://github.com/microsoft/PowerToys/issues/422
Add support for maximizing in the zone with Shift+Double Click on title bar as well.
That way, all methods (I guess) of maximizing in the zone would be supported.
Much like issue #1400, i'm a bit confused what "maximize window within a zone" means.
Is it the believe that zones represent sections of the screen (like just like you could have multiple monitors) and if an app is inside that area of the zone, it should be treated just like it would if it was another monitor? A way to think about it would be a virtual monitor.
@crutkas yes, the idea is to be able to maximize/go fullscreen as if the zone is a virtual monitor. Not sure this is doable. My guess is that is not possible, but we haven't investigate it yet.
Since Shift-Windows-ArrowUp is already doing a maximize within a a zone , couldn't you just map this to Windows-ArrowUp? Same as you do for windows-left-arrow and windows-right-arrow.
Handling the click on the window itself is a different story, hope you could make that work too.
Win Shift up arrow is a Part of aero snap. We would have to override it
The issue with something like this is what determines what some the window is in. Overlapping zones and when the window is across multiple zones would have to be answered.
@crutkas This should be similar to when you're using multiple monitors. I think the default approach is to look at the center coordinate of the window. Anyway, I think this would be a great improvement.
Hey guys,
I just started using PowerTools and wanted to contribute. I uploaded a short video so everyone could visualize the issue that I think is being described.
Hey guys,
I just started using PowerTools and wanted to contribute. I uploaded a short video so everyone could visualize the issue that I think is being described.
That is because you set you base layout with a padding.
The issue here is it sounds like they want a zone to act like a “virtual monitor”.
I would also really like this feature. My main reason for wanting this is having a way to display a Netflix or YouTube video full screen in one of the zones but also a browser window in full screen for reading is nice to have.
I've had to switch to MaxTo because this functionality doesnt exist in PowerToys. I really hope it is added soon so I can switch back! :)
@ChristopherHaws with MaxTo, you can have a windows in full-screen mode inside a region?
@enricogior You can 'maximize' the window, but 'full-screen' is not supported. It works a lot more like standard windows does (windows snap keyboard shortcuts, edge snapping, maximize button, etc). To me it is lot more intuitive than having to hold down the shift key to snap to a region. There are some features I wish it had such as actual full screen support, adjacent windows resizing (like the built in Windows Snap), etc, but to be fair, those features don't exist in PowerToys either.
Here is a link to the issue where they talk about why "full screen" is not supported: https://github.com/digitalcreations/MaxTo/issues/388
@ChristopherHaws
you say "maximize", but if I understand correctly it's just placing the window in the region, not really maximizing it.
In 0.21 we will add directional snapping with Win + Arrows in all four directions, that will improve the user experience when using just the keyboard.
@enricogior just tested it, MaxTo "maximizes" the window to the region when you click the windows maximize button. Not exactly what this ticket is about. It also can not handle full screen windows.
@kbehren as far as I know, the only way to go full screen in a zone/region would be to create a virtual monitor. If a window is full screen, we can resize it to a zone, but as soon as the user interacts with the window, the application will go back to the full screen.
+1 on this request. Here's my particular use case.
I use Visual Studio when developing, and in order to get VS to span across 2 monitors when maximized, I had to use the NVidia Surround mode to make it appear to Windows as a single 7680 x 2160 resolution desktop (2 x 4K monitors).
Fantastic when developing using Visual Studio because I have a single Fancy Zone mapping to that full single desktop and I can maximize VS to that zone.
However, not so fantastic when I want to go fullscreen with a YouTube or Netflix video -- Because it's a single desktop, the fullscreen mode tries to span the whole 7680x2160 (splitting the actual video window right down the middle of the two monitors).
What I ideally want is to create a couple of 3480 x 2160 Fancy zones (one on each monitor - or maybe even two on each monitor) and maximize Edge/Netflix to one of those zones. When I tell the video player to go full-screen, it only expands into that zone - not take over the entire display device/desktop.
Does that make more sense?
Guys, I am using the Virtual Display by Ishadow.com and works like a charm. Support Full Screen and allow many customization. Give it a try https://www.ishadow.com/vdm/
@dacowan in 0.21 you will be able to create zones that span across monitors.
I just tried the mentioned Virtual Display Manager. It works with full screen videos like YouTube. It does not actually create virtual displays that windows recognizes it also just sets areas where windows maximize to you can see it only has one task bar and the effects for snapping still look like it would fill the whole screen and then it doesn't. So handling full screen should be possible.
Just to add on here, being able to identify zones as a virtual monitor would be great.
Using an ultra-wide monitor not all applications support the aspect ratio I'm using and many games run better in full-screen mode than they do in windowed. It would be great to have the ability to set a 16:9 virtual monitor to run those applications in full-screen vs right now zones require them to be ran in windowed.
I'm not currently in a position to work on a PR for this, but I've been playing around with it a bit. It's definitely doable but it does involve hooking into the window WndProc. It's somewhat hacky, and such approaches might not be acceptable to merge. What I can do is provide an existing collaborator with the code I have, so they can see what it takes to make it proper and discuss the feature with the team.
It would definitely be better if the OS had a mechanism to attach a virtual HMONITOR to a window. (which is used to control both monitor and work area) But I doubt they'll add a new api to the OS just for this. I don't think you can write a driver to do it either. afaik services such as mstsc and Citrix do actually hook into GetMonitorInfo and EnumDisplayMonitors, so if that's possible then it might be a better option and worth investigating as some point.
The main element of this approach is hooking into WndProc using SetWindowHookEx to attach ourselves to the WndProc hook similar to what FancyZones already does with the keyboard hook. Except that the WndProc hook is in-process, so this requires a separate lightweight dll (both 64 and 32 bit).
Once hooked, our dll method is called prior to every message that a window received. At this point we're still only observers and cannot modify messages.
The messages we're interested in is WM_GETMINMAXINFO, which is used to control the rect of a maximized window. And WM_WINDOWPOSCHANGING, which does the actual resizing. Simply overriding WM_GETMINMAXINFO fixes 90% of the applications, but apps that play around with fullscreen often have their own logic, such as chrome, so I found that WM_WINDOWPOSCHANGING is a better approach.
First we have to get out of the readonly hook, the trick here is to temporary subclass the window (replacing the window actual WndProc with our own), let the OS call our WndProc, and then immediately undo the subclass before calling the origin WndProc ourselves. our WndProc runs as if it's the real one, so can modify the return value of WM_WINDOWPOSCHANGING.
While processing WM_WINDOWPOSCHANGING we have to check whether FanzyZones wants the window maximized/limited into a zone. We can determine if the window is actually being maximized, and limit the calculated position and size. Once the window is no longer maximized we reset the flag set by FanzyZones. So that if the user drags the window, it automatically restores to it's original size and is no longer bound to the zone.
In my hacky version I replaced the size-to-zone with maximize-to-zone when shift dragging, this works with:
- standard apps: explorer, notepad
- visual studio
- chrome maximized & fullscreen (except a small border at the top, not sure about that yet)
- firefox maximized & fullscreen
- edge maximized & fullscreen (edge fullscreen is unmaximized borderless, so had to deal with that separately or it would detach from the zone premature)
- youtube fullscreen in chrome, firefox & edge
What doesn't work or untested (yet):
- dpi unaware
If a collaborator is interested in this, lemme know.
@dpbuhlig PS: what you're asking for isn't going to help with the game performance. Games that run in fullscreen are more efficient because they have exclusive access to that monitor. The game is running exclusive, not merely maximized. Running it only partially on a virtual area requires desktop composition and by definition isn't exclusive anymore. That's why many games have 'Fullscreen' (Exclusive) and 'Windowed Fullscreen' (aka Borderless window) as options.
Much like issue #1400, i'm a bit confused what "maximize window within a zone" means.
Is it the believe that zones represent sections of the screen (like just like you could have multiple monitors) and if an app is inside that area of the zone, it should be treated just like it would if it was another monitor? A way to think about it would be a virtual monitor.
Hello, I found this issue/feature thread because I wanted to suggest the same thing... I think...
Feature suggestion - Provide a way to toggle the application window to "Borderless" while snapped in a zone. Much like setting the WinForm property to none: "Me.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None" I imagine this would have to be done at the container level of the individual zone. This is where my knowledge runs out.
This would suit my needs wonderfully. When I'm using fancy zones I'm mostly moving and selecting with the keyboard. The maximize, minimize and close window controls in the top border are redundant. The application top border wastes a lot of space especially when the window size decreases and the top border is still the same height.
I don't believe that toggling border style would be a solution to embedded video player "fullscreen." Toggling the application border would apply to the browser application window not the embedded player. I agree fancy zone video playback would be awesome!
enjoy, Tim R
Hello everyone. Just got myself an ultrawide monitor and was searching for the window management tool. Found FancyZones and I really love it (especially because its free and has shortcuts).
To put some clarity into the topic of "Going fullscreen within zone" I am providing this video:
https://user-images.githubusercontent.com/32734275/103167989-7730fe00-4838-11eb-8c0d-ae5d7712a66c.mp4
Video explanation:
There are two zones with the following contents:
- Chrome window with this current GitHub ticket on the left;
- Chrome window with a YouTube video on the right.
And when I go fullscreen with the YouTube video, it only goes fullscreen inside its zone and I can browse freely in my other zone.
This was possible with the help of software called "Virtual Display Manager" (also mentioned by @robk9e), which is not free. Would like to see similar functionality in FancyZones and hoping that this thread is just about it.
Cheers!
@riks1233 thanks for the video, this is exactly what I'm looking for and what I would expect from an implementation of this issue.
Plus, I would add one more feature for "maximized windows" inside a zone. It seems that some programs, in my case Vivaldi browser, behave differently (smaller window toolbar / tab bar) when actually maximized to the physical screen instead of being "maximized" inside a zone.
I think this is really two separate issues. Maximising is supported by many window management apps like MaxTo and DisplayFusion. Fullscreening seems more complicated, and I've only seen one application do it (and even then, whether an app will fullscreen correctly within a zone is a coin flip).
exclusive full screen seems like nearly impossible without digging into drivers at the very least, borderless that in most cases is indistinguishable should just work whenever maximizing works
Suggestion by @ohn8 for different DPI scaling per virtual monitor https://github.com/microsoft/PowerToys/issues/9936
Given the proliferation of Widescreen monitors, this is a critical feature to maximize productivity and usability. Ideally the feature will enable two things:
-
Create virtual monitors to mimic the functionality of a dual-monitor setup where Windows 10 believes there are two discrete monitors. This enables us to "maximize" a YouTube video within a "FancyZone" that was set to behave as a one of the virtual monitors.
-
Within each virtual monitor, FancyZones should behave as it currently does. That is, we should still be able to use FancyZones within each of the virtual monitors.
