aboutsummaryrefslogtreecommitdiffhomepage
path: root/options/m_config.h
Commit message (Collapse)AuthorAge
* options: add slightly more sophistcated mechanism for option deprecationGravatar wm42014-12-11
|
* m_config: add function to copy all optionsGravatar wm42014-10-06
| | | | Needed to copy the global option struct in the next commit.
* Move compat/ and bstr/ directory contents somewhere elseGravatar wm42014-08-29
| | | | | | | | | 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.
* options: remove a global variableGravatar wm42014-06-11
| | | | This is probably the last one, at least with my current configuration.
* m_config: add function to copy subopt-structGravatar wm42014-06-11
|
* options: unify code for setting string and "raw" optionsGravatar wm42014-05-18
| | | | | | | | | 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.
* client API: make mpv_set_option set options nativelyGravatar wm42014-04-22
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* command: make options property return the list of all optionsGravatar wm42014-02-24
|
* client API: implement setting options using their native type tooGravatar wm42014-02-24
| | | | | | | | | | | 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.
* m_option, m_config: mp_msg conversionsGravatar wm42013-12-21
| | | | | | | | 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.
* m_config: add custom context to includefunc callbackGravatar wm42013-12-21
|
* Split mpvcore/ into common/, misc/, bstr/Gravatar wm42013-12-17
|
* Move options/config related files from mpvcore/ to options/Gravatar wm42013-12-17
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.