Basically, the declared option name and the name passed to the
parse_obj_settings_list() must be the same.
Fixes the issue addressed in #1550, but differently.
This catches a few cases which basically call:
m_property_strdup_ro(..., ..., NULL)
which would return NULL strings. This should generally be avoided
(although it's allowed due to reasons), and it seems most callers
actually intend this to mean M_PROPERTY_UNAVAILABLE.
Instead of absuing m_option to store the property list, introduce a
separate type for properties. m_option is still used to handle data
types. The property declaration itself now never contains the option
type, and instead it's always queried with M_PROPERTY_GET_TYPE. (This
was already done with some properties, now all properties use it.)
This also fixes that the function signatures did not match the function
type with which these functions were called. They were called as:
int (*)(const m_option_t*, int, void*, void*)
but the actual function signatures were:
int (*)(m_option_t*, int, void*, MPContext *)
Two arguments were mismatched.
This adds one line per property implementation. With additional the
reordering of the parameters, this makes most of the changes in this
commit.
This used to display the property type, but it was not always correct or
even available. The way the property mechanism works, we can know this
only at runtime.
The function tag_property() in command.c passed a key action with empty
path to m_property_read_list. This is normally not valid, because key
actions are supposed to access sub-paths. But it's kind of inconvenient
to check for this case in tag_property(). So make it valid by providing
a m_property_unkey() function, which turns a key access to "" into a
top-level action.
We've just checked whether a sub-path started with "name/", but that
changes behavior whether the property name has a trailing '/' or not.
Using a helper function to split of path components avoids this problem.
Setting string options to strings over the m_option fallback (i.e.
M_PROPERTY_SET_STRING is called if the option type is CONF_TYPE_STRING)
failed. This was because m_option_parse() returns 0. 0 still means
success, but the property code tried to be clever, and considered 0 not
a success in order to disallow setting flags to an emtpy string (which
in turn is allowed, because the command line allows flag options without
parameters).
Fix this by removing the overly clever code.
This could happen when e.g. using the "set" command on options/title (a
string option), and also was a problem for the client API.
Closes#610.
This automatically allows accessing properties like chapter-list and
track-list to be read as mpv_node. This affects all properties which use
m_property_read_sub() and m_property_read_list().
Allows retrieving properties by their native values (or something close
to it), rather than having to go through string conversion. The caller
could actually just copy the value itself and then use the m_option
functions to convert it to mpv_node, but maybe it's more flexible this
way.
Some code accessed m_option.name to get the property name. (Maybe only
show_property_osd() had a significant use of it.) Remove that, and
remove setting names and dummy names as well.
The old code usually assumed that the name was set, and
show_property_osd() used it to get the proper name of deprecated
aliases.
The "vf" property was listed as "vf*". Not sure why that was done, but
it works without anyway.
This adds a mechanism for easier export of sub-properties. The following
commits will make use of it to export fine grained information about
certain things. The sub-property mechanism reduces the amount of code
needed to export a data value to 1 line.
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.
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.
