-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incremental zoom from center issues #2740
Comments
Good feedback. Let's keep it on the PR. If we can't merge an acceptable PR then we will leave it as-is. Need to define desired behavior for incremental zoom when already snapped. My thinking is it should honor snapped edges as long as room exists. Beyond that I don't know but it becomes complex, and different monitor layouts could be quite messy. |
I think this can be closed now |
uuuhh.... @NBruderman, @clsid2 why close this? I opened this issue just now to describe the problems that still exist after the integration of #2710 and #2736 aka. #1515 . |
@Sp3EdeR after the latest patch, what issues are still not fixed from the list above? |
@Sp3EdeR I also want to know what isn't fixed. Could you use 'strikethrough' on whats fixed. |
Crossed out resolved issues, raised new issues after testing the merged PR #2743 . I think the issue is that this condition may need to be modified to |
If the point overlaps the rect border, it is considered "not in." It first hits full screen constraints. Next it expands, in testing. |
If we are zooming to scale, why should it use any proportion other than that of the video? Is there a purpose to growing "to scale" while leaving unnecessary black bars? Should it take the larger of the "zoom" dimensions and the existing dimensions? |
I can make it honor existing vertical dead space, which has a less surprising result when you zoom. But horizontal dead space is a different matter, since it calculates the zoom by the video window and not the video size itself. |
I just highlighted any changes and potential deviancies from requirement. If you guys deem that this should not be handled, then I cross it off the list. I just wanted to make sure that the software requirements are defined within this issue ticket before I would contribute any code, since my previous contribution that spawned this thread waited over two years. :) |
More of a discussion. I think a similar fix to the other would work. If the window is already proportional to the video, zoom constrained. Otherwise, zoom bottom right. |
Can you review latest patch? |
@adipose, I have tested the behaviour of the latest patch and added issues I've found with it into that PR. May I suggest discussing the desired behavioural requirements before further patchsets? Perhaps, once the requirements are specified, a test set could be derived, and maybe I could even help with the implementation (given I have enough time on my hands). |
That patch is closed so perhaps it is best to update this thread until we have resolved all issues. I think it works more reasonably now than it did. I haven't checked the auto-hide issue yet. |
If you want to write up a proposal of what you think should change, I'm happy to review and discuss with @clsid2 . I believe that "Limit window proportions on resize" should be honored now. Can you confirm? |
For the current iteration of this feature (2.2.1.25):
|
2% step is fine |
Updated.
It now is considered on the monitor when it touches the bottom or right edges.
I changed it to use bottom right when zooming fails to grow on the current monitor. This should solve this issue, I think.
I don't understand the steps you are describing here. I'll look at the other issues soon. |
It already ignores it, because it just checks the video window size, which doesn't include any hovering panels.
With the new code this should work automatically, because it tries not to grow outside the monitor unless it's out of space. |
Tested #2797:
Overall, I think the behaviour is very good now. I've updated the issue description with the current state. The issue can be considered closable, the remaining issue is not severe in my opinion. |
Can you please demonstrate this with some specifics:
|
As an example with frameless view (measured with Spy++):
|
Thanks. I see the problem--it wasn't using the right method to get the video window. You can try again. |
Tested the change and it works correctly now! One minor issue I found in this version just now is when the window fills the width of the screen (HD), and then I zoom in, there is an incorrect zoom step:
I have updated the description again. |
Fixing that incorrect step was difficult. I wanted to preserve some nice behaviors, so now it will:
I did this in two passes, causing a bit of a rewrite. You will need to retest all behaviors. |
The faulty step is now fixed. I found the following issue, it is good otherwise:
|
Can you explain what you mean by "close a video"? |
I mean File -> Close |
OK, you can check it again. It should refuse to zoom unless media is loaded. |
You have not crossed this out. I believe it works differently depending on the setting. |
I re-checked it and I find no more issues. And yes, I re-checked the "limit window proportions on resize" logic too. Fair enough. I will cross out everything now. This design looks all good to me. |
The #1626 issue and #2710 PR changed the behaviour of the incremental zoom feature. Some resulting regressions from this change:
When using a multi-monitor setup, this feature is no longer able to increase window size to larger than the current monitor's viewport. The window cannot overflow onto a second or third monitor and it cannot overlap the start menu, even if the window is always-on-top.DONE IN allow zoom past monitor size #2743It is generally hard to zoom a video in more than what is displayable now, one has to corner drag, and move. While this is a rare use-case, I imagine it may still be there sometimes.DONE IN allow zoom past monitor size #2743The "Limit window proportions on resize" feature no longer has an effect on this function, it always always limits the window proportions on resize.DONE IN improvements to incremental zoom #2797When viewing a video that doesn't fit the viewport exactly, and incrementing past the fully fitted window size, an additional black border is shown. For example, if the window is longer than the monitor space, then black borders are added to the top-and-bottom.DONE IN allow zoom past monitor size #2743After merging #2743, the following regressions are present (FYI, @adipose ):
When the start menu is displayed on the bottom of the screen, when snapping the window against the bottom start menu, the zoom function grows the window on the bottom-right. Expected: the window is zoomed towards the monitor centre, until the current monitor is filled.On a multi-monitor setup, the window is on the left monitor, when snapping the window to the right edge of the monitor, the zoom function grows the window on the bottom-right. Expected: the window is zoomed towards the monitor centre, until the current monitor is filled.After the result of PR #2797, the following issue is present:
Autohidden interface elements still influence the window growth when shown (hovered) vs. hidden.There is one incorrect zoom-in step once the window fills the screen widthWeird zoom behaviour after closing a videoNote for the future:
Initial versions of the #1515 PR contained a screen edge snapping logic on resize. It may be reused in case of a potential update.
The text was updated successfully, but these errors were encountered: