view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    [$guard] = $mpv->observe_property_string ($name => $coderef->($mpv,
    $name, $value))
        These methods wrap a registry system around mpv's "observe_property"
        and "observe_property_string" commands - every time the named
        property changes, the coderef is invoked with the $mpv object, the
        name of the property and the new value.

        For a list of properties that you can observe, see the mpv
        documentation <https://mpv.io/manual/stable/#property-list>.

        Due to the (sane :) way mpv handles these requests, you will always
        get a property cxhange event right after registering an observer
        (meaning you don't have to query the current value), and it is also
        possible to register multiple observers for the same property - they
        will all be handled properly.

        When called in void context, the observer stays in place until mpv
        is stopped. In any otrher context, these methods return a guard
        object that, when it goes out of scope, unregisters the observe
        using "unobserve_property".

        Internally, this method uses observer ids of 2**52
        (0x10000000000000) or higher - it will not interfere with lower
        ovserver ids, so it is possible to completely ignore this system and
        execute "observe_property" commands yourself, whilst listening to
        "property-change" events - as long as your ids stay below 2**52.

        Example: register observers for changtes in "aid" and "sid". Note
        that a dummy statement is added to make sure the method is called in
        void context.

           sub register_observers {
              my ($mpv) = @_;

              $mpv->observe_property (aid => sub {
                 my ($mpv, $name, $value) = @_;
                 print "property aid (=$name) has changed to $value\n";
              });

              $mpv->observe_property (sid => sub {
                 my ($mpv, $name, $value) = @_;
                 print "property sid (=$name) has changed to $value\n";
              });

              () # ensure the above method is called in void context
           }

  SUBCLASSING
    Like most perl objects, "AnyEvent::MPV" objects are implemented as
    hashes, with the constructor simply storing all passed key-value pairs
    in the object. If you want to subclass to provide your own "on_*"
    methods, be my guest and rummage around in the internals as much as you
    wish - the only guarantee that this module dcoes is that it will not use
    keys with double colons in the name, so youc an use those, or chose to
    simply not care and deal with the breakage.

    If you don't want to go to the effort of subclassing this module, you
    can also specify all event handlers as constructor keys.

EXAMPLES
    Here are some real-world code snippets, thrown in here mainly to give
    you some example code to copy.

  doomfrontend
    At one point I replaced mythtv-frontend by my own terminal-based video
    player (based on rxvt-unicode). I toyed with the diea of using mpv's
    subtitle engine to create the user interface, but that is hard to use
    since you don't know how big your letters are. It is also where most of
    this modules code has originally been developed in.

    It uses a unified input queue to handle various remote controls, so its
    event handling needs are very simple - it simply feeds all events into
    the input queue:

       my $mpv = AnyEvent::MPV->new (
          mpv   => $MPV,
          args  => \@MPV_ARGS,
          on_event => sub {
             input_feed "mpv/$_[1]", $_[2];
          },
          on_key => sub {
             input_feed $_[1];
          },
          on_eof => sub {
             input_feed "mpv/quit";
          },
       );

       ...

       $mpv->start ("--idle=yes", "--pause", "--force-window=no");

    It also doesn't use complicated command line arguments - the file search
    options have the most impact, as they prevent mpv from scanning
    directories with tens of thousands of files for subtitles and more:

       --audio-client-name=doomfrontend
       --osd-on-seek=msg-bar --osd-bar-align-y=-0.85 --osd-bar-w=95
       --sub-auto=exact --audio-file-auto=exact

    Since it runs on a TV without a desktop environemnt, it tries to keep
    complications such as dbus away and the screensaver happy:

       # prevent xscreensaver from doing something stupid, such as starting dbus
       $ENV{DBUS_SESSION_BUS_ADDRESS} = "/"; # prevent dbus autostart for sure
       $ENV{XDG_CURRENT_DESKTOP} = "generic";

    It does bind a number of keys to internal (to doomfrontend) commands:

       for (
          List::Util::pairs qw(
             ESC   return
             q     return
             ENTER enter
             SPACE pause
             [     steprev
             ]     stepfwd
             j     subtitle
             BS    red
             i     green
             o     yellow