summaryrefslogtreecommitdiffstats
path: root/player/lua/osc.lua
Commit message (Collapse)AuthorAgeFilesLines
* osc: redraw on visibility option runtime changeswm42019-12-241-0/+1
| | | | | | This affects behavior when using the "del" default key binding. Sometimes, setting visibility to always did not draw it correctly. This probably fixes it.
* osc: add option to disable santa hatNicolas F2019-12-231-2/+3
| | | | | | | | | | A minority of users have expressed a dislike of hats, calling them "cancer [that] don't belong in software" describing the people who add them as "shitty circlejerks" and "chucklefuck." While I personally disagree with those opinions, it's probably easier to let them have it their way. For that reason this adds the option `greenandgrumpy` to the osc, which allows users to disable the hat.
* osc: set an arbitrary high Z-orderwm42019-12-231-0/+1
| | | | | | | | The main reason for this is just to make show the OSC always above console.lua, instead of a random order. (And this is also the only reason osc.lua was changed to the new API. The old API could have been extended, but lets not.)
* osc: use new overlay APIwm42019-12-231-5/+18
| | | | | | | | | This tries to avoid the update() call if nothing changed. This brings it more into line with the old code (the osd-overlay command simply does not skip the update if nothing changed). I don't know whether this matters; most likely not. Normally, code should try to avoid redundant updates on its own, so it's not the job of the command. However, for the OSC we simply want to reduce the differences.
* osc: display Santa hat for idle logo in DecemberTheAMM2019-12-231-18/+43
| | | | | | | | | | During the 12th month (checked during script initialization), draw a Santa hat on top of the idle message's logo. Slightly refactors and optimizes the drawing process as well: reorder original logo layers and remove redundant holes in them, use a shared line prefix to clear the style and set start position. Signed-off-by: wm4 <wm4@nowhere>
* osc: use video margins only if OSC is visiblewm42019-12-221-6/+5
| | | | | Looks awkward otherwise. This means that even if boxvideo is enabled, nothing gets "boxed" if the OSC is set to auto-hide.
* osc: cleanup boxvideo margin handlingwm42019-12-221-20/+23
| | | | | | | | | | Make sure it gets properly reinitialized when needed. This is especially useful now that the OSC reacts to runtime option changes, which can change the layout too. This may call set_property_number() on the margin properties more often now, but since redundant option changes are ignored now, this shouldn't have any too bad effects.
* osc: full reinit on runtime option changeswm42019-12-221-3/+2
| | | | | | | | | Fuck it, just let's just reinit everything. On a side note, the changelist parameter provided by read_options() (here "list") is now unused. But it's not hard to provide and might be useful for other stuff. So don't remove it from the generic read_options() code.
* osc: cosmetics: remove some excessive whitespacewm42019-12-201-7/+0
|
* osc: react to script-opts runtime changeswm42019-12-201-1/+8
| | | | | | | | | | With special attention to changing osc-visibility. Untested, although osc-visibility works (it's pretty much equivalent to the key binding, so there is not much interesting going on). Somewhat inspired by code posted by github user CogentRedTester. Fixes: #4513
* osc: rearrange hidetimeout/visibiltiy handlingwm42019-12-201-19/+19
| | | | | | | | | | The way how this modifies and backups/restores user option values is a bit of a problem for runtime option changing. Clean this up a little. Now cycling the visibility updates the user option value, but always to "valid" values (unlike hidetimeout used to be used). If the user option value is changed externally (enabled by a later commit), it'll be cleanly overwritten.
* osc: move windowcontrols option code to the right placewm42019-12-201-15/+14
| | | | | | There doesn't seem to be a reason why it was where it was. It should be in validate_user_opts(), which will be important for runtime changing too.
* osc: fix a commentwm42019-12-201-1/+1
|
* osc: fade out if paused and mouse position is outside of OSCwm42019-12-191-5/+18
| | | | | This broke with the recent changes since tick() is not called regularly anymore in paused mode. Add an explicit timer for this.
* osc: fix crash when toggling visibilitywm42019-12-191-1/+0
| | | | | The previous osc.lua related commit removed this function, and trying to call it crashed the OSC. Just remove the call.
* osc: don't run update_margins() every framewm42019-12-191-2/+4
| | | | | This is something recent that also caused per frame log spam, because it tried to update the margins every frame.
* osc: use property notifications and a timer instead of "tick" eventswm42019-12-191-60/+47
| | | | | | | | | | | | | | | | | | | | | | | Traditionally, the OSC used mpv's "tick" event, which was approximately sent once per video frame. It didn't try to track any other state, and just updated everything. This is sort of a problem in many corner cases and non-corner cases. For example, it would eat CPU in the paused state (probably to some degree also the mpv core's fault), or would waste power or even throw errors ("event queue overflows") on high FPS video. Change this to not using the tick event. Instead, react to a number of property change events. Rate-limit actual redrawing with a timer; the next update cannot happen sooner than the hardcoded 30ms OSC frame duration. This has also the effect that multiple successive updates are (mostly) coalesced. This means the OSC won't eat your CPU when the player is fucking paused. (It'll still update if e.g. the cache is growing, though.) There is some potential for bugs whenever it uses properties that are not explicitly observed. (In theory we could easily change this to a reactive concept to avoid such things, but whatever.)
* osc: make margins availablewm42019-12-181-1/+23
| | | | | | | | | This is for console.lua (see next commit). The idea is that console.lua can adjust its offset to the bottom of the window by the height of the OSC. If the OSC is not set to permanently visible, export no margins, because it would look weird to move the console depending on the mouse movement.
* osc: set the wrap style for the title shown with window controlsPhilip Langdale2019-12-121-1/+1
| | | | | | I missed adding this when defining the style used for the video title in the window control bar. The default behaviour is to wrap, but we want to cut the title off when we run out of space.
* osc: use custom symbols for window controlsPhilip Langdale2019-12-111-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | I was recently informed that unicode has official symbols for window controls, and I put together a change to use them, which worked, as long as a suitable font was installed. However, it's not that hard to get a normal system that lacks an appropriate font, and libass wants to print warnings if the symbols aren't in the default font, which will almost always be true. So, I gave up and added the symbols to the custom osd font that we already have. This ensures they are always available, and that they are aligned consistently on all platforms. I took the symbols from the `symbola` font, as this has a suitable licence and the symbols look nice enough. Symbola Licence: Fonts are free for any use; they may be opened, edited, modified, regenerated, packaged and redistributed. Finally, as we now have access to an un-maximize symbol, I added logic to use it when the window is maximized.
* osc: explicitly re-init the osc on a change in border visibilityPhilip Langdale2019-12-091-0/+1
| | | | | | | | | | | | | | I had previously wondered whether to do this, but in my testing with x11 and wayland, the osc was being re-inited on a border toggle already so I didn't add it. However, on win32, things are different and there is no re-init when toggling borders. I belive this is because the active window size doesn't change in anyway, while on x11/wayland, toggling the border actually changes the window size - and that trigger a re-init. So, let's just be explicit and request a re-init when the border is toggled.
* osc: rework window control configuration to add auto modePhilip Langdale2019-12-041-17/+46
| | | | | | | | | | | | | | | | To aid in discoverability, and to address the most common case directly, I'm adding an 'auto' mode for the window controls. In this case, we will show the controls if there is no window border and hide them if there are borders. This also respects the option being toggled at runtime. To ensure that it works in the wayland case, I've also made sure that the wayland code explicitly forces the option to false if decoration support is missing. Based on feedback, I've split the config in two, with one option for whether controls are active, and one for alignment. These are new enough that we can get away with ignoring compatibility.
* osc: ensure that window control show/hide zone is handled dynamicallyPhilip Langdale2019-12-041-6/+6
| | | | | | | | | | | | | | | | | | | As preparation for adding the auto mode for window controls, we need to make sure that the controls can be successfully toggled at runtime, rather than only being able to configure them once at startup. Right now, there is a problem with the handling of the show/hide zone for the window controls. The previous fix for #7212 was to avoid registering the input mapping for the window control show/hide zone. If there is no input mapping, then there is no input, and the zone is a no-op, even if it exists. But this only happens at startup. After that point, the input mapping doesn't exist and cannot be turned on. In this change, I'm switching the approach; we now go back to always registering the input mapping, and instead, we zero out the show/hide zone if window controls are disabled, and set its size appropriately if they are enabled.
* osc: don't show error if windowcontrols=yesPhilip Langdale2019-12-021-1/+2
| | | | | | | | I always intended for this to be accepted and mean "right" but I made it show an error for any value that's not explicitly recognised (while considering all unrecognised values to mean "right"). So let's explicitly recognise "yes".
* osc: don't always set window control keybindingsDudemanguy2019-12-011-4/+6
| | | | | Only set the window control keybindings if the window control option is actually enabled. Fixes #7212.
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | This is necessary to avoid breaking input behaviour in the 'idle' state when not playing a video. Otherwise, the mouse area starts off covering the whole window and blocks normal input.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-301-0/+3
| | | | | | It seems logical to account for the window controls if `boxvideo` is in use (which has the effect of reducing the size of the video so that the osc is not covering the video).
* osc: fix operation when window controls are disabledwm42019-11-291-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale2019-11-291-6/+28
| | | | | | | | | | | | | | | | I missed these due to only testing with my personal osc config. The deadzone needs to be correctly handled for the window controls, or they will fail to appear when the mouse is close to or over them. In the process of doing that, I realised that the controls should respect the barmargin, if set. This is because the controls should remain aligned when layout=topbar and as the control bar is top aligned, it should be equally affected if the user needs to set the barmargin. I also fixed a mistake in trying to the use the mpv-osd-symbols font for the window controls.
* osc: implement pseudo client side decorations via OSCPhilip Langdale2019-11-291-7/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, if window decorations are not present, either because they were disabled, or because the platform doesn't support them (eg: gnome-shell on wayland), there are no window controls, meaning it is not possible to minimize/maximize/close a window without knowing keyboard shortcuts. While you can imagine various ways of offering client side decorations, it is attractive to consider using OSC because that is functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* osc: Unify bottom and topbar codeJan Janssen2019-10-281-179/+31
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* osc: add mouse mid-button as alias to shift+left buttonRicardo Constantino2019-09-211-0/+3
|
* osc: add feature to bottombar to not cover the videowm42019-09-191-1/+47
| | | | | | | | | | | | | | | | | | | | | | Normally I use the OSC like this: not at all, but have a key binding that does "cycle osc" to show it. And in that case, I don't really want it to overlap the damn video. I could use the zoom/pan options to move the video out of the way, but this is also sort of annoying. Likewise, you could write a script or so which does this automatically if the OSC appears, but that's still annoying, and computing values for these options such that the video is moved correctly is tricky. So I added a bunch of options that set explicit video borders (previous commit), and a option for the OSC to use them (this commit). Disabled by default, since I'm afraid this is too awkward and unpolished, especially with OSC default settings. I'm also using "osc-visibility=always". Effectively, making the OSC appear will box the video, and making it disappear (by unloading osc.lua) will restore the video back to normal.
* osc: improve look of seekrangesJan Janssen2019-09-021-78/+185
|
* osc: fix accidentally skipping files when seeking with sliderfatalis2018-06-041-0/+2
| | | | | | | When seeking near the end of the file and the next file loads, seeking continues on the next file at the same position and then immediately the file after that. This patch stops slider seeking when a new file is loaded, which is the standard behavior of many other players.
* osc: leave only demuxer cache duration and limit its refresh rateRicardo Constantino2018-01-141-19/+16
| | | | Sorta requested in #5390
* osc: add seekbarkeyframes as a user optiondudemanguy2018-01-031-2/+3
|
* osc: check if demuxer cache has not reached eofRicardo Constantino2018-01-021-3/+3
| | | | Avoids flickering stream cache status while filling the demuxer cache.
* osc: hide cache if not forced for local filesRicardo Constantino2017-12-261-13/+7
| | | | | Also hide cache if 'cache-used' is 0 (usually means video fits entirely within demuxer-cache-duration or stream cache is disabled).
* osc: make seek ranges rendering optionalpavelxdd2017-12-261-0/+4
| | | | | This commit adds a new osc setting `seekranges` to control the seek ranges visibility.
* osc: show demuxer cache buffered amount in byteswm42017-12-231-2/+6
| | | | | | | | Same as previous commit, but for the OSC. (A bit of a waste to request demuxer-cache-state at least twice per frame, but the OSC queries so many properties it probably doesn't matter anymore.)
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-7/+7
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* osc: make cycling visibility an input.conf key bindingwm42017-11-031-1/+1
| | | | | As builtin script, it should not register global key bindings, and add them to input.conf instead. This is similar to what stats.lua does.
* osc: render seek ranges a bit less uglyChrisK22017-11-021-1/+1
|
* osc: render seek rangeswm42017-11-021-0/+26
| | | | | | Pretty fucking ugly, but I'm not a UI designer. Of course only does something with --demuxer-seekable-cache.
* osc: fix rare stack overflow when changing visibility modeAvi Halachmi (:avih)2017-09-231-1/+6
| | | | | | | | | | | | | Under some conditions, hide_osc() was calling render(), which then called hide_osc() again, and so forth, until the stack overflows. Tracking the exact conditions where this happens (and then managing them to prevent it) is an excercise in futility. Remove the osc directly - instead of going through the entire rendering procedure just to end up rendering nothing. Fixes #4900 .
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* input: use mnemonic names for mouse buttonsJames Ross-Gowan2017-09-031-48/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv's mouse button numbering is based on X11 button numbering, which allows for an arbitrary number of buttons and includes mouse wheel input as buttons 3-6. This button numbering was used throughout the codebase and exposed in input.conf, and it was difficult to remember which physical button each number actually referred to and which referred to the scroll wheel. In practice, PC mice only have between two and five buttons and one or two scroll wheel axes, which are more or less in the same location and have more or less the same function. This allows us to use names to refer to the buttons instead of numbers, which makes input.conf syntax a lot easier to remember. It also makes the syntax robust to changes in mpv's underlying numbering. The old MOUSE_BTNx names are still understood as deprecated aliases of the named buttons. This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in the codebase, since I think both would benefit from using names over numbers, especially since some platforms don't use X11 button numbering and handle different mouse buttons in different windowing system events. This also makes the names shorter, since otherwise they would be pretty long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they weren't used. Names are the same as used in Qt: https://doc.qt.io/qt-5/qt.html#MouseButton-enum
* OSD message: "Drop files or URLs to play here."nodiscc2017-05-311-1/+1
| | | | Add "or URLs" to the default OSD message when mpv is launched without parameters. Since this works flawlessly with youtube-dl integration, the fact that you can drop URLs directly to the window should be advertised more.
* osc: also add processing for axis_up/down eventsRicardo Constantino2017-04-251-4/+6
| | | | | | Considered semantically equivalent with mouse_btn3/4. This is a preemptive fix for upcoming changes to AXIS_* events.
* osc: add user_opts.boxmaxchars for box layout title limitAvi Halachmi (:avih)2017-04-191-3/+6
| | | | | The default of 80 is conservative to allow relatively wide fonts, but with many common fonts a bigger number can be used without overflow.
* osc: add volume icons to osd font and use themRicardo Constantino2017-04-191-3/+4
| | | | | Glyphs taken and based on U+1F507 to U+1F50A from Symbola, which is available under public domain: http://users.teilar.gr/~g1951d/
* osc: move volume left of fullscreen buttonRicardo Constantino2017-04-191-16/+17
|
* osc: bottom/topbar: add fullscreen buttonRicardo Constantino2017-04-191-4/+13
|