diff --git a/src/documentation/haiku_book/Jamfile b/src/documentation/haiku_book/Jamfile index 34160e7b4d..80ec18ed1a 100644 --- a/src/documentation/haiku_book/Jamfile +++ b/src/documentation/haiku_book/Jamfile @@ -11,6 +11,15 @@ Doc2HTML : -stringparam use.id.as.filename 1 -stringparam language cpp -stringparam chunk.section.depth 2 ; +Doc2HTML + howto.xml + : Haiku_Book_Howto.html + : [ FDirName $(HAIKU_TOP) src documentation docbook-xsl html chunk.xsl ] + : Haiku_Book_Howto + : + : -stringparam language cpp + ; + # Single most ugly string manipulation ever ... rule FRelGristFiles { diff --git a/src/documentation/haiku_book/howto.xml b/src/documentation/haiku_book/howto.xml new file mode 100644 index 0000000000..3a814560d6 --- /dev/null +++ b/src/documentation/haiku_book/howto.xml @@ -0,0 +1,727 @@ + + + +]> + + + + Developer Documentation Writing Howto + 2005-10-26 + + + Niels + Reedijk + + + + + + This guide is for Haiku Developers that need to write developer documentation. + + + + + + 1 + 2005-10-26 + nielx + First section about documenting classes on review. + + + + + + Introduction + + + The Haiku project maintains application programming interface (from now on + API) documentation for developers that want to write and port + applications on the platform. The project strives to create and maintain a uniform and + clear book that describes the API, named the Haiku Book. + + + + The tool to help structure and format the Haiku Book is Docbook. Docbook is originally + a SGML-based text that was developed for separating structure + and formatting in the age of digital publication. Docbook is basically a document type + definition (from now on DTD) that provides a standard that can be + used to generate a whole slew of output formats. The Haiku project chose this format + so that the documentation can be transformed into several output formats without any + effort. Furthermore, the format is is widely used and understood, and is structured by + the well-known XML standard. + + + + This document is written to prescribe a set of conventions so that the Haiku Book will + become a coherent whole. It also serves as a manual for those that are unfamiliar with + docbook, who will probably at times feel 'lost'. However, beginners using this manual + when documenting their classes, you will be able to generate proper docbook and create + a structure that fits in with the rest. Since the DTD contains over + three hundred elements, this document also selects which elements are used in our + documentation. Thus, this manual is also helpful to those more familiar with docbook. + + + + At the moment there is only one section finished. + + + + + Documenting Classes + + + This chapter will outline all the formal docbook structure for documenting classes, + as well as give hints on the content of the documentation. + + + + If you are documenting a class that hasn't been documented before, please read + the section on documenting a new class. If you are + working on an existing class, you can proceed to the + formal formatting. + + + + Documenting a new class + + + This section describes the rules on where to place the documentation of a new + class. It discusses + the place in the file hierchy, and how to hook it into the existing documentation. + Please read through this desciption carefully if you are adding a new class. For + those that are merely modifying classes that already exist, you can skip this + section. + + + + Where do I place my file? + + + When writing the documentation for a new class, you will create a new file. + This file needs to be placed in the hierchy in the subversion repository, that + is located at src/documentation/haiku_book/. This + directory contains a set of subdirectories that correspond with the class + division the Haiku project uses. You place your file in the subdirectory that + corresponds to the kit the class belongs to. + + + + + How do I name my file? + + + The naming of the file, consistent with header and source naming, consists + of the class name without the B + prefix and with the xml extension. For example, the + BList class would have the List.xml + documentation file. + + + + + What should be the initial contents of the file? + + + The minimal required content for the file is a line that is required by the + XML standard. Furthermore, you'll have to "open" a new + section (and close it), and you'll have to add a title. For example, the + BList class has the following bare minimum: + + + +<?xml version="1.0" encoding="UTF-8"?> + +<sect2 id="blist"> + <title>BList</title> +</sect2> + + + + Please note the following. The sect2 element, like other + sect elements, has the element id. This + id contains the classname in lowercase, including the B-prefix. + For notes on the XML formatting style, please see elsewhere in this document. + + + + + How do I hook in the file into the generated documentation? + + + If you have created the file and put it in the subdirectory that's appropriate + for the kit it belongs to, it's time to hook it into the generated documents. + The way to do this is by opening the api.xml file that's + located in that same subdirectory. Hooking in is a two-step process. First, you + create an entity in the doctype declaration that refers to the content of the + file that describes the class, secondly you refer to that entity in the body of + the document. + + + + The first step involves adding a line at the top of the file in the doctype + declaration. In clase of BList, the following has been + done. + + + +<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ + +<!ENTITY list SYSTEM "List.xml"> + +]> + + + + The line with the ENTITY in it, is the one that you need to + recreate for your own file. There are things you need to adapt. First of all, + you need to adapt list to reflect the name of the file in + lowercase, since entities are lowercase by convention. Secondly, you need + to change the filename it refers too. Please make sure you've got the case + right! + + + + Please note that the inclusions are by convention in alphabetical order. So + make sure the new line is at the proper spot. + + + + The second step is calling the entity in the body. For example in the support + kit: + + + +<sect1 id="supportapi"> + <title>Support Kit API</title> + + &list; +</sect1> + + + + The main body of the api.xml file consists of a list of + entities. You place your entity in the list (on a new line). Please remember + that entities are refered to by prefixing the name with + & and postfixing + ;. Please note that this also should be in + alphabetical order by convention. + + + + + + Formal formatting of a class + + + Thersomee are formal requirements for class documentation to be consistent with + the rest of the API documentation. This section will explain in + what order things should be documented, what the formal structural markup + for methods is and what sections are required. + + + + What elements should be in class documentation? + + + This sections describes the order in which things should be described. It + will touch a little bit of the docbook elements used in the larger structure. It + will not describe how you should structure the individual methods. That's for + the next section. + + + + We can distinguish roughly three parts. First of all, we've got the class + summary. This includes a formal block with useful information. Secondly, + we document the constructors and destructors. Then we describe + the member functions. Finally we describe the operators that are overloaded. + Note that any section can be left out if it's not available. For example, the + BList class doesn't have actual overloaded operators, + thus that section is not in the actual documentation. The following example + gives a rough outline of the BList documentation. + + + +<sect2 id="blist"> +<title>BList</title> + +<itemizedlist> + <listitem><para><emphasis>Derived from:</emphasis> none</para></listitem> + <listitem><para><emphasis>Declared in:</emphasis> <filename>os/support/List.h</filename></para></listitem> + <listitem><para><emphasis>Library:</emphasis> <filename>libbe.so</filename></para></listitem> +</itemizedlist> + +... summary comes here ... + +<bridgehead renderas="sect2">Constructors and Destructors</bridgehead> + +... constructors come here ... + +<bridgehead renderas="sect2">Member Functions</bridgehead> + +... member functions come here ... + +<bridgehead renderas="sect2">Operators</bridgehead> + +... operators would come here ... + + + + Class Summary + + + The first part of the class description is the summary. In the example + above it runs from <title>BList</title> to + the first <bridgehead>. There is an obligatory + <itemizedlist>. This list contains three elements: + the class it is derived from, the location it is declared in and the + library you need to link to. + + + + Note that every item in the <itemizedlist> begins + with <listitem>, which also happens to be the + final tags. The item is started with the tag <para>. + The labels to every piece of data is put inside an + <emphasis> block, including the semicolon! There's + a space between the endtag and the actual value. + + + + + The value of the first item, Derived from:, is either a + classname, or none. If it is a class, make sure you link + to it using the entity available. For example, if your class is derived + from BList, use &BList;. + This generates a nice crosslink within the documentation. + + + + The value of the second item, Declared in:, is wrapped + inside a <filename> tag. You refer to the path + relative to the header subdirectory in the Haiku + source tree. + + + + The value of the third item, Library:, is also wrapped + inside a <filename> tag. Stating the name of the + library suffices. The example can be found in libbe.so. + + + + + After that obligatory block, you can write a summary. This section won't + go into details of what good summaries contain (and what they don't). + Please remember to wrap every paragraph into a set of + <para> tags. Also note that if you link to methods + inside your class, that you use the appopriate entities. So if I want to + link to AddItem of my class, I use + &BList_AddItem;. + + + + + Constructor and Destructor + + + The second part focusses on constructors and the + destructor, and the third on the actual members. The second section starts + after the first <bridgehead> with the label + Constructors and Destructors. See for example the + BList constructors and destructors: + + + +<bridgehead renderas="sect2">Constructors and Destructors</bridgehead> + +<sect3 id="blist_constructor"> + <title>BList()</title> + + <constructorsynopsis> + <methodname>BList</methodname> + <methodparam><type>int32</type><parameter>count</parameter><initializer>20</initializer></methodparam> + </constructorsynopsis> + + <constructorsynopsis> + <methodname>BList</methodname> + <methodparam><modifier>const</modifier><type>BList &amp;</type><parameter>list</parameter></methodparam> + </constructorsynopsis> + + ... Description of the constructors here ... +</sect3> + +<sect3 id="blist_destructor"> + <title>~BList()</title> + + <destructorsynopsis> + <methodname>~BList</methodname> + </destructorsynopsis> + + ... Description of the destructor here ... +</sect3> + + + + First of all, the <bridgehead> element is an + element that instructs the stylesheet that transforms the docbook to an + output format to place a header in the same style as the header of the + section (hence the renderas="sect2" attribute). Because + of hierchial reasons, we don't actually want to start a new section. A + similar <bridgehead> is used as the second header + for the member functions. + + + + As you might notice, the BList has two constructors + and one destructor. The constructors are bundled together in the + <sect3> element with the id + blist_constructor. Like every other id, this one is + lowercase. The label must be the full classname in lowercase, an + underscore and the word constructor. The destructor + section is built up in a similar way. The title is the name of the method, + without any of it's arguments. So in case of the constructor, it is + BList(). + + + + As you can see, there is a normal constructor and a copy constructor. The + rule is that the copy constructor should always be places last. If you have + overloaded constructors, the order is somewhat at will, but please take as + guiding principle that it's most logical to order the constructors in order of + the amount of parameters (so from most complex to simpler). Feel free to + drop this order if your argument in the description or the synopsis requires + another order of constructors. + + + + The actual descriptions of the constructors are embedded in a + <constructorsynopsis> element. The destructor + is embedded in a <destructorsynopsis> element. + These are special variations of the <methodsynopsis> + construction, for they don't require a return type. They do follow the rest of + the rules of the <methodsynopsis> construction. + + + + For a more detailed description about the + <methodsynopsis> construction, see + . Some guiding lines on writing descriptions + will occur in a later section, but please note that you should wrap them in + <para> tags. + + + + Member documentation + + + The member documentation starts under the second + <bridgehead> with the label + Member Functions. This <bridgehead> + has the same properties as the one the one used with the constructors. + + + + In order to illustrate some of the principles, here's a piece of the + documentation for the BList class: + + + +<bridgehead renderas="sect2">Member Functions</bridgehead> +<sect3 id="blist_additem"> + <title>AddItem()</title> + + <methodsynopsis> + <type>bool</type><methodname>AddItem</methodname> + <methodparam><type>void *</type><parameter>item</parameter></methodparam> + <methodparam><type>int32</type><parameter>index</parameter></methodparam> + </methodsynopsis> + + <methodsynopsis> + <type>bool</type><methodname>AddItem</methodname> + <methodparam><type>void *</type><parameter>item</parameter></methodparam> + </methodsynopsis> + + ... Here comes documentation for this (or these) method(s)... +</sect3> + +<sect3 id="blist_countitems"> + <title>CountItems()</title> + + <methodsynopsis> + <type>int32</type><methodname>CountItems</methodname><modifier>const</modifier> + </methodsynopsis> + + ... Here comes documentation for this (or these) method(s)... +</sect3> + +<sect3 id="blist_removeitem"> + <title>RemoveItem()</title> + + <methodsynopsis> + <type>bool</type><methodname>RemoveItem</methodname> + <methodparam><type>void *</type><parameter>item</parameter></methodparam> + </methodsynopsis> + + <methodsynopsis> + <type>void *</type><methodname>RemoveItem</methodname> + <methodparam><type>int32</type><parameter>index</parameter></methodparam> + </methodsynopsis> + + <methodsynopsis> + <type>bool</type><methodname>RemoveItems</methodname> + <methodparam><type>int32</type><parameter>index</parameter></methodparam> + <methodparam><type>int32</type><parameter>count</parameter></methodparam> + </methodsynopsis> + + ... Here comes documentation for this (or these) method(s)... +</sect3> + +<sect3 id="blist_removeitems"> + <title>RemoveItems()</title> + + <para>See &BList_RemoveItem;</para> +</sect3> + + + + The first thing that's important is that every distinct method has it's own + <sect3>. The id attribute is build up of the + lowercase full classname, an underscore and the name of the method, also in + lowercase. There are no braces present. The title of the section is the + name of the method with proper casing, followed by closed braces (without a + space before or between them). Note that all the sections are ordered + alphabetically. + + + + Let's take the CountItems() method as an example. + We notice that the prototype of the function is encapsulated in a + <methodsynopsis> construction. This construction + is discussed in more detail in . If a + method is overloaded, like the AddItem() + method, both the prototypes are given. + + + + Important is the fact that multiple methods can be grouped together. For + instance, the documentation for the RemoveItems() + method is included in the documentation of the singular + RemoveItem(). Thus that prototype is listed in + that location. Please note that it still is obligatory to create a separate + section for RemoveItems(), as you can see in the + example. You don't have to put anything in that section, besides the title + and one <para> with the contents See + and the entity that refers to the method where it is documented. + + + + If you group different methods together, the rule is that they should be in + alphabetical order. If you have overloaded method, take the guideline that + they should be reverse ordered in complexity (complex first, simple later). + The guideline is that this should be done by the amount of parameters, but + if your method or documentation would be clearer by another order, you are + allowed to order them as you like. + + + + After the method synopsis is done, you add the documentation. This section + doesn't discuss the guidelines for writing good documentation. Please refer + to another section for that. Do remember that you need to wrap it between + <para> elements. + + + + + Operators + + + Operator overloading is quite common in the Haiku API + and as such it should be documented. The original Be Book gave operators + a special treatment, and we've decided to reproduce it in the Haiku Book as + well. As noted before, if there are any overloaded operators, they are placed + under a special bridgehead with the label Operators. In + essence, operators aren't so different from methods in the sense that + they both contain a methodsynopsis and a description, + but there are some oddities you need to be aware of. See the example + from the BString class: + + + +<bridgehead renderas="sect2">Operators</bridgehead> +<sect3 id="bstring_operator_assignment"> + <title>= (assignment)</title> + + <methodsynopsis> + <type>BString &amp;</type><methodname>operator=</methodname> + <methodparam><modifier>const</modifier><type>BString &amp;</type><parameter>string</parameter></methodparam> + </methodsynopsis> + + <methodsynopsis> + <type>BString &amp;</type><methodname>operator=</methodname> + <methodparam><modifier>const</modifier><type>char *</type><parameter>string</parameter></methodparam> + </methodsynopsis> + + + + The first thing to note is how the id in the + sect3 tag is built up. It starts with the lowercase + classname, an underscore, the word operator an + underscore, and a short description of what the operator does. Later this + section I'll try to present some standard operator descriptions which you + should follow as much as possible. + + + + The next thing is the title. The title is built up of the operator (here the + =), and a description of what it does, lowercase in parenthesis. + + + + Last thing of note in this example is that the methodname + is quite literally the name of the method in the header file. This wraps up + the conventions we use for individual overloaded operators. + + + + More interesting is the order of the operators. The following list shows + the order and the common descriptions of the overloaded operators. + + + + = (assignment) + += (append) + << (stream; formatted append) + [] (indexing) + ==, !=, <, >, <=, >= (comparison) + + + + This list is far from complete. As more classes are documented, more + possiblities will be described. Do try to combine the comparison operators + into one block: they share the same features. Also, if your description + contains a space, substitute it for an underscore in the id + parameter of the sect3 tag. + + + + + + How do I write a proper methodsynopsis? + + + Docbook provides several tools for properly documenting methods. It is + important that you use the correct markup, to create a uniform format. A + synopsis lives inside a methodsynopsis block. So open + and close the block and follow the following list of instructions step by step + to document the methods properly. + + + + + Open the block with <methodsynopsis>. Then put in + a newline and jump in one tab. + + + + If the method has a modifier, the first element of + the line is this modifier. Modifiers are virtual, + inline and static. Enclose the modifier + in a modifier block. + + + + For the return type, there are two options. + + + + In case the method doesn't return a value, please use the tag + <void/>. Note the trailing slash! + + + + In case of a return type, please enclose the return type in a + type block. Note that if you've got + const BList * as a return type, that complete segment + is the return type. So the const is also considered a + part of the return type! + + + + The name of the method is next, which should be enclosed in a + methodname block. Use the proper + capitalisation. Note that you don't need to include the trailing + parenthesis. The stylesheet will do this when it processes the block. + + + + If the method has arguments, put every argument on a new line. Put the line + between <methodparam> tags. + + + + If the argument has a modifier, use the modifier + tag. Modifiers are const and mutable. + Notice that const is considered a modifier + in arguments, as opposed to const in return + values. The logic is that you may pass a non-const object + in, and the modifier just tells you how the method is going to handle it, as + opposed to the return value which always is the const object when it has + that modifier. + + + + Put the type of the argument between type tags. Note + that if the argument is a pointer or a reference, that the asterix (*) and + the ampersand (&) are included between the tags. Pay attention + to the fact that XML requires your ampersand to be + encoded like this: &amp;. + + + + Enclose the the name of the parameter between parameter + tags. Note that the name of the parameter is obligatory. Use the original + name that is in the header file. + + + + If the argument has an initialiser, put the value between the + initializer tags. Note that you should not put the = in + front of it. + + + + Don't forget to end each line with </methodparam>! + + + + The last thing you need to be aware of is whether or not the method is + modified by a trailing const. If so, you need to append + <modifier>const</modifier>. The location + depends on whether or not the method has arguments. If it doesn't have + any arguments, just append it to the single line you've written. If there are + arguments, put this on a newline after the last argument. + + + + And of course, the <methodsynopsis> ends with + /<methodsynopsis>. + + + + + Please note that constructors and destructors have a slightly different syntax. + Instead of the <methodsynopsis> tags, they are + enclosed in the <constructorsynopsis> or + <destructorsynopsis> tags. And they don't have return + types. The rest of the rules that are described here are valid. + + + + + + &license; + diff --git a/src/documentation/haiku_book/support/Autolock.xml b/src/documentation/haiku_book/support/Autolock.xml new file mode 100644 index 0000000000..f5ce67d0b2 --- /dev/null +++ b/src/documentation/haiku_book/support/Autolock.xml @@ -0,0 +1,50 @@ + + + + BAutolock + + + Derived from: none + Declared in: os/support/AutoLock.h + Library: libbe.so + + + BAutolock implements easy locking and unlocking using a BLocker or a BLooper object. + + Constructors and Destructors + + BAutolock() + + + inlineBAutolock + BLooper *looper + + + + inlineBAutolock + BLocker *locker + + + + inlineBAutolock + BLocker &locker + + + + + ~BAutoLock() + + + inline~BAutolock + + + + Member Functions + + IsLocked() + + + boolIsLocked + + + diff --git a/src/documentation/haiku_book/support/BlockCache.xml b/src/documentation/haiku_book/support/BlockCache.xml new file mode 100644 index 0000000000..ad25b0e8c0 --- /dev/null +++ b/src/documentation/haiku_book/support/BlockCache.xml @@ -0,0 +1,53 @@ + + + + BBlockCache + + + Derived from: none + Declared in: os/support/BlockCache.h + Library: libbe.so + + + BBlockCache is used to manage a pool of memory blocks. + + Constructors and Destructors + + BBlockCache() + + + BBlockCache + uint32blockCount + size_tblockSize + uitn32allocationType + + + + + ~BBlockCache() + + + ~BBlockCache + + + + Member Functions + + + Get() + + + void *Get + size_tblockSize + + + + + Save() + + Save + void *pointer + size_tblockSize + + + diff --git a/src/documentation/haiku_book/support/Locker.xml b/src/documentation/haiku_book/support/Locker.xml new file mode 100644 index 0000000000..22b3cbb3b2 --- /dev/null +++ b/src/documentation/haiku_book/support/Locker.xml @@ -0,0 +1,120 @@ + + + + BLocker + + + Derived from: none + Declared in: os/support/Locker.h + Library: libbe.so + + + BLocker implements a locking mechanism that can be used to protect multithreaded code. + + Constructors and Destructors + + BLocker() + + + BLocker + + + + BLocker + constchar *name + + + + BLocker + boolbenaphore_style + + + + BLocker + constchar *name + boolbenaphore_style + + + + BLocker + constchar *name + boolbenaphore_style + boolbogus + + + + + ~BLocker() + + + virtual~BLocker + + + + Member Functions + + CountLocks() + + + int32CountLocksconst + + + + + CountLockRequests() + + + int32CountLockRequestsconst + + + + + IsLocked() + + + boolIsLockedconst + + + + + Lock() + + + boolLock + + + + + LockingThread() + + + thread_idLockingThreadconst + + + + + LockWithTimeout() + + + status_tLockWithTimeout + bigtime_ttimeout + + + + + Sem() + + + sem_idSemconst + + + + + Unlock() + + + Unlock + + + + diff --git a/src/documentation/haiku_book/support/String.xml b/src/documentation/haiku_book/support/String.xml new file mode 100644 index 0000000000..772e8c15c3 --- /dev/null +++ b/src/documentation/haiku_book/support/String.xml @@ -0,0 +1,382 @@ + + + + BString + + + Derived from: none + Declared in: os/support/String.h + Library: libbe.so + + + BString implements a high level string object. + + Constructors and Destructors + + BString() + + + BString + + + + BString + constchar *string + + + + BString + constBString &string + + + + BString + constchar *string + int32maxLength + + + + + ~BString() + + + ~BString() + + + + Member Functions + + Adopt() + + + BString &Adopt + BString &from + + + + BString &Adopt + BString &from + int32length + + + + + Append() + + + BString &Append + constBString &string + + + + BString &Append + const char *string + + + + BString &Append + constBString &string + int32length + + + + BString &Append + constchar *string + int32length + + + + BString &Append + charstring + int32count + + + + + CopyInto() + + + BString &CopyInto + BString &into + int32fromOffset + int32length + + + + CopyInto + char *into + int32fromOffset + int32length + + + + + CountChars() + + + int32CountCharsconst + + + + + Insert() + + + BString &Insert + constchar *string + int32pos + + + + BString &Insert + constchar *string + int32length + int32pos + + + + BString &Insert + constchar *string + int32fromOffset + int32length + int32pos + + + + BString &Insert + constBString &string + int32pos + + + + BString &Insert + constBString &string + int32length + int32pos + + + + BString &Insert + constBString &string + int32fromOffSet + int32length + int32pos + + + + BString &Inser + charstring + int32count + int32pos + + + + + Length() + + + int32Lengthconst + + + + + MoveInto() + + + BString &MoveInto + BString &into + int32from + int32length + + + + MoveInto + char *into + int32from + int32length + + + + + Prepend() + + + BString &Prepend + constBString &string + + + + BString &Prepend + constchar *string + + + + BString &Prepend + constBString &string + int32length + + + + BString &Prepend + constchar *string + int32length + + + + BString &Prepend + charstring + int32count + + + + + Remove() + + + BString &Remove + int32from + int32length + + + + + RemoveFirst() + + + BString &RemoveFirst + constBString &string + + + + BString &RemoveFirst + constchar *string + + + + + RemoveLast() + + + BString &RemoveLast + constBString &string + + + + BString &RemoveLast + constchar *string + + + + + RemoveAll + + + BString &RemoveAll + constBString &string + + + + BString &RemoveAll + constchar *string + + + + + RemoveSet + + + BString &RemoveSet + constchar *setOfCharsToRemove + + + + + SetTo + + + BString &SetTo + constchar *string + + + + BString &SetTo + constchar *string + int32length + + + + BString &SetTo + constBString &from + + + + BString &SetTo + constBString &from + int32length + + + + BString &SetTo + charstring + int32count + + + + + String() + + + const char *String const + + + + + Truncate() + + + BString &Truncate + int32newLength + boollazytrue + + + + Operators + + = (assignment) + + + BString &operator= + constBString &string + + + + BString &operator= + constchar *string + + + + BString &operator= + charstring + + + + + += (append) + + + BString &operator+= + constBString &string + + + + BString &operator+= + constchar *string + + + + BString &operator+= + constcharcharacter + + + + diff --git a/src/documentation/haiku_book/support/api.xml b/src/documentation/haiku_book/support/api.xml index 19e5a43a2b..3e48eedbb2 100644 --- a/src/documentation/haiku_book/support/api.xml +++ b/src/documentation/haiku_book/support/api.xml @@ -2,12 +2,20 @@ + + + ]> Support Kit API + &autolock; + &blockcache; &list; + &locker; + &string; diff --git a/src/documentation/haiku_book/support/intro.xml b/src/documentation/haiku_book/support/intro.xml index 5ca28d1822..5fa97e3d11 100644 --- a/src/documentation/haiku_book/support/intro.xml +++ b/src/documentation/haiku_book/support/intro.xml @@ -13,7 +13,7 @@ Threading utility classes: - BLocker and BAutoLock + BLocker and BAutoLock "Thread Local Storage" @@ -29,9 +29,9 @@ Container classes: - BBlockCache - BList - BString + BBlockCache + BList + BString BStopWatch