CVS: g2/DOCS cfg.txt,1.2,1.3

CVS change done by Diego Biurrun CVS

Update of /cvsroot/mplayer/g2/DOCS
In directory mail:/var2/tmp/cvs-serv15966

Modified Files:
	cfg.txt 
Log Message:
spelling cosmetics


Index: cfg.txt
===================================================================
RCS file: /cvsroot/mplayer/g2/DOCS/cfg.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cfg.txt	1 Feb 2004 00:04:50 -0000	1.2
+++ cfg.txt	2 Feb 2004 23:36:21 -0000	1.3
@@ -12,7 +12,7 @@
   unsigned short type, version; // for loadable plugins
   void *entry; // pointer to module entry point (xxx_open() or xxx_functions_t*)
   char *name;
-  char *desc; // short description for commandline help and gui
+  char *desc; // short description for command line help and GUI
   char *maintainer;
   char *author;
   char *comment;
@@ -24,7 +24,7 @@
 
 Yes, it looks like the *_info_t of g1's plugins. No wonder, it is that.
 The difference is that in g2 not only actual plugins have such description,
-but core layers (like libdemux etc) and even the main application too.
+but core layers (like libdemux etc) and even the main application, too.
 Config handler and parser functions receive info in this module_info_t struct.
 
 So, look at this struct a bit closer:
@@ -33,13 +33,13 @@
   int  config_size;
 
 In g2, modules may have their own dynamically allocated config data structure.
-It means: no more globals! yeah. Of course globals can be used, too.
+It means: no more globals! Yeah. Of course globals can be used, too.
 The implementation of per-module dynamic config is the following:
 A module (be it core layer or a plugin) will define its own config_data_t
-structure, containing its configuration variables. It can (optinally)
+structure, containing its configuration variables. It can (optionally)
 define a set of default values, in the layout of config_data_t.
 Then it will define a config_t array, describing each option, with pointers
-into the config_data_t struct. It's a bit tricky: if you have config_defaults,
+into the config_data_t struct. It's a bit tricky: If you have config_defaults,
 your pointers should point into that. If you don't have defaults, your pointers
 will be struct offsets (NULL-based pointers).
 
@@ -73,24 +73,24 @@
 };
 
 What if I leave/ignore some of these fields?
-- if config_size>0 then config_data will be dynamically allocated,
+- If config_size>0 then config_data will be dynamically allocated,
   otherwise all options (in config_t array) are handled as globals,
   with absolute pointers.
-- if config_defaults!=NULL, then config_data will be cloned from it,
+- If config_defaults!=NULL, then config_data will be cloned from it,
   instead of allocating zero-filled memory.
-  option pointers targetting inside the config_defaults struct will be
+  Option pointers targetting inside the config_defaults struct will be
   handled as dynamic variables (relocated to cloned config_data), others
   will be handled as globals.
-- if config_defaults==NULL and config_size>0, then pointers will be handled
+- If config_defaults==NULL and config_size>0, then pointers will be handled
   as struct offsets relative to the start of config_data_s structure.
-  In this case you should use macros like ST_OFF() (from mplayer g1) or
+  In this case you should use macros like ST_OFF() (from MPlayer g1) or
   do it by hand:  &( ((struct config_data_s*)NULL)->field )
 
 Config layers:
 ~~~~~~~~~~~~~~
-The new config code is layered by functionality and dependancy:
+The new config code is layered by functionality and dependency:
 
-layer #0 is actually cfg.h and a small cfg-l0.c containing helper functions
+Layer #0 is actually cfg.h and a small cfg-l0.c containing helper functions
 to work with the cfg.h structs.
 It includes 2 functions:
 
@@ -103,17 +103,12 @@
 the module's defaults) or the user-supplied base (config_data_t* def).
 The later can be used for configtree/playtree implementation, when a given
 module inherits non-default config from a previous layer. 'def' may be NULL!
-Normally this function should be called only once (per url/file) by the app
+Normally this function should be called only once (per URL/file) by the app
 for only the top level module, assuming it has references (CONF_TYPE_MODULE
 or _MODLIST) to all other modules.
 
-layer #1 is the place for the string<->conf_type parsers/converters.
+Layer #1 is the place for the string<->conf_type parsers/converters.
 Currently it includes functions for string->conf_type conversion (parsing),
-an complete option parsing handler (including option serach and
+a complete option parsing handler (including option search and
 CONF_TYPE_MODULE recursion), and a subconfig-compatible syntax parser
 (already used for CONF_TYPE_MODLIST).
-
-
-
-
-