Wiki Page Content

Style Guide: Enumerations Pages

This guide provides specific instructions for editing or adding your own content to each section of an Enumeration page in this wiki.

Enumeration pages should provide basic information about the SDL enumerations to allow users to most effectively utilize them in their projects.

General Guidelines

red
The basic enumeration template is also used for hints that have pages in the wiki. For simplicity, the following guidelines for enumerations will also apply to hints unless a specific difference is noted.

Please observe the following for all enumeration 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.

Return to Table of Contents

Getting Started

  1. Begin by going to the page you wish to edit and selecting blue or blue in the left column to begin editing.

    • {i} Markup info provided here is specifically for use in the Text editor but should work in both.

  2. Scroll down in the edit window to the section(s) you want to edit. Add your content following the conventions in this style guide.
  3. Find information relevant to your content in the style guide sections below and apply the appropriate formatting as you edit.

  4. Preview your work as you go by clicking blue in the left column. Preview often and any time you are unsure of formatting.

    • (Keep in mind that a few things (like Color2 text) don't preview exactly as they parse.)

  5. Save your work by clicking blue in the left column after you are satisfied with your content and have filled in the Comment field under the editing box.

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>.

Return to Table of Contents

Editing Specific Sections

Title

Do not edit the Title.

The Title section consists of the page heading and its markup:

  • = SDL_EnumerationName =

For enumeration pages this is the name of the enumeration being described on the page and should match the address of the page.

Example: The page address http://wiki.libsdl.org/moin.cgi/SDL_EventType should have matching title SDL_EventType and describe the SDL_EventType 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>.

Return to Table of Contents

Description

The Description section immediately follows the page title and does not have it's own heading.

Enumeration descriptions begin with:

  • An enumeration of

    • or very rarely

    A hint that specifies

  • followed by a clear and concise description of what the enumeration (or hint) is.

Note: Information presented in this section is meant to be limited. Extended description information for more complicated enumerations 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 hint rather than an enumeration

Action: Use the alternate description (A hint that specifies...) and, if necessary, replace the word enumeration with the word hint where appropriate throughout the page.

Example: SDL_EventType, SDL_HINT_RENDER_SCALE_QUALITY

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]], SDL_BlendMode

If a value on that page is referenced in the description

Action: There is no special formatting for enumeration values since most are already in all caps and distinct enough. (This is different from function parameters or structure data values.)

Return to Table of Contents

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>.

Return to Table of Contents

Values

The Values section provides basic information about each value in the enumeration and is presented in table format.

The basic format is as follows:

||value1||description||
||value2||description||
...
||valueN||description||

Markup: Use basic table markup. All text in the table is left-justified. Do not use bold.

  • The first column contains the value name, usually in all caps (format as in the API).

  • The second column contains a simple description of each value 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_BlendMode, SDL_HintPriority, SDL_PowerState, SDL_WindowFlags

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 the value is for internal use, deprecated, or unused (greyed out)

Action 1: Place a text notation in parentheses at the end of the description (ie: (deprecated))

Action 2: 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:
<rowstyle="color: #808080;">

Note: Although a rare case, any other style markup for that row/cell should be included within the same set of angle brackets (<>) and separated from this markup by a space.

Markup: ||<rowstyle="color: #808080;">value||description||

Example: SDL_EventType, SDL_LOG_CATEGORY

If the value is specified as read-only

Action: Place the text notation (read-only) in parentheses at the end of the description.
Do not grey out the line.
If all values are read-only notate it in the Remarks instead.

Note: This also applies to the rare case that "(read-write)" is specified.

Example: There are currently no enumeration examples of this. SDL_Surface, SDL_PixelFormat

If another API page is referenced and the value is greyed out (see above)

Action 1: DO NOT hyperlink the page in the table.

Action 2: List the page, with a hyperlink, in the description and/or in the appropriate "Related" section at the bottom of the page, if appropriate.

Example: There are currently no enumeration examples of this. SDL_Event

If another API page is referenced and the value is not greyed out (see above)

Action1: Be sure to hyperlink it and use () outside the link markup if it is a function.

Action 2: List the page in the appropriate "Related" section at the bottom of the page, if appropriate.

Example: There are currently no enumeration examples of this. SDL_Event, SDL_BlendMode

If there are important, distinct groups of values within the enumeration

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: 1 empty cell for a 2 column table). Place the following markup in the last cell
<bgcolor="#EDEDED">''Section Title''
Replace Section Title with appropriate text and close the last column.

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_AudioFormat, SDL_EventType

Specific (description column)

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 value" below for more details.

Example: SDL_HintPriority, SDL_GLattr

If a more detailed description is required to adequately explain a value

Action 1 : Append the following, verbatim, to the end of the brief description
; see [[#Remarks|Remarks]] for details

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_PixelFormatEnum, SDL_GLattr

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 value" above) to the following:
; see [[#anchorname|Remarks]] for details
where anchorname matches the name you chose for the anchor in Action 1.

Example: SDL_GLattr, SDL_PixelFormatEnum

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 novel information.

Note: If none of the values has relevant description text it is acceptable to remove the entire description column, but this should be done with caution and only extremely rarely.

Example: SDL_PixelFormatEnum, SDL_AudioStatus, SDL_HINT_RENDER_DRIVER

Return to Table of Contents

Code Examples

The Code Examples section is meant to contain simple, meaningful examples of how to use the enumeration in a program.

  • Unlike other sections, which should rarely require editing once DRAFT is removed, this section is expected to change over time.

This is one of the few sections that is intended to grow and adjust as users discover more information about an enumeration that would be helpful to share with other users.

For the most part the contents of the Code Examples section will be user-generated and this section will remain as-is until users input their examples.

Please see the Code Examples Style Guide for details on editing this section.

Return to Table of Contents

Remarks

The Remarks section is meant to contain additional information that did not fit in the other sections as well as comments regarding the behavior and use of the enumeration in real-world applications.

  • Unlike other sections, which should rarely require editing once DRAFT is removed, this section is expected to change over time.

This is one of the few sections that is intended to grow and adjust as users discover more information about how an enumeration behaves under different circumstances.

For the most part the contents of the Remarks section will be user-generated and this section will remain as-is until users input their comments.

Note: This is not an appropriate place to post questions, suggestions, bugs, or commentary. Please use the other communication channels available to you, especially the forums and mailing lists, for these types of remarks.

Please see the Remarks Style Guide for details on editing this section.

Return to Table of Contents

The Related Enumerations section provides a list of enumerations specifically referenced by the enumeration or otherwise closely related to it. This section is very rarely used.

This list should include:

  • other enumerations that are specifically referenced in the enumeration (may never occur)
  • other enumerations that are indirectly referenced by or very closely related to the enumeration

    • (ie: the enum is not used as a value but its values are used to fill in a value or they are different aspects of the same idea)

    • This is very uncommon.

This list should not include:

  • the primary enumeration on that page
  • every enumeration that might be considered "related" to the enumeration or any other listed enumerations
    • Including too many would make these lists much less valuable.

  • all enumerations of similar type
  • all enumerations of a related category
  • enumerations that are indirectly related
    • (ie: it might be common to use them together)

  • enumerations that do not have a page in the wiki
  • non-enumerations
    • (ie: do not include functions or structures in this list)

Markup: Each line should begin with a single blank space and a period followed by the enumeration name enclosed in double brackets to create a hyperlink.

  • Note: Do not include empty parentheses after the name.

  • The basic format for the Related Enumerations list is:

== Related Enumerations ==
 .[[SDL_EnumerationName]]
 .[[SDL_EnumerationName]]
  • Note: The heading was included to more clearly illustrate the blank space before the period at the beginning of each list line. Without this markup the format will not parse correctly.

If there is more than one enumeration in the list

Action: List the enumerations in alphabetical order.

If there are no related enumerations

Action: This section may be removed entirely (including the heading) and added back at a later time if it becomes relevant.

Note: It is common for this section to be empty and removed from the page.

Example: SDL_Keycode, SDL_Scancode

Return to Table of Contents

The Related Structures section provides a list of structures (or unions) specifically referenced by the enumeration or otherwise closely related to it.

This list should include:

  • structures that specifically reference the enumeration
  • structures that indirectly reference but are closely related to the enumeration
    • This is uncommon.

This list should not include:

  • every other structure that might be considered "related"
    • Including too many would make these lists much less valuable.

  • all structures of similar type
  • all structures of a related category
  • structures that are indirectly related
    • (ie: it might be common to use them together)

  • structures that do not have a page in the wiki
  • non-structures
    • (ie: do not include functions or enumerations in this list)

Markup: Each line should begin with a single blank space and a period followed by the structure name enclosed in double brackets to create a hyperlink.

  • Note: Do not include empty parentheses after the name.

  • The basic format for the Related Structures list is:

== Related Structures ==
 .[[SDL_StructureName]]
 .[[SDL_StructureName]]
  • Note: The heading was included to more clearly illustrate the blank space before the period at the beginning of each list line. Without this markup the format will not parse correctly.

If there is more than one structure in the list

Action: List the structures in alphabetical order.

If the structure is a member of the SDL_Event union

Action: Include SDL_Event in this section of the page.

If there are no related structures

Action: This section may be removed entirely (including the heading) and added back at a later time if it becomes relevant.

Note: It is common for this section to be empty and removed from the page.

Example: SDL_AudioFormat, SDL_BlendMode, SDL_PixelFormatEnum

Return to Table of Contents

The Related Functions section provides a list of functions specifically associated with that enumeration or otherwise closely related to it.

  • In general, a "Related Function" is one that uses the given enumeration.

This list should include:

  • functions that use or are otherwise very closely related to the enumeration

This list should not include:

  • every other function that might be considered "related"
    • Including too many would make these lists much less valuable.

  • all functions of similar type or action
  • all functions of a related category
  • functions that are indirectly related (ie: a similar function that does not use the structure)
  • functions that do not have a page in the wiki
  • non-functions (ie: do not include structures or enumerations in this list)

Markup: Each line should begin with a single blank space and a period followed by the function name enclosed in double brackets to create a hyperlink.

  • Note: Do not include empty parentheses after the function names in this section. They are all functions so it should be understood/unnecessary.

  • The basic format for the Related Functions list is:

== Related Functions ==
 .[[SDL_FunctionName]]
 .[[SDL_FunctionName]]
  • Note: The heading was included to more clearly illustrate the blank space before the period at the beginning of each list line. Without this markup the format will not parse correctly.

If there is more than one function in the list

Action: List the functions in alphabetical order.

If there are no related functions

Action: This section may be removed entirely (including the heading) and added back at a later time if it becomes relevant.

Example: SDL_AudioStatus, SDL_HintPriority, SDL_TextureAccess

Return to Table of Contents

red
See Hint Pages below for details on how this section is different for Hint pages.

The Footer section consists of a horizontal rule followed by two links separated by a comma.

Markup:

----
[[CategoryEnum]], [[CategoryHeader]]
  • where CategoryEnum is the same for every enumeration page and CategoryHeader is enumeration-specific with Header varying based on the header file containing the enumeration (see below).

red Category names do not always match the header file name. Please consult the following table for the correct name to use so the enumeration will appear in the correct list(s).

Action 1: Do not edit the CategoryEnum link!

Action 2: The CategoryHeader link may be edited if the page still says [[CategoryHeader]] (as on a new page) or if the structure has been relocated to another header (very rare).

red There are a few exceptions to this rule (pages with a category name that does not match their header file according to the table). These have been determined by the SDL team. Please do not change an existing page's category name simply because it does not match its header file. If you are concerned that a name is incorrect please submit your concern in the forums or mailing lists or contact us at <ANTI SPAM wiki AT libsdl DOT org> to confirm the change first.

Markup: Replace CategoryHeader with the appropriate category name from the table that follows, or contact us at <ANTI SPAM wiki AT libsdl DOT org> to find out what category name to use if you are unsure or if the category appears to be missing.

Header File Containing the Structure*

Corresponding Category Name

SDL.h

CategoryInit

SDL_assert.h

CategoryAssertions

SDL_atomic.h

CategoryAtomic

SDL_audio.h

CategoryAudio

SDL_clipboard.h

CategoryClipboard

SDL_compat.h

CategoryCompat

SDL_cpuinfo.h

CategoryCPU

SDL_endian.h

CategoryEndian

SDL_error.h

CategoryError

SDL_events.h

CategoryEvents

SDL_haptic.h

CategoryForceFeedback

SDL_hints.h

CategoryHints

SDL_joystick.h

CategoryJoystick

SDL_keyboard.h

CategoryKeyboard

SDL_keycode.h

CategoryKeyboard

SDL_loadso.h

CategorySharedObject

SDL_log.h

CategoryLog

SDL_mouse.h

CategoryMouse

SDL_mutex.h

CategoryMutex

SDL_pixels.h

CategoryPixels

SDL_platform.h

CategoryPlatform

SDL_power.h

CategoryPower

SDL_quit.h

CategoryEvents

SDL_rect.h

CategoryRect

SDL_render.h

CategoryRender

SDL_rwops.h

CategoryIO

SDL_scancode.h

CategoryKeyboard

SDL_surface.h

CategorySurface

SDL_syswm.h

CategorySWM

SDL_thread.h

CategoryThread

SDL_timer.h

CategoryTimer

SDL_version.h

CategoryVersion

SDL_video.h

CategoryVideo

*Some exceptions exist. See above.

Return to Table of Contents

Special

This section contains details for special formatting circumstances that are best described separately from the average enumeration page. In general these guidelines should be used in conjunction with the above.

Hint Pages

In some cases Hints are formatted slightly differently than enumerations. Use the following formatting specifics in addition to those listed above for all CategoryHints pages::

Action 1: All Hint pages contain an additional section not present on enumeration pages - Default

Markup: Add the following section to all CategoryHints pages between the Values and Code Examples sections.

  • == Default ==
  • Action: Immediately under this section include at least one sentence beginning with the following, and describing the default state, if any, for that hint:

    • By default...

Example: SDL_HINT_FRAMEBUFFER_ACCELERATION, SDL_HINT_RENDER_SCALE_QUALITY

Action 2: The Footer section of a Hint page follows the same guidelines as for an enumeration page with the following differences:

  • Use [[CategoryDefine]], [[CategoryHints]] as the link pair at the bottom instead.

  • The table above is irrelevant to this section since they are all the same.

Note: To date there are no Related Enumerations, Related Structures, or Related Functions listed on any Hint page. Should there be, follow the same general guidelines as for enumerations.

Return to Table of Contents


Resources

Our goal is to create accurate, consistent, helpful, user-friendly documentation. We appreciate your efforts to make your additions fit into the existing framework and retain the same look and feel as much as possible.

If you have questions that aren't addressed here:

  1. Search for another page that contains something similar to what you want to do and copy all the basics as much as applicable.
  2. Check the other SDL Style Guides.

  3. Post a question to Feedback and include a way to contact you.

  4. Post a question to the Mailing List.

  5. Send a comment or question to <ANTI SPAM wiki AT libsdl DOT org> for clarification.

If you have suggestions for changes or additions to this document or any other portion of the wiki please don't hesitate to contact us with your thoughts. We are happy to have the participation!


Disclaimer

All content modifications are subject to review for consistency and quality. We reserve the right to remove or modify any content added to this wiki at any time. You may direct questions or concerns to <ANTI SPAM wiki AT libsdl DOT org>.

None: SGEnumerations (last edited 2012-01-06 00:09:48 by SheenaSmith)

Feedback
Please include your contact information if you'd like to receive a reply.
Submit