|
Size: 11552
Comment: add content (very incomplete)
|
Size: 11945
Comment: add content (very incomplete)
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 136: | Line 136: |
| ||||<bgcolor="#EDEDED">''First Column (type)''|| ||<( |2 30%>''If'' there is __a pointer__ associated with the field||''Action'': Place the pointer symbol(s) at the end of the type with no space between.|| |
||<( |3 30%>''If'' there is __a pointer__ associated with the field||''Action 1'': Place the pointer symbol(s) at the end of the type in the ''first column'' with no space between.|| ||''Action 2'': In general, avoid mentioning the pointer in the description unless it is necessary to understand the field.|| |
| Line 139: | Line 139: |
| ||||<bgcolor="#EDEDED">''Second Column (field)''|| ||||<(>There are currently no special formatting instructions just for this column. See [[#general|''General'']] above.|| |
||||<bgcolor="#EDEDED">''First Column (type) & Second Column (field)''|| ||||<(>There are currently no special formatting instructions just for these columns. See [[#general|''General'']] above.|| |
| Line 157: | Line 157: |
||<( |2 30%>''If''||''Action'':|| ||''Example'':|| |
||<( |2 30%>''If'' there is __no relevant description text__||''Action'': It is acceptable to leave the description cell blank, although it is preferable to put some information there even if it is redundant with the field name or otherwise does not really provide any new information.|| ||''Example'': [[SDL_Color]]|| |
DRAFT |
Style Guide: Structure Pages
This guide provides specific instructions for editing or adding your own content to each section of a Structure page in this wiki.
Structure pages should provide basic information about the SDL structures to allow users to most effectively utilize them in their projects.
Contents
General Guidelines
red |
Please observe the following for all structure pages:
- Do not post anything that you do not have permission to post publicly.
- Sections should have adequate details to make them clear and useful while remaining brief wherever possible. Code Examples and Remarks may be more extensive than other sections if necessary.
- Please remember to keep it accurate, simple, and easy to understand.
Do not remove, modify, or add to the markup above the page title (processing instructions (ie: #pragma, #acl), red
markup, etc.) except:
On CategoryCompat pages, place the following markup above the page title and below the processing instructions or draft markup, if present:
||<tablewidth="100%" #000000 style="color: #FF8C00;" :> <<BR>>~+For Backward Compatibility Only+~<<BR>><<BR>> ||
- Do not remove, modify, or add section headings unless specifically mentioned below.
- In general, we prefer that you do not remove or modify existing content unless it is clearly incorrect or out of date.
Pages with red at the top are in progress and will often contain unusual content, formatting, or notes. Please do not remove or modify these. That will all be corrected/removed upon final edit.
For assistance with editing, saving, or wiki-appropriate markup see the Wiki Basics Style Guide or contact us at <ANTI SPAM wiki AT libsdl DOT org>.
Editing Specific Sections
Title
Do not edit the Title.
The Title section consists of the page heading and its markup:
= SDL_StructureName =
For structure pages this is the name of the structure being described on the page and should match the address of the page.
Example: The page address http://wiki.libsdl.org/moin.cgi/SDL_PixelFormat should have matching title SDL_PixelFormat and describe the SDL_PixelFormat structure.
If you believe a change is necessary please submit Feedback from that page or contact us at <ANTI SPAM wiki AT libsdl DOT org>.
Description
The Description section immediately follows the page title and does not have it's own heading.
Structure descriptions begin with: A structure that contains
- or very rarely
A union that contains
followed by a clear and concise description of what the structure contains.
Note: Information presented in this section is meant to be limited. Extended description information for more complicated structures should be placed in the Remarks section instead.
- The Description should not contain a link to the Remarks section even if additional information is located there.
Note: Exceptions to the basic description are very unusual. Follow established patterns in the wiki (based on similar pages which may be found by text search) whenever possible if an exception seems appropriate.
If the page describes a union rather than a structure |
Action: Use the alternate description (A union that contains...) and, if necessary, replace the word structure with the word union where appropriate throughout the page. |
Example: SDL_Event |
|
If another API page is referenced in the description |
Action: Be sure to hyperlink it and use () outside the link markup if it is a function. |
Example: [[SDL_FunctionName]](), [[SDL_StructureName]] |
|
If a parameter on that page is referenced in the description |
Action: Use bold for the parameter name. |
Note: This is a very rare occurrence. |
|
Note: If the reference is to the parameter as a concept (ie: the window to do something with) rather than directly to the parameter itself (ie: SDL_Function(window)) do not make it bold. |
Table of Contents
Do not edit the Table of Contents.
The Table of Contents consists of the following markup and is generated automatically on the parsed page.
<<TableOfContents()>>
If you believe a change is necessary please submit Feedback from that page or contact us at <ANTI SPAM wiki AT libsdl DOT org>.
Data Fields
The Data Fields section provides basic information about each field in the structure and is presented in table format.
The basic format is as follows:
||type1||'''field1'''||description|| ||type2*||'''field2'''||description|| ||[[type3]]||'''field3'''||description|| ... ||typeN||'''fieldN'''||description||
Markup: Use basic table markup and enclose each field name in bold markup. All text in the table is left-justified.
The first column contains the field type and any pointers if applicable.
The second column contains the field name, without types or pointers, in bold.
The third column contains a simple description of each field using some specific formatting conventions.
red All descriptions begin with a lower case letter, end without a period, and are generally not complete sentences.
Example: SDL_Surface, SDL_JoyButtonEvent, SDL_Palette, SDL_HapticCondition
Action: There are a few content-dependent conventions we have chosen for consistency across pages. See the tables below for details.
General (whole table) |
|
If another API page is referenced |
Action: Be sure to hyperlink it and use () outside the link markup if it is a function. |
Example: SDL_Event, SDL_AudioSpec, SDL_SysWMinfo |
|
If there are important, distinct groups of fields within the structure |
Action: Create sections by placing a full-width row with a grey background and centered, italics title above each group. |
Markup: Begin the row with empty table cells equal to the number of columns in the table -1 (ie: 2 empty cells for a 3 column table). Place the following markup in the next cell |
|
Note: This is a rare occurrence. Do not use sections unless they significantly improve the meaning, clarity, or usability of the information. |
|
Example: this table, SDL_HapticConstant, SDL_HapticRamp |
|
If the field is for internal use, deprecated, unused, or read-only |
Action: In addition to the notation (ie: deprecated), make the text in the row grey by including the following, verbatim, in the first cell of the row between the starting table markup and the text: |
Note: Although a rare case, any other style markup should be included within the same set of angle brackets (<>) and separated from this markup by a space. |
|
Example: ||<rowstyle="color: #808080;">||type||'''field'''||description||, SDL_Palette, SDL_Color |
|
If the structure includes padding fields |
Action: Omit all padding fields from the wiki page. |
Example: SDL_AudioSpec, SDL_WindowEvent |
|
If there is a pointer associated with the field |
Action 1: Place the pointer symbol(s) at the end of the type in the first column with no space between. |
Action 2: In general, avoid mentioning the pointer in the description unless it is necessary to understand the field. |
|
Example: ||type*||..., SDL_Surface, SDL_assert_data |
|
First Column (type) & Second Column (field) |
|
There are currently no special formatting instructions just for these columns. See ''General'' above. |
|
Third Column (description) |
|
If more than one statement must be included in the description |
Action: Separate them with a semi-colon (;) |
Note: This should be avoided whenever possible. See "If a more detailed description is required to adequately explain a parameter" below for more details. |
|
Example: SDL_JoyButtonEvent, SDL_Keysym |
|
If a more detailed description is required to adequately explain a field |
Action 1 : Append the following, verbatim, to the end of the brief description |
Action 2: Place the more detailed information in the Remarks section. |
|
Action 3: See "If the Remarks section is large" below for more details. |
|
Example: SDL_RendererInfo, SDL_HapticEffect |
|
If the Remarks section is large |
Action 1: Create an anchor immediately before the additional comments you are adding to the Remarks section. |
Markup: Use <<Anchor(anchorname)>>, where anchorname is a name of your choosing, to create the anchor in the Remarks section. See Anchors for details. |
|
Action 2: Modify the Remarks link in the parameter description (see Action 1 in "If a more detailed description is required to adequately explain a parameter" above) to the following: |
|
Example: SDL_RendererInfo |
|
If a field references another field on that same page |
Action: Use bold for the field name. |
Note: This is a very rare occurrence. |
|
Note: If the reference is to the field as a concept rather than directly to the field itself do not make it bold. |
|
Example: SDL_AudioCVT, SDL_HapticCustom |
|
If there is no relevant description text |
Action: It is acceptable to leave the description cell blank, although it is preferable to put some information there even if it is redundant with the field name or otherwise does not really provide any new information. |
Example: SDL_Color |
|
