| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
WS_POPUP windows cannot be maximized, so instead of forcing it with
unavoidable side-effects, change the window style before maximizing to
make it work correctly.
|
|
|
|
|
|
| |
This makes the context menu items accessible from the window menu,
which can be opened by either right-clicking on the title bar or
left-clicking on the mpv icon on the title bar.
|
|
|
|
|
|
|
|
|
| |
Currently if VO init fails, the context menu is leaked. Additionally,
init/uninit are in the VO thread, while other accesses are in the GUI
thread.
Fix this by moving them to the GUI thread, similar to other resources.
This also lets init function take the mpv HWND in the next commit.
|
|
|
|
|
| |
Use the multitouch API. To disable system's defualt mouse emulation,
set --native-touch=yes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After explorer is restarted while show-in-taskbar is false, toggling
show-in-taskbar no longer puts mpv back to the taskbar until it's
unfocused and refocused.
My guess of how this works is that the HWND of the taskbar is cached,
and setting the WS_EX_TOOLWINDOW style internally uses this value to
show/hide the taskbar button. But after explorer is restarted it no
longer works until its taskbar state needs to change (such as focusing).
Only then it realizes the HWND is no longer valid and refreshes it.
Fix this by following MS documentation on this: the window needs to be
hidden before changing the style, and be shown after that. This
unfortunately can sometimes introduce a brief window flash, but it
fixes the problem.
|
|
|
|
|
| |
When the window style changes, use WS_EX_TOOLWINDOW style to exclude
the window from the taskbar and Alt+Tab switching.
|
| |
|
|
|
|
|
|
|
| |
win32 does not respect --native-keyrepeat option, and native key
repeat has been broken since 0ab3482f73a199b2e839ad4ec0a4b21adc1e75d5.
This lets mpv respect the --native-keyrepeat option on win32.
|
|
|
|
|
|
|
|
|
| |
Windows 10 top bar height cannot be adjusted individually when
WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is
fixed in Windows 11.
To keep consistent window look remove the border on each side, but only
on Windows 10.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows 11 draws border regardless, so we are 1px off on window size,
blending border with one line of video. Fix that by adding the border to
our internal windows size calculation.
Windows 10 on the other hand has a bug where specifying left and top NC
area will trigger title bar drawn in full height always. Keep old
behaviour in this case. Also while there is similar "visible" border
there, it seems to be transparent on Windows 10.
For high contrast themes, don't adjust title bar height and instead
remove WS_CAPTION to have the same border all around the window, as DWM
doesn't make borders invisible in this case.
|
| |
|
| |
|
|
|
|
|
| |
If the window-maximized is set while in fullscreen, it needs to be applied
when leaving fullscreen, as noted in the comment.
|
|
|
|
|
|
|
|
|
|
|
| |
With runtime geometry change, currently it only results in a
SetWindowPos call to resize the window. However, SetWindowPos doesn't
change the window maximized state, so Windows still thinks that the
window is maximized even though it no longer covers the whole workspace.
This results in visual glitches, and if the window is dragged afterwards
it's "restored" again.
Fix this by correctly setting the window maximized state in this case.
|
|
|
|
|
| |
Similar to other platforms. Also make sure that the x/y positions are set
on geometry update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VOCTRLs are processed in the GUI thread through the mp_dispatch mechanism.
Window dragging requests are asynchronous on x11 and wayland, so the item
is processed quickly without problem. However, currently win32 uses the
SendMessage call for this, which is synchronous. This causes the playback
to stop while the dragging request is being processed because the
dispatch queue is blocked.
Work around this by setting a flag instead if the window dragging is
requested, and immediately starts dragging after processing the dispatch
queue. This doesn't block the dispatch queue while also avoiding any
extra latency added by the Windows message queue.
|
|
|
|
|
|
|
|
|
|
| |
57367377505b6b2edc87004fa3192d831d515aa5 removed the check because it was
not needed to prevent fullscreen window from being dragged. However, this
causes an undesirable behavior: when using a touch screen to drag a window
on Windows 11, DWM shrinks the window content a bit with an acrylic
backdrop to indicate that the window is being dragged. This also happens
when trying to drag the window in fullscreen. Add the check to prevent
this from happening.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, VO dragging logic is hardcoded into each VO, where a left mouse
button down event unconditionally begins dragging if the VO dragging test
passes. This method is extremely unflexible as the VO has no knowledge of
what is happening in the input system: while begin dragging with the second
click of a doubleclick is undesired, it cannot determine whether a click
is a double click or not because it's determined by the input system.
The better way to do it is to handle it somewhere in the downstream
consumers of the events instead, as they have more information to make
this decision. The input system is the perfect place for this as the logic
for checking doubleclick already exists. So just issue a begin-vo-dragging
command if it detects a left mouse button down which isn't also a
doubleclick in this case, and delete all hardcoded VO dragging logic
in win32, x11, and wayland.
Note that this solution hardcodes left mouse button down for now, but
because the VO dragging is now centralized, it's possible to make more
improvements, such as a deadzone mechanism to fix the conflict with
MBTN_LEFT mouse bind.
|
|
|
|
|
|
|
| |
This allows begin-vo-dragging command to initialize a vo dragging request
for win32. Also set dragging to release all keys like for other platforms.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
|
|
|
|
|
| |
Same as X11. An accurate dpi scale should always be reported and
UNFS_WINDOW_SIZE shouldn't take dpi scale as an additional multiplier.
|
|
|
|
| |
Use the DWM API to enable and disable compositor transparency.
|
|
|
|
|
| |
Replace various dead links with live replacements or archives.
Less friction for anyone who wants to look up these references.
|
|
|
|
| |
GetMessageW will indefinitely block after the window is destroyed.
|
|
|
|
|
|
| |
Needed in case the timer solution fails. Note that this will leave the
mode indicator in the language bar showing the original mode until
a key is pressed.
|
|
|
|
|
|
| |
Some IMEs initialize to composition mode for new windows, which is
undesirable for keyboard control.
Default to alphanumeric input to solve this.
|
|
|
|
|
| |
By default the IME candidate window appears on the top left corner
of the monitor. Move it to the video window for sane behavior.
|
|
|
|
| |
WM_UNICHAR is sent by some 3rd-party IMEs.
|
|
|
|
|
|
|
|
|
|
| |
The IME is useful for text input. Additionally, Alt+Shift input language
switching doesn't work when IME is disabled even when the languages don't
require IME.
Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly.
Reverts bf6b981367e45c3f926d3e667bba3f3ed6e9dc37.
|
|
|
|
| |
This completes the support for all supported desktop platforms.
|
|
|
|
|
|
|
|
| |
In commit c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8
long-path support was enabled for mpv without actually
making sure that there was no code left that used the
old limit (260 Unicode chars) for buffer sizes.
This commit fixes all but one case.
|
|
|
|
|
| |
57367377505b6b2edc87004fa3192d831d515aa5 mistakenly changed the mode
from 644 to 755. Change it back.
|
| |
|
|
|
|
|
|
|
| |
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
|
|
|
|
|
|
|
|
|
| |
windowrc in vo_w32_state is actually client size, for hit test we need
proper window size. When border is disabled those sizes are the same,
but when only title bar is disabled it is not.
Reduce the hit area to more sane values when the border is not
drawn to minimize amount of covered client area in borderless mode.
|
| |
|
|
|
|
|
| |
Add more refresh rates for get_refresh_rate_from_gdi() now (Nov 2023) that
165 Hz is common, 240 Hz is on the rise, and 120 * N Hz is the future.
|
|
|
|
|
|
|
|
| |
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
|
|
|
|
|
|
|
|
|
|
|
|
| |
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
|
|
|
|
|
|
|
| |
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
|
| |
|
|
|
|
|
|
|
|
|
| |
Some users report visible black frames during window resize, this should
not happen in most cases. Let's just keep stale content as it is less
distracting. While still clearing on first window paint to avoid white
background.
Fixes: #12642
|
|
|
|
|
|
|
|
|
|
|
| |
Several window resizing operations (i.e., --auto-window-resize,
border dragging with --keep-aspect-window, Alt+0/1/2) cause the
window to detach from the snapped borders. This patch resolves
this by recording to which borders the window is snapped, and
using this info to determine how the window should be placed after
resizing.
Closes https://github.com/mpv-player/mpv/issues/6588
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes white background appearing for short period of time before
first frame is drawn. Clear to black as this is way less distracting
than bright white flash.
Borderless window and fullscreen seems to be initially not
drawn/transparent, so no need to clear it to black. Only when
decorations are enabled (--border) the issue happens.
Fixes: #12549
|
|
|
|
| |
We have to support all changing states, not only borderless.
|
|
|
|
|
|
| |
Fixes window resizing in borderless mode after adding WS_SYSMENU.
Fixes: 172d9be3005c6a85f4f139f1dedccefe26ea8d91
|
|
|
|
|
|
| |
Fixes missing icon when initial window is created without caption.
Fixes: #12472
|
| |
|
|
|
| |
uses the same mechanic as for x11
|
|
|
|
|
|
|
|
| |
Apparently removing WS_CAPTION disables some window animations. Instead
adjust non-client area to not draw title bar.
Note that we do not account for difference in real border size and
invisible one, but seems to work correctly.
|
| |
|
|
|
|
|
|
| |
I don't think in fullscreen mode it makes sense to enable rounded corners.
We can add another option if someone needs it, but for now `window_corners`
affects only the window as one would expect.
|
|
|
|
| |
Allows to set preference for window corners rounding for DWM.
|
|
|
|
| |
Fixes too small initial window size.
|
|
|
|
| |
DWM makes part of left, right and bottom border invisible.
|
|
|
|
| |
Fixes: #11432
|
| |
|
|
|
|
|
| |
Fixes: #11610
Fixes: 9feeb324eddd9ed73ae667e10275f663d70f7544
|
|
|
|
| |
It is quite unnecessary to log every window move.
|
|
|
|
|
| |
Fixes: 57ba77fc736f6976bc114974f5955c972139740f
Fixes: #12220
|
| |
|
| |
|
|
|
|
|
|
| |
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
|
|
|
|
|
|
|
| |
It was actually always wrong, and no one ever noticed. This currently
returns the size of the entire display area and not one actual monitor.
Fix this by calling get_monitor_info and then doing the appropriate
subtractions. Checked by @CrendKing and fixes #12172.
|
|
|
|
|
|
|
| |
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. S |