diff options
Diffstat (limited to 'doc/hackersguide/overview.sgml')
| -rw-r--r-- | doc/hackersguide/overview.sgml | 72 |
1 files changed, 49 insertions, 23 deletions
diff --git a/doc/hackersguide/overview.sgml b/doc/hackersguide/overview.sgml index d405ac18c..18cc40396 100644 --- a/doc/hackersguide/overview.sgml +++ b/doc/hackersguide/overview.sgml @@ -201,7 +201,7 @@ <term><filename>libmad</filename> (imported)</term> <listitem> <para> - Mpeg audio decoder plugin (i.e. mp2 and mp3 decoding). + Mpeg audio decoder plugin (i.e. mp2 and mp3 decoding). ISO/IEC compliant decoder using fixed point math. </para> <para></para> @@ -460,7 +460,7 @@ <para> Contains various video output driver plugins. Video output drivers are thin abstraction layers over various video output platforms - (e.g. X11, directfb, directX,...). Video output driver plugins + (e.g. X11, directfb, directX, …). Video output driver plugins provide functions like frame allocation and drawing and handle stuff like hardware acceleration, scaling and colorspace conversion if necessary. They do not handle a/v sync since this is done @@ -497,7 +497,7 @@ <term><filename>xine-engine</filename></term> <listitem> <para> - The heart of xine - it's engine. Contains code to + The heart of xine – its engine. Contains code to load and handle all the plugins, the configuration repository as well as the generic decoding loops and code for synchronized output. A lot of helper functions for plugins to use live here as well. @@ -529,7 +529,7 @@ <sect1> <title>Object oriented programming in C</title> <para> - xine uses a lot of design principles normally found in + xine uses a lot of design principles normally found in object oriented designs. As xine is written in C, a few basic principles shall be explained here on how xine is object oriented anyway. @@ -561,7 +561,7 @@ my_stack_t stack; /* public part */ /* private part follows here */ - int values[MAX_STACK_SIZE]; + int values[MAX_STACK_SIZE]; int stack_size; } intstack_t;</programlisting> Each method is implemented as a static method (static to prevent @@ -573,7 +573,7 @@ <programlisting> static void push (my_stack_t *this_gen, int i) { intstack_t *this = (intstack_t *)this_gen; - this->values[MAX_STACK_SIZE - ++this->stack_size] = i; + this->values[MAX_STACK_SIZE - ++this->stack_size] = i; }</programlisting> </para> <para> @@ -613,15 +613,15 @@ this = malloc(sizeof(intstack_t)); /* fill in methods */ - this->push = push; - this->add = add; - this->pop = pop; + this->push = push; + this->add = add; + this->pop = pop; /* init data fields */ - this->stack_size = 0; + this->stack_size = 0; /* return public part */ - return &this->stack; + return &this->stack; }</programlisting> </para> <sect2> @@ -646,7 +646,7 @@ </para> </sect2> </sect1> - + <sect1> <title>Coding style and guidelines</title> <para> @@ -655,44 +655,44 @@ Contributions will not be rejected if they do not meet these rules but they will be even more appreciated if they do. <itemizedlist> - <listitem> + <listitem> <para> Comment your interfaces directly in the header files. No doxygen comments, ordinary C comments will do. </para> </listitem> - <listitem> + <listitem> <para> Use C-style comments (/* */), not C++-style (//). </para> </listitem> - <listitem> + <listitem> <para> When in doubt, use lower case. BTW: This thing is called xine, never Xine. </para> </listitem> - <listitem> + <listitem> <para> Use expressive variable and function identifiers on all public interfaces. Use underscores to seperate words in identifiers, not uppercase letters (my_function_name is ok, myFunctionName is not ok). </para> </listitem> - <listitem> + <listitem> <para> Avoid macros unless they are really useful. Avoid gotos. </para> </listitem> - <listitem> + <listitem> <para> use something like - <programlisting> printf("module: ..."[,...]);</programlisting> + <programlisting> printf("module: ..."[,…]);</programlisting> for console output. All console output goes to stdout and must be prefixed by the module name which generates the output (see example above). </para> </listitem> - <listitem> + <listitem> <para> Refer to emac's C-mode for all questions of proper indentiation. That first of all means: indent with two spaces. @@ -701,7 +701,7 @@ </itemizedlist> </para> </sect1> - + <sect1> <title>The xine logging system</title> <para> @@ -714,7 +714,7 @@ <para> Output which is done thru this function will be displayed for the end user by the frontend. - If <varname>xine->verbosity</varname> is not 0 the messages will also + If <varname>xine->verbosity</varname> is not 0 the messages will also be displayed on the console. Ideally these strings are translated. This function is for information which the user should @@ -727,7 +727,7 @@ <sect2> <title>xprintf</title> <para> - This macro uses the <varname>xine->verbosity</varname> value to decide + This macro uses the <varname>xine->verbosity</varname> value to decide if the string should be printed to the console. Possible values are XINE_VERBOSITY_NONE, XINE_VERBOSITY_LOG or XINE_VERBOSITY_DEBUG. By default nothing is printed. @@ -806,6 +806,32 @@ working on other parts of the code or are simply busy at the moment). </para> + <para> + We prefer to receive patches in a format which is immediately + committable. This normally means that we want your name and email address + (we're not keen on pseudonyms), a subject line which provides a + convenient summary of your changes, and body text which provides a longer + description (if needed). Patches must be generated using <command>hg + diff</command> or <command>cvs -z9 diff</command>, depending on which is + used for the repository, and always from within the top level of the + checked-out source. + </para> + <para> + If your patch is intended for a Mercurial-format repository, then + committing it locally and using + <command>hg export <parameter>.</parameter> ><filename>foo.patch</filename></command> + to create the file to be attached is acceptable (but note that the first + line – up to the first line feed – of the commit message is regarded as + the patch summary; if you're not sure, check with + <command>hg log -r<parameter>.</parameter></command>. + Alternatively, use <token>From:</token> and <token>Subject:</token> lines + in the patch file itself; this is useful when forwarding. + </para> + <para> + Patches should normally be included as attachments. Some mail clients and + webmail services are known to mangle whitespace or wrap lines, either of + which is enough to render a patch potentially useless. + </para> </sect1> </chapter> |