1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-24 07:42:17 +00:00
Commit Graph

12 Commits

Author SHA1 Message Date
wm4
d26104351b m_config: add function to copy all options
Needed to copy the global option struct in the next commit.
2014-10-06 21:49:26 +02:00
wm4
68ff8a0484 Move compat/ and bstr/ directory contents somewhere else
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.

The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
2014-08-29 12:31:52 +02:00
wm4
a7ed3610ca options: remove a global variable
This is probably the last one, at least with my current configuration.
2014-06-11 00:39:14 +02:00
wm4
98c0930f9b m_config: add function to copy subopt-struct 2014-06-11 00:34:41 +02:00
wm4
caa939aa91 options: unify code for setting string and "raw" options
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.

Also, use this to remove the weirdness in the mpv_set_option()
implementation.
2014-05-18 19:21:39 +02:00
wm4
b430c886aa client API: make mpv_set_option set options natively
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.

Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)

I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.

In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
2014-04-22 01:42:57 +02:00
wm4
4d1575173b command: make options property return the list of all options 2014-02-24 22:50:24 +01:00
wm4
942fb43d0c client API: implement setting options using their native type too
This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.

Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
2014-02-24 22:50:23 +01:00
wm4
d8d42b44fc m_option, m_config: mp_msg conversions
Always pass around mp_log contexts in the option parser code. This of
course affects all users of this API as well.

In stream.c, pass a mp_null_log, because we can't do it properly yet.
This will be fixed later.
2013-12-21 21:05:02 +01:00
wm4
dadf3a9a46 m_config: add custom context to includefunc callback 2013-12-21 20:50:13 +01:00
wm4
0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +01:00
wm4
eb15151705 Move options/config related files from mpvcore/ to options/
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.

Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
2013-12-17 02:07:57 +01:00