[vlc-devel] Recommendation: Configuration.c update to allow reuse of command-line parser
Mark Moriarty
mfmbusiness at earthlink.net
Wed Nov 10 14:11:43 CET 2004
I'm trying to understand if it is feasible to rework the function
config_LoadCmdLine to make it reuseable, as a way to also handle dynamic
control of VLC.
1. Split off the module and options discovery (generation of list,
longopts, shortopts) into a standalone function, run at VLC startup, so that
the list of possible things to work with is separate from parsing the actual
command being generated. Store these items long-term (persistent), so that
they can be reused. I'm talking about the code from about 1272 - 1414 of
the current configuration.c, going from " /* List all modules */"
To " /* Close the longopts and shortopts structures */"
2. Split off the options discovery/setting code into a standalone
procedure. Pretty much the code from lines 1416, "* Parse the command line
options", to line 1533, (just before " /* Free allocated resources */").
The new function, (2), would include a variable to allow designation of the
calling function type. A "1" could indicate console, in which case the
current print statements can be used as-is. A "2" could indicate anything
else, so that the print statements would be replaced with a returned list of
error/warning messages. The calling function would be responsible for
acting on the returned list of error/warning/whatever messages.
(2) would pretty much perform the current processing, plus it would do a
check to see if there is already a pre-existing variable "tacked-up",
matching the particular longopt or shortopt identified. If there is a
variable in-place, that means the longopt/shortopt is an on-the-fly
parameter, the new function would set that variable.
A concrete example:
In the section starting at line 1424:
/* A long option has been recognized */
if( i_cmd == 0 )
{
module_config_t *p_conf;
char *psz_name = (char *)p_longopts[i_index].name;
/* Check if we deal with a --nofoo or --no-foo long option */
if( flag ) psz_name += psz_name[2] == '-' ? 3 : 2;
/* Store the configuration option */
p_conf = config_FindConfig( p_this, psz_name );
Add a test:
If ( var_exist(p_input, psz_name) ) /*I know it's the wrong call --
there's one that lets you check for a var existance */
b_SetOTF = VLC__TRUE else b_setOTF = VLC_FALSE;
Then the case statements immediately below get adjusted, for example:
case CONFIG_ITEM_INTEGER:
config_PutInt( p_this, psz_name, strtol(optarg, 0, 0));
break;
Becomes:
case CONFIG_ITEM_INTEGER:
if (!b_SetOTF) config_PutInt( p_this, psz_name,
strtol(optarg, 0, 0)) /* not on-the-fly -- a true startup parameter */
else var_Set( p_input, strtol(optarg, 0, 0)); /* an
on-the-fly variable */
break;
If I launch VLC with logo, for example, the "--logo-x=100" should be
processed equally well for either the initial command-line startup or for an
OTF change.
The above would allow for a socket based interface to at least handle a
multi-parameter option string ("--logo-x=100 --logo-y=50"), as long as the
input string on the socket uses the same format as allowed on the current
command-line. It would allow for general user interfaces to get rid of the
"gludge" work of having to independently check for OTF parameters -- just
ship the string to the new parser function to handle that. It would provide
commonality of the command syntax between console startup and telnet-type
socket commands.
This absolutely doesn't require that all options be on the fly -- if a
particular module hasn't created a control variable, with callback, then
b_SetOTF will be FALSE, no harm done.
The above doesn't mean that a user interface cannot have unique
options/capabilities/commands, above and beyond the basic shortcuts/options.
You just pass the input string to the parser first, to handle the "gludge"
settings, then can independently process the string if there are any
special/unique commands that you need to look at.
A recognize that, for example, perhaps INPUT might not be the right object
to attach the variables against, but there should be some top-level
structure where shortcuts could be placed, and only placed if they are live
"OTF" variables. I only use INPUT because that's where the marq and logo
OTFs are, at present.
Thoughts/comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20041110/7ac4ad5a/attachment.html>
More information about the vlc-devel
mailing list