[MPlayer-dev-eng] Is anyone considering docbook for the man page ?
Dirk
noisyb at gmx.net
Tue Mar 18 23:34:08 CET 2003
Alban Bedel wrote:
>Hi Dirk,
>
>on Tue, 18 Mar 2003 17:00:03 +0100 you wrote:
>
>
>
>>Alban Bedel wrote:
>>
>>
>>
>>>Hi Diego Biurrun,
>>>
>>>on Tue, 18 Mar 2003 01:34:42 +0100 you wrote:
>>>
>>>
>>>
>>>
>>>
>>>>The man page is in for an overhaul, no question,
>>>>maybe even the idea of putting mplayer and mencoder together needs to
>>>>be revisited. If you have any bright ideas, step forward. In the
>>>>meantime I think that redundancy is our worst enemy.
>>>>
>>>>
>>>>
>>>>
>>>I agree with you, fight the redundancy !!!!!
>>>I'd like to say that I would like to have (someday) a kind of
>>>integreted help as the man page is growing way to big now. By
>>>integrated help i mean the possiblity of having mplayer document it
>>>self. Something like'mplayer -describe fs' would ouput what the man
>>>page is saying about this option.
>>>
>>>
>>>
>>In our project we finally ended with using a simple struct...
>>
>>typedef struct
>>{
>> int val; // same val as getopt() returnes after parsing another arg
>>successfully
>> char *option_s; // the option as string... same string as used in
>>struct option
>> char *optarg; // optarg
>> char *desc; // the simple usage
>> char *more_desc; // MORE explanation
>>// (void)
>>} st_usage_t;
>>
>>then we made an array of this including EVERY option we have..
>>
>>st_usage_t usage[] =
>>{
>> {OPT_HELP, "help", NULL, "help output", "i said help output.."},
>> ...
>>
>>}
>>
>>
>
>Having the help in the source code is bad imho. 1) translation are harder,
>2) doc writers have to mess in the code. 3) ....
>I considered this solution too but abandoned it for the reasons i writed
>above (and i'm sure there is many others reasons that aren't comming to
>mind atm)
> Albeu
>
>
yeah.. that stuff above could be turned into XML without thinking, anyways..
More information about the MPlayer-dev-eng
mailing list