[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