included"> ]> GTK-Doc kézikönyv 1.24.1 Felhasználói kézikönyv fejlesztők számára a GTK-Doc használatára vonatkozó utasításokkal. Chris Lyttle
chris@wilddev.net
Dan Mueth
d-mueth@uchicago.edu
Stefan Sauer (Kost)
ensonic@users.sf.net
GTK-Doc projekt
gtk-doc-list@gnome.org
 2000, 2005 Dan Mueth és Chris Lyttle 2007-2019 Stefan Sauer (Kost) Engedélyt adunk Önnek a jelen dokumentum sokszorosítására, terjesztésére és/vagy módosítására a Free Software Foundation által kiadott GNU Free Documentation License 1.2-es, vagy bármely azt követő verziójának feltételei alapján. Nincs Nem Változtatható szakasz, nincs Címlapszöveg, nincs Hátlapszöveg. A jelen licenc egy példányát mellékelve találja. A vállalatok által termékeik és szolgáltatásaik megkülönböztetésére használt nevek közül sokan védjegyként vannak bejegyezve. Ahol ezek a nevek megjelennek a GNOME dokumentációban, és a GNOME dokumentációs projekt tagjainak tudomásuk van ezekről a védjegyekről, ott a nevek nagybetűvel vagy nagy kezdőbetűvel vannak kiírva. 1.33.0 2020. október 1. mc gtk4 verzió 1.32.1 2019. augusztus 15. ss fejlesztői verzió 1.32 2019. augusztus 15. ss gyorsjavítási kiadás 1.31 2019. augusztus 5. ss újratervezések és jobb tesztlefedettség 1.30 2019. május 8. ss jobb tesztlefedettség 1.29 2018. augusztus 28. ss hibajavítások 1.28 2018. március 24. ss hibajavítások 1.27 2017. december 7. ss a Pythonra történő átírás finomhangolása 1.26 2017. augusztus 11. ss az összes eszköz átírása Perl és Bash nyelvekről Pythonra 1.25 2016. március 21. ss hibajavítások, teszttisztítások 1.24 2015. május 29. ss hibajavítás 1.23 2015. május 17. ss hibajavítás 1.22 2015. május 7. ss hibajavítások, elavult funkciók kidobása 1.21 2014. július 17. ss hibajavítások, elavult funkciók kidobása 1.20 2014. február 16. ss hibajavítások, Markdown-támogatás, stílusjavítások 1.19 2013. június 5. ss hibajavítások 1.18 2011. szeptember 14. ss hibajavítások, gyorsítások, Markdown-támogatás 1.17 2011. február 26. sk sürgős hibajavító frissítés 1.16 2011. január 14. sk hibajavítások, elrendezési továbbfejlesztések 1.15 2010. május 21. sk hibajavítások és regressziójavítások 1.14 2010. március 28. sk hibajavítások és teljesítményjavítások 1.13 2009. december 18. sk törött forráscsomag-frissítés 1.12 2009. december 18. sk új eszközfunkciók és hibajavítások 1.11 2008. november 16. mal GNOME doc-utils költöztetés Úr Balázs ur dot balazs at fsf dot hu 2023 2024 2026. Úr Balázs Bevezetés Ez a fejezet bemutatja a GTK-Doc dokumentációs eszközt, és áttekintést ad arról, hogy mi is ez, és hogyan használják. Mi a GTK-Doc? A GTK-Doc a C kód dokumentálására szolgál. Általában programkönyvtárak nyilvános API-jának dokumentálására használják, mint például a GLib-alapú programkönyvtárak, de használható az alkalmazás kódjának dokumentálására is. Hogyan működik a GTK-Doc? A GTK-Doc úgy működik, hogy beolvassa a forrásfájlokon belül elhelyezett különlegesen formázott megjegyzésblokkokat, hogy dokumentálja a szimbólumokat, mint például a függvényeket, makrókat, struktúrákat, felsorolásokat stb. (habár ne feledje, hogy a legtöbb szimbólumtípusnál a GTK-Doc csak a fejlécfájlokban deklarált szimbólumokat fogja dokumentálni, például nem fog kimenetet előállítani statikus függvényekhez). A GTK-Doc a sablonfájlokat is olvassa, amelyekbe dokumentáció is hozzáadható. A GTK-Doc számos programból áll, amelyek mindegyike más-más lépést hajt végre a folyamatban. A fő lépések a következők: A dokumentáció megírása. A szerző kitölti a forrásfájlokat minden egyes függvény, makró, struktúra, unió és egyéb szerkezetek dokumentációjával. Információgyűjtés a kódról. A gtkdoc-scan átvizsgálja a kód fejlécfájljait függvények, makrók, felsorolások, struktúrák és uniók deklarációit keresve. Létrehozza a deklarációk listáját tartalmazó <modul>-decl-list.txt fájlt, és szakaszokba helyezi azokat aszerint, hogy melyik fejlécfájlban vannak. Az első futáskor ez a fájl a <modul>-sections.txt fájlba lesz másolva. A szerző átrendezheti a szakaszokat és az azokon belüli deklarációk sorrendjét, hogy a kívánt végső sorrendet állítsa elő. A második fájl, amelyet előállít, a <modul>-decl.txt. Ez a fájl tartalmazza az átvilágító által talált összes deklarációt. Ha valamilyen oknál fogva valaki azt szeretné, hogy néhány szimbólum megjelenjen a dokumentációban, ahol a teljes deklarációt nem találja meg az átvizsgáló, vagy a deklarációnak másképp kellene megjelennie, akkor a <modul>-decl.txt fájlban lévőhöz hasonló entitásokat helyezhet el a <modul>-overrides.txt fájlba. A gtkdoc-scangobj arra is használható, hogy dinamikusan lekérdezzen egy programkönyvtárat az általa exportált GObject alosztályokról. Információt tárol az egyes objektumok osztályhierarchiában elfoglalt pozíciójáról, valamint az általa biztosított GObject-tulajdonságokról és szignálokról. A gtkdoc-scanobj függvényt nem szabad többé használni. Régebben volt rá szükség, amikor a GObject még GtkObject volt a GTK-n belül. Az XML és a HTML/PDF előállítása. A gtkdoc-mkdb átalakítja a sablonfájlokat XML-fájlokká az xml/ alkönyvtárban. Ha a forráskód tartalmaz dokumentációt a szimbólumokhoz a különleges megjegyzésblokkok használatával, akkor az beolvasztásra kerül ide. Ha nem használnak tmpl-fájlokat, akkor csak a forrásokból és a betekintési adatokból olvassa be a dokumentációt. A gtkdoc-mkhtml átalakítja az XML-fájlokat HTML-fájlokká a html/ alkönyvtárban. Hasonlóképpen a gtkdoc-mkpdf átalakítja az XML-fájlokat <csomag>.pdf nevű PDF-dokumentummá. Az xml/ és a html/ könyvtárakban lévő fájlok mindig felülírásra kerülnek. Soha sem szabad közvetlenül szerkeszteni azokat. A dokumentumok közötti kereszthivatkozások javítása. A HTML-fájlok telepítése után a gtkdoc-fixxref futtatható a különálló dokumentumok közötti kereszthivatkozások javításához. Például a GTK dokumentáció számos kereszthivatkozást tartalmaz a GLib kézikönyvben dokumentált típusokra. A terjesztésre szánt forráscsomag létrehozásakor a gtkdoc-rebase az összes külső hivatkozást webes hivatkozásokká alakítja. A terjesztett (előre előállított) dokumentumok telepítésekor ugyanez az alkalmazás megpróbálja a hivatkozásokat visszaalakítani helyi hivatkozásokká (ahová az adott dokumentumok telepítve vannak). A GTK-Doc beszerzése Követelmények python 2/3 – a fő parancsfájlok Python nyelven lettek írva. xsltproc – az XSLT-feldolgozó a libxslt csomagból, xmlsoft.org/XSLT/ docbook-xsl – a Docbook XSL-stíluslapjai, sourceforge.net/projects/docbook/files/docbook-xsl A source-highlight, highlight vagy vim egyike – nem kötelező – a példák szintaxis-kiemeléséhez van használva A GTK-Doc története Történetileg a GTK-Doc programot arra használták, hogy sablonfájlokat állítsanak elő a forráskódból. Ezeket a sablonfájlokat a fejlesztők használhatták az API-dokumentáció bevitelére. Ez a megközelítés meglehetősen kényelmetlen volt, mivel az előállított fájlokat verziókövetés alatt kellett tartani. A GTK-Doc 1.9 óta lehetővé vált, hogy az összes API-információ forrásmegjegyzésekbe kerüljön, ami elavulttá tette a sablontámogatást. Az 1.26-os verzióban a sablontámogatás eltávolításra került. (JAVÍTS KI) (szerzők, weboldalak, levelezőlista, licenc, jövőbeli tervek, összehasonlítás más, hasonló rendszerekkel) Erről a kézikönyvről (JAVÍTS KI) (kinek szánják, hol lehet hozzájutni, licenc) Projekt beállítása Ez a fejezet azokat a lépéseket írja le, amelyek a GTK-Doc projektbe való integrálásához szükségesek. A GTK-Doc projektbe való integrálása a következő lépéseket tartalmazza: A könyvtárszerkezet előkészítése és a GTK-Doc dokumentációhoz szükséges beállítási fájlok létrehozása (nézze meg a Dokumentációvázlat beállítása szakaszt). Az összeállítási rendszer beállítása a dokumentáció összeállításához a GTK-Doc eszközök használatával. Több összeállítási rendszer is támogatott, ebben a kézikönyvben azt mutatjuk be, hogy hogyan integrálható a GTK-Doc az Autotools, a CMake és az egyszerű Makefile megoldásokkal. GTK-Doc specifikus fájlok hozzáadása a verziókövetéshez és annak eldöntése, hogy mely fájlokat kell figyelmen kívül hagyni (nézze meg az Integráció verziókövető rendszerekkel szakaszt). A következő szakaszok azt feltételezik, hogy egy meep nevű projekten dolgozunk. Ez a projekt két csomagot (vagy modult) tartalmaz, egy libmeep nevű programkönyvtárat és egy meeper nevű végfelhasználói alkalmazást. Dokumentációvázlat beállítása Általános gyakorlat, hogy a dokumentáció a docs nevű mappába kerül a legfelső szintű projektkönyvtáron belül. Általában különbséget teszünk a fejlesztőknek szánt hivatkozási dokumentáció és a végfelhasználóknak szánt felhasználói kézikönyv között. Megint csak az a gyakorlat, hogy mindkettőhöz külön mappák tartoznak. A hivatkozási dokumentációt általában a reference nevű mappába, a végfelhasználói kézikönyvet pedig a help nevű mappába tesszük. A fenti gyakorlat szerint a libmeep csomagunk dokumentációja a következő helyre kerülne: docs/reference/libmeep. A csak egy programkönyvtárat vagy alkalmazást tartalmazó csomagok esetében a dokumentációt közvetlenül a docs/reference mappában is elhelyezhetjük. Nem kötelező a fenti gyakorlatot használni, de ha más könyvtárszerkezet használatát választja, akkor a könyvtárszerkezetnek megfelelően kell beállítania az összeállítási rendszer beállításait. A következő szakaszokban olyan könyvtárszerkezetet feltételezünk a meep projektünkhöz, amely a fenti gyakorlatokat használja. A <emphasis>meep</emphasis> projekt könyvtárszerkezeti példája meep/ docs/ reference/ # hivatkozási dokumentáció libmeep/ meeper/ help/ # elhagyható: felhasználói kézikönyv meeper/ src/ libmeep/ meeper/ Integráció az Autotools programmal A GTK-Doc integrálása egy autotools alapú összeállítási rendszerbe a következő lépéseket igényli: Győződjön meg arról, hogy a gtkdocize egyszer lefusson a configure parancsfájl előtt. Ha egy autogen.sh parancsfájl is jelen van, akkor állítsa be úgy, hogy ellenőrizze a GTK-Doc eszközt, és adjon hozzá egy gtkdocize hívást. A gtkdocize fő célja, hogy elkészítse az összeállítási rendszerhez elérhető gtk-doc.make Makefile-t és gtk-doc.m4 makródefiníciós fájlt a projektbe történő másolással vagy a projekthez történő kapcsolással. Adja hozzá a szükséges autoconf makrókat a configure.ac fájlhoz, hogy engedélyezze a GTK-Doc eszközt az összeállítási rendszerben a GTK-Doc beállításainak az előállított configure parancsfájl általi engedélyezéséhez. Többek között a --enable-gtk-doc kapcsoló regisztrálásával a configure parancsfájlban. Hozzon létre egy automake parancsfájlt a projekt minden egyes alkalmazásához vagy programkönyvtárához. Az ebben a dokumentációban használt példában ez a lépés mind a meeper alkalmazásra, mind a libmeep programkönyvtárra vonatkozik. A következő szakaszokban a fenti lépéseket fordított sorrendben hajtjuk végre. Az automake parancsfájlokkal kezdjük, és folytatjuk a munkát a configure.ac és autogen.sh parancsfájlokig. Ezután megmutatjuk, hogyan engedélyezzük a GTK-Doc használatát az összeállítási rendszerben, és hogyan állítsuk össze a dokumentációt. Integráció az automake programmal Először másolja át a Makefile.am fájlt a gtkdoc-sources examples alkönyvtárából a projektje hivatkozási dokumentációs könyvtárába (például docs/reference/<csomag>). Egy helyi másolatnak az /usr/share/doc/gtk-doc-tools/examples/Makefile.am alatt kell elérhetőnek lennie. Ha több csomagja van, akkor ezt ismételje meg mindegyiknél. Ne felejtsen el hozzáadni minden Makefile.am fájlt az AC_CONFIG_FILES makróhoz a configure.ac fájlban. A docs/reference/libmeep/Makefile.am esetén a docs/reference/libmeep/Makefile bejegyzést kell hozzáadnia az AC_CONFIG_FILES makróhoz. Könyvtárszerkezeti példa a <filename>Makefile.am</filename> fájlokkal meep/ docs/ reference/ # hivatkozási dokumentáció libmeep/ Makefile.am meeper/ Makefile.am help/ # elhagyható: felhasználói kézikönyv meeper/ src/ libmeep/ meeper/ Ezután személyre kell szabnia a lemásolt Makefile-okat, és meg kell adnia a különböző paraméterek értékeit az egyes Makefile.am fájlokban. Az összes beállítás fölött található egy megjegyzés, amely leírja a céljukat és a beállítás személyre szabását. A legtöbb beállítás arra szolgál, hogy további jelzőket adjon azokhoz az eszközökhöz, amelyekre vonatkozik. Minden eszköz rendelkezik egy formájú változóval (például a gtkdoc-mkhtml eszköznek van egy MKHTML_OPTIONS nevű kapcsolója). Az összes eszköz támogatja a kapcsolót a támogatott kapcsolók felsorolásához. A következő lista a legfontosabb kapcsolókat ismerteti. További kapcsolókért nézze meg a Makefile.am példát. A a dokumentálandó csomag nevének megadására szolgál (például meeper vagy libmeep). A a forráskönyvtár helyének megadására szolgál, amelyben a GTK-Doc az API dokumentációját keresi. Ez általában a DOC_SOURCE_DIR=$(top_srcdir)/src vagy annak a könyvtárnak az alkönyvtára. A és a függőségekhez használatos. Mindkét kapcsoló egy fájl globot vár (például HFILE_GLOB=$(top_srcdir)/src/*.c). A dokumentáció újra összeállításra kerül, ha bármelyik illeszkedő fájl megváltozik. Az lehetővé teszi az API-dokumentáció keresésekor a további beágyazandó fejlécfájlok megadását, amelyek nem találhatók meg a DOC_SOURCE_DIR alatt (például EXTRA_HFILES=$(top_srcdir}/contrib/extra.h). Az lehetővé teszi a figyelmen kívül hagyandó fejlécfájlok vagy könyvtárak megadását az API-dokumentáció keresésekor. Használja a fájl vagy könyvtár alapnevét (például IGNORE_HFILES=gtkdebug.h gtkintl.h személyes_kód_mappa). A lehetővé teszi az olyan képfájlok megadását, amelyek az előállított dokumentáció html/ könyvtárába lesznek másolva. Ha az API-dokumentáció tartalmaz képeket, akkor azokat is hozzá kell adni ehhez a kapcsolóhoz (például HTML_IMAGES=$(top_srcdir)/gtk/stock-icons/stock_about_24.png). A lehetővé teszi a további fájlok megadását, amelyeket a $(DOC_MAIN_SGML_FILE) beágyaz (például content_files=running.xml building.xml changes-2.0.xml). Az lehetővé teszi azoknak a fájloknak a megadását, ahol a gtk-doc rövidítések – mint például a #GtkWidget – ki vannak bővítve (például expand_content_files=running.xml). Integráció az autoconf programmal Az autoconf programmal való integráció nagyon egyszerű, és egy kötelező, valamint egy további választható (de ajánlott) lépést tartalmaz. Az első lépés a GTK_DOC_CHECK makró hozzáadása a configure.ac parancsfájljához. Ez számos beállítási kapcsolót regisztrál a GTK-Doc engedélyezéséhez, és lehetővé teszi a gtkdocize alapértelmezett argumentumainak beállítását. Győződjön meg arról, hogy a GTK_DOC_CHECK makró ne legyen behúzva. A makrónak a sor elején kell kezdődnie, és nem kezdődhet üres karakterekkel. A második lépés az AC_CONFIG_MACRO_DIR(m4) hozzáadása a configure.ac parancsfájljához. Ez nem kötelező, de segít a gtkdocize eszköznek abban, hogy azt a makródefiníciót (például gtk-doc.m4), amely a GTK_DOC_CHECK makrót tartalmazza, automatikusan a projektje makrókönyvtárába másolja. Enélkül előfordulhat, hogy a GTK_DOC_CHECK makrót nem találja meg, és kifejezetten meg kell mondania az aclocal eszköznek, hogy hol találja meg a makródefiníciós fájlt. Minimális integráció az autoconf programmal # ajánlott: az m4 könyvtár beállítása AC_CONFIG_MACRO_DIR(m4) # elhagyható: a gtk-doc regisztrálása a configure fájlban GTK_DOC_CHECK([1.28]) A fenti példa működik, de minden fejlesztőtől megköveteli a gtk-doc telepítését. Jobb megoldás, ha a dokumentáció összeállítását nem tesszük kötelezővé, ahogy a következő példában látható: Integráció a választható gtk-doc függőséggel m4_ifdef([GTK_DOC_CHECK], [ # ajánlott: az m4 könyvtár beállítása AC_CONFIG_MACRO_DIR(m4) # elhagyható: a gtk-doc regisztrálása a configure fájlban GTK_DOC_CHECK([1.28]) ],[ AM_CONDITIONAL([ENABLE_GTK_DOC], false) ]) Az első argumentum a GTK-Doc verziójának ellenőrzésére szolgál a beállításkor. A második, nem kötelező argumentumot a gtkdocize használja. A GTK_DOC_CHECK makró számos beállítási kapcsolót is hozzáad: --with-html-dir=PATH : útvonal a telepített dokumentációkhoz --enable-gtk-doc : a gtk-doc használata a dokumentáció összeállításához [alapértelmezett=nem] --enable-gtk-doc-html : dokumentáció összeállítása HTML formátumban [alapértelmezett=igen] --enable-gtk-doc-pdf : dokumentáció összeállítása PDF formátumban [alapértelmezett=nem] A GTK-Doc alapértelmezetten le van tiltva! Ne felejtse el átadni az kapcsolót a következő configure futtatásához. Egyébként előre előállított dokumentáció kerül telepítésre (aminek a felhasználók számára van értelme, de a fejlesztők számára nincs). Miután a configure.ac fájl összes módosítása megtörtént, frissítse a configure fájlt. Ezt az autogen.sh újbóli futtatásával lehet megtenni. Integráció az autogen programmal A legtöbb projekt rendelkezik autogen.sh parancsfájllal az összeállítási infrastruktúra beállításához, miután a projektet lekérték egy verziókövető rendszerből (például git vagy svn). A GTK-Doc egy gtkdocize nevű parancsfájllal érkezik, amely arra használható, hogy a GTK-Doc számára szükséges fájlokat a forráskönyvtárba másolja. Ezt az autoreconf, autoheader, automake vagy autoconf előtt kell futtatni. A gtkdocize futtatása az autogen.sh fájlból gtkdocize || exit 1 A gtkdocize feltételes futtatása az autogen.sh fájlból GTKDOCIZE=$(which gtkdocize 2>/dev/null) if test $? -ne 0; then echo "Nem található gtk-doc támogatás. Nem állítható össze a dokumentáció." else $GTKDOCIZE || exit 1 fi A gtkdocize futtatásakor átmásolja a gtk-doc.make fájlt a projektje gyökerébe (vagy a kapcsolóval megadott bármely könyvtárba). A gtkdocize átnézi a configure.ac parancsfájlt a GTK_DOC_CHECK makrót keresve. A GTK_DOC_CHECK makró használható további argumentumok átadásához a gtkdocize parancsfájl számára. A második paraméter a GTK_DOC_CHECK makróban. Másik lehetőségként további argumentumok is átadhatók a gtkdocize makrónak a GTKDOCIZE_FLAGS környezeti változón keresztül, vagy közvetlenül megadva azokat a gtkdocize számára az autogen.sh fájlban. A GTK-Doc végrehajtása az összeállítási rendszerből Az előző lépések után itt az ideje az összeállítás futtatásának. Először az autogen.sh ismételt futtatása szükséges. Ha ez a parancsfájl futtatja a configure fájlt, akkor adja meg neki az kapcsolót. Ellenkező esetben futtassa kézzel a configure fájlt utólag ezzel a kapcsolóval. A make első futtatása számos további fájlt állít elő a dokumentációs könyvtárakban. A legfontosabbak a következők: <csomag>.types, <csomag>-docs.xml (régebben .sgml), <csomag>-sections.txt. A dokumentáció összeállításának futtatása ./autogen.sh --enable-gtk-doc make Most nyissa meg a böngészőjével a docs/reference/<csomag>/index.html fájlt. Ezzel a kezdeti beállítással csak egy nagyon egyszerű dokumentumot fog látni. A következő fejezetben megtanítjuk, hogyan adhat API-dokumentációt a kódjához a különleges megjegyzésblokkok segítségével. A fejezet ezt követően bemutatja a további fájlokat, és megmutatja, hogyan szerkesztheti a mestersablont, hogy további fejezeteket és szakaszokat adjon a dokumentációs fájljaihoz. Integráció a CMake összeállítási rendszerekkel A GTK-Doc mostantól biztosít egy GtkDocConfig.cmake modult (és a megfelelő GtkDocConfigVersion.cmake modult). Ez biztosít egy gtk_doc_add_module parancsot, amelyet beállíthat a CMakeLists.txt fájlban. A következő példa azt mutatja be, hogy hogyan kell használni ezt a parancsot. Példa a GTK-Doc CMake-ből való használatára find_package(GtkDoc 1.25 REQUIRED) # A doc-libmeep cél létrehozása. gtk_doc_add_module( libmeep ${CMAKE_SOURCE_DIR}/libmeep XML meep-docs.xml LIBRARIES libmeep ) # A doc-libmeep összeállítása az alapértelmezett cél részeként. Enélkül # kifejezetten futtatni kellene valami olyasmit, mint a „make doc-libmeep” # a dokumentáció összeállításához.add_custom_target(documentation ALL DEPENDS doc-libmeep) # A dokumentáció telepítése (ez azt feltételezi, hogy a GNUInstallDirs CMake # modulját használja a CMAKE_INSTALL_DOCDIR változó helyes beállításához). install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/libmeep/html DESTINATION ${CMAKE_INSTALL_DOCDIR}) Integráció egyszerű makefile-okkal vagy egyéb összeállítási rendszerekkel Abban az esetben, ha valaki nem szeretné az automake és ezáltal a gtk-doc.mak használatát, akkor a gtkdoc eszközöket a megfelelő sorrendben kell meghívni a saját makefile-okban (vagy más összeállítási eszközökben). Dokumentáció összeállítási lépései DOC_MODULE=meep // források megváltoztak gtkdoc-scan --module=$(DOC_MODULE) <source-dir> gtkdoc-scangobj --module=$(DOC_MODULE) gtkdoc-mkdb --module=$(DOC_MODULE) --output-format=xml --source-dir=<source-dir> // XML-fájlok megváltoztak mkdir html cd html && gtkdoc-mkhtml $(DOC_MODULE) ../meep-docs.xml gtkdoc-fixxref --module=$(DOC_MODULE) --module-dir=html Meg kell nézni a Makefile.am és a gtk-doc.mak fájlokat a szükséges további kapcsolók kiválasztásához. Integráció verziókövető rendszerekkel Ökölszabályként a szerkesztett fájloknak kell verziókövetés alá kerülniük. Tipikus projektek esetén ezek a következő fájlok: <csomag>.types, <csomag>-docs.xml (régebben .sgml), <csomag>-sections.txt, Makefile.am. Az xml/ és a html/ könyvtárakban lévő fájlok nem kerülhetnek verziókövetés alá. A .stamp fájlok egyikének sem kellene. A kód dokumentálása A GTK-Doc a forráskód különleges szintaxisú megjegyzéseit használja a kód dokumentációjához. Továbbá információkat szerez a projekt szerkezetéről más forrásokból. A következő szakaszban minden információt megtalál a megjegyzések szintaxisáról. A GTK-Doc átvizsgáló a C fejlécek többségét jól tudja kezelni. Abban az esetben, ha az átvizsgálótól olyan figyelmeztetések érkeznek, amelyek különleges esetnek tűnnek, a GTK-Doc eszköznek jelezni lehet, hogy hagyja ki azokat. GTK-Doc megjegyzésblokk #ifndef __GTK_DOC_IGNORE__ /* feldolgozhatatlan kód itt */ #endif Korlátozások Ne feledje, hogy a GTK-Doc az #ifndef(__GTK_DOC_IGNORE__) megadást támogatja, de az #if !defined(__GTK_DOC_IGNORE__) vagy egyéb kombinációkat nem. Dokumentációs megjegyzések Egy további „*” karakterrel kezdődő többsoros megjegyzés olyan dokumentációs blokkot jelöl, amelyet a GTK-Doc eszközök feldolgoznak. GTK-Doc megjegyzésblokk /** * azonosító: * dokumentáció ... */ Az „azonosító” egy sorban tartalmazza annak az elemnek a nevét, amelyhez a megjegyzés kapcsolódik. A szintaxis az elemtől függően némileg eltér. (TEENDŐ: az azonosítókat megjelenítő táblázat hozzáadása) A „dokumentáció” blokk szintén különbözik az egyes szimbólumtípusoknál. A paramétereket kapó szimbólumtípusoknál, mint például a függvények vagy makrók, a paraméter leírása az első, amit egy üres sor követ (csak egy „*”). Ezután következik a részletes leírás. Az összes olyan sor (a programlistákon és a CDATA szakaszokon kívül), amely csak „ *” karaktereket (üres helyet és csillagot) tartalmaz, bekezdéstörésekké lesznek átalakítva. Ha nem szeretne bekezdéstörést, akkor változtassa át „ * ” karaktersorozatra (üres hely, csillag, üres hely, üres hely). Ez hasznos az előformázott szövegnél (kódlistáknál). A kód dokumentálásakor két szempontot kell leírni: Mi ez: egy osztály vagy funkció neve néha félrevezető lehet a más háttérrel érkezők számára. Mit csinál: mondja el a gyakori használatot, helyezze kapcsolatba a többi API-val. A hiperszöveg egyik előnye az egyszerű szöveggel szemben az, hogy a dokumentumban hivatkozások is lehetnek. Egy hivatkozás megfelelő jelölésének megírása azonban fárasztó lehet. A GTK-Doc számos hasznos rövidítéssel segít ebben. Használja a függvény() jelölést az olyan függvényekre vagy makrókra való hivatkozáshoz, amelyek argumentumokat fogadnak el. Használja a @paraméter jelölést a paraméterekre való hivatkozáshoz. Akkor is használja, ha más függvények paramétereire hivatkozik, amelyek a leírtakhoz kapcsolódnak. Használja a %konstans jelölést egy konstansra való hivatkozáshoz, például %G_TRAVERSE_LEAFS. Használja a #szimbólum jelölést más típusú szimbólumokra, például struktúrákra, felsorolásokra és olyan makrókra, amelyek nem fogadnak el argumentumokat. Használja az #Objektum::szignál jelölést egy GObject szignálra való hivatkozáshoz. Használja az #Objektum:tulajdonság jelölést egy GObject tulajdonságra való hivatkozáshoz. Használja a #Struktúra.mező jelölést egy struktúrán belüli mezőre való hivatkozáshoz, és a #GObjectClass.foo_bar() jelölést egy virtuális metódusra való hivatkozáshoz. Ha különleges karaktereket („<”, „>”, „(”, „)”, „@”, „%” vagy „#”) kell használnia a dokumentációban anélkül, hogy a GTK-Doc megváltoztatná azokat, használhatja az XML-entitásukat („&lt;”, „&gt;”, „&lpar;”, „&rpar;”, „&commat;”, „&percnt;” vagy „&num;”) a fentieknek megfelelően vagy elfedheti azokat egy visszafelé mutató perjellel („\”). A DocBook többre is képes a hivatkozásoknál. Lehetnek benne listák, példák, címsorok és képek is. Az 1.20-as verziótól kezdve az előnyben részesített mód a Markdown nevű alapvető szövegformázási szintaxis egy részhalmazának használata. A régebbi GTK-Doc verziókban minden olyan dokumentáció, amely Markdown formátumot tartalmaz, úgy lesz megjelenítve, ahogy van. Például a listaelemek kötőjellel kezdődő sorokként jelennek meg. Míg a Markdown most előnyben részesített, mindkettőt lehet vegyesen használni. Az egyik korlátozás az, hogy a DocBook XML használható a Markdown jelölésen belül, de a Markdown a DocBook XML-en belül nem támogatott. Ha a régebbi GTK-Doc kiadásokban további formázási támogatásra volt szüksége, akkor engedélyeznie kellett a DocBook XML címkék használatát a dokumentációs megjegyzéseken belül úgy, hogy (vagy ) kapcsolókat tett az MKDB_OPTIONS változóba a Makefile.am fájlon belül. GTK-Doc megjegyzésblokk Markdown használatával /** * azonosító: * * dokumentációs bekezdés ... * * # Alcímsor # * * ## Második alcímsor * * # Alcímsor hivatkozási horgonnyal # {#heading-two} * * további dokumentáció: * * - Első listaelem * * Bekezdés a listaelemen belül. * * - Második listaelem * * 1. számozott listaelem * * 2. egy másik számozott listaelem * * Még egy bekezdés. [Hivatkozás a GNOME webhelyére](http://www.gnome.org/) * * ![egy beágyazott kép](plot-result.png) * * [Hivatkozás a fenti címsorhorgonyra][heading-two] * * Egy C nyelven írt példa: * |[<!-- language="C" --> * GtkWidget *label = gtk_label_new ("Gyönyörű!"); * ]| */ További példák találhatók a támogatott Markdown-címkékre a GTK dokumentáció Markdown-szintaxis hivatkozásában. Mint már korábban említettük, a GTK-Doc a nyilvános API dokumentálására szolgál. Így statikus szimbólumokhoz nem lehet dokumentációt írni. Mindazonáltal jó, ha ezeket a szimbólumokat is ellátjuk megjegyzéssel. Ez segít más fejlesztőknek megérteni a kódot. Ezért azt javasoljuk, hogy ezeket normál megjegyzésekkel dokumentálja (a második „*” nélkül az első sorban). Ha később a függvényt nyilvánossá kell tenni, akkor csak annyit kell elvégezni, hogy a egy újabb „*” karaktert kell hozzáadni a megjegyzésblokkhoz, és a megfelelő helyre be kell illeszteni a szimbólum nevét a „sections” fájljában. Szakaszok dokumentálása A dokumentáció minden egyes szakasza egy-egy osztályról vagy modulról tartalmaz információt. Az összetevő bemutatásához írhatunk szakaszblokkot. A rövid leírást a tartalomjegyzéken belül is használják. Egyik @mező használata sem kötelező. Szakasz megjegyzésblokkja /** * SECTION:meepapp * @short_description: az alkalmazás osztálya * @title: Meep alkalmazás * @section_id: * @see_also: #MeepSettings * @stability: Stable * @include: meep/app.h * @image: application.png * * Az alkalmazás osztálya kezeli a ... */ SECTION:<név> A név összekapcsolja a szakasz dokumentációját a <csomag>-sections.txt fájl megfelelő részével. Az itt megadott névnek meg kell egyeznie a <FILE> címkével a <csomag>-sections.txt fájlban. @short_description A szakasz egysoros leírása, amely később a hivatkozás után jelenik meg a tartalomjegyzékben és a szakasz oldalának tetején. @title A szakasz címe alapértelmezetten a SECTION deklarációból származó <név>. Ez felülírható a @title mezővel. @section_id Felülírja a cím szakaszazonosítóként való használatát. A GObject objektumoknál a <title> lesz szakaszazonosítóként használva, más szakaszoknál pedig a <MODUL>-<cím>. @see_also A szakaszhoz kapcsolódó szimbólumok listája. @stability Az API stabilitási szintjének nem hivatalos leírása. Javasoljuk a következő kifejezések egyikének használatát: Stable – A stabil interfész célja, hogy lehetővé tegye tetszőleges harmadik fél számára, hogy alkalmazásokat fejlesszen ezekre az interfészekre, kiadja azokat, és bízzon abban, hogy azok a termék minden kisebb kiadásán futni fognak (az interfész bevezetését követő, de ugyanazon fő kiadáson belül). Még egy fő kiadásnál is elvárható, hogy az inkompatibilis változtatások ritkák legyenek, és hogy erős indoklással rendelkezzenek. Unstable – Az instabil interfészek kísérleti vagy átmeneti jellegűek. Általában arra használják azokat, hogy külső fejlesztőknek korai hozzáférést biztosítsanak új vagy gyorsan változó technológiához, vagy hogy átmeneti megoldást nyújtsanak egy olyan problémára, amelyre általánosabb megoldást várnak. Sem a forrás-, sem a bináris kompatibilitás tekintetében nem állítanak semmit az egyik kisebb kiadásról a másikra. Private – Egy olyan interfész, amely a GNOME rendszerben használható, de nincs dokumentálva a végfelhasználók számára. Az ilyen függvényeket csak meghatározott és dokumentált módon szabad használni. Internal – Egy olyan interfész, amely egy modul belső része, és nem igényel végfelhasználói dokumentációt. A dokumentálatlan függvények belsőnek tekintendők. @include Az #include fájlok, amelyeket a szakasz összefoglalójában kell megjeleníteni (vesszővel elválasztott lista), felülírva a szakaszfájlból vagy a parancssorból származó globális értéket. Ez az elem nem kötelező. @image Az a kép, amelyet a hivatkozási oldal tetején kell megjeleníteni ebben a szakaszban. Ez gyakran valamilyen diagram lesz, amely az osztály vizuális megjelenését vagy más osztályokkal való kapcsolatát szemlélteti. Ez az elem nem kötelező. A felesleges újrafordítás elkerülése érdekében a dokumentáció változtatásai után tegye a szakasz dokumentációit a C-forrásba, ahol csak lehetséges. Szimbólumok dokumentálása Minden szimbólum (függvény, makró, struktúra, felsorolás, szignál és tulajdonság) külön blokkban van dokumentálva. A blokkot célszerű a szimbólumok definíciójához közel elhelyezni, hogy könnyen szinkronban lehessen tartani őket. Így a függvényeket általában a C-forrásban, a makrókat, struktúrákat és felsorolásokat pedig a fejlécfájlban dokumentálják. Általános címkék Verziózási információkat adhat az összes dokumentációs elemhez, hogy megmondja, mikor lett egy API bevezetve, vagy mikor vált elavulttá. Verziózási címkék Since: Annak leírása, hogy a kód melyik verziója óta érhető el az API. Deprecated: Olyan bekezdés, amely azt jelzi, hogy ezt a funkciót nem szabad tovább használni. A leírásnak az új API-ra kell irányítania az olvasót. Az összes dokumentációs elemhez stabilitási információt is adhat annak feltüntetéséhez, hogy az API stabilitása garantált-e hozzájuk a projekt összes jövőbeli kisebb kiadásában. Az összes dokumentációs elem alapértelmezett stabilitási szintje beállítható a argumentum gtkdoc-mkdb részére történő átadásával, az alábbi értékek egyikével. Stabilitási címkék Stability: Stable Az elem megjelölése stabilként. Ez olyan nyilvános API-kra vonatkozik, amelyek garantáltan stabilak maradnak a projekt összes jövőbeli kisebb kiadásában. Stability: Unstable Az elem megjelölése instabilként. Ez olyan nyilvános API-kra vonatkozik, amelyeket előzetesként adnak ki a stabilizálás előtt. Stability: Private Az elem megjelölése privátként. Ez olyan interfészekre vonatkozik, amelyeket szorosan összekapcsolt modulok használhatnak, de tetszőleges harmadik felek nem. Általános címkék /** * foo_get_bar: * @foo: valamilyen izé * * Visszaadja a @foo bigyóját. * * Returns: @foo' bigyója * * Since: 2.6 * Deprecated: 2.12: Használja a foo_baz_get_bar() függvényt helyette. */ Bar * foo_get_bar(Foo *foo) { ... Magyarázó jegyzetek A dokumentációs blokkok tartalmazhatnak magyarázó megjegyzés címkéket. Ezek a címkék a jelentésüket leíró buboréksúgókkal lesznek megjelenítve. A címkéket a GObject Introspection használja a nyelvi kötődések előállításához. A támogatott címkék részletes listája megtalálható a GObject Introspection dokumentációjában. Magyarázó jegyzetek /** * foo_get_bar: (megjegyzés) * @foo: (megjegyzés): valamilyen izé * * Visszaadja a @foo bigyóját. * * Returns: (megjegyzés): a @foo bigyója */ ... /** * foo_set_bar_using_the_frobnicator: (megjegyzés) (másik megjegyzés) * (és még egy megjegyzés) * @foo: (megjegyzés) (másik megjegyzés): valamilyen izé * * Beállítja a bigyót a @foo izén. */ Függvény megjegyzésblokkja Ne felejtse el a következőket: Dokumentálja, hogy a visszaadott objektumokat, listákat, karakterláncokat stb. fel kell-e szabadítani, meg kell-e szüntetni a hivatkozásukat, illetve ki kell-e adni. Dokumentálja, hogy a paraméterek lehetnek-e NULL értékűek, és mi történjen, ha azok. Említse meg az érdekes elő- és utófeltételeket, ahol szükséges. A GTK-Doc azt feltételezi, hogy az összes „_” karakterrel kezdődő szimbólum (makró, függvény) privát. Úgy kezeli őket, mint a statikus függvényeket. Függvény megjegyzésblokkja /** * függvénynév: * @par1: az 1. paraméter leírása. Ez kiterjedhet több * sorra is. * @par2: a 2. paraméter leírása. * @...: %NULL-ra végződő bigyólisták. * * A függvény leírása kerül ide. A @par1 használatával hivatkozhat a * paraméterekre, így azok a kimeneten kiemelve jelennek meg. Használhatja * továbbá a %konstans jelzőt konstansok esetén, a függvény_neve2() jelzőt * függvények esetén és a #GtkWidget jelzőt más deklarációkra mutató * hivatkozások esetén (amelyek máshol lehetnek dokumentálva). * * Returns: egy egész szám. * * Since: 2.2 * Deprecated: 2.18: Használja az egyéb_függvény() függvényt helyette. */ A függvény címkéi Returns: A visszaadott eredményt leíró bekezdés. @...: Abban az esetben, ha a függvénynek változó argumentumai vannak, akkor ezt a címkét kell használnia (a @Varargs: történelmi okokból szintén működik). Tulajdonság megjegyzésblokkja Tulajdonság megjegyzésblokkja /** * ValamilyenElem:valamilyen-tulajdonság: * * Itt dokumentálhat egy tulajdonságot. */ g_object_class_install_property (object_class, PROP_SOME_PROPERTY, ...); Szignál megjegyzésblokkja Ne felejtse el a következőket: Dokumentálja, hogy a szignál mikor kerül kibocsátásra, és hogy más szignálok előtt vagy után kerül-e kibocsátásra. Dokumentálja, hogy mit tehet egy alkalmazás a szignál kezelőjében. Szignál megjegyzésblokkja /** * FooWidget::foobarized: * @widget: a kütyü, amely fogadta a szignált * @foo: valamilyen izé * @bar: valamilyen bigyó * * A ::foobarized szignál minden alkalommal kibocsátásra kerül, ha valaki * megpróbálja megizélni a @widget kütyüt. */ foo_signals[FOOBARIZED] = g_signal_new ("foobarized", ... Struktúra megjegyzésblokkja Struktúra megjegyzésblokkja /** * FooWidget: * @bar: valamilyen #gboolean * * Ez a valaha volt legjobb kütyü. */ typedef struct _FooWidget { GtkWidget parent_instance; gboolean bar; } FooWidget; Használja a /*< private >*/ jelölést azon privát struktúramezők előtt, amelyeket el szeretne rejteni. Használja a /*< public >*/ jelölést a fordított viselkedésért. Ha az első mező „g_iface”, „parent_instance” vagy „parent_class”, akkor az automatikusan privátnak minősül, és nem kell megemlíteni a megjegyzésblokkban. A struktúrák megjegyzésblokkjai GObjectek és GObjectClassok esetében is használhatók. Általában jó ötlet egy osztályhoz megjegyzésblokkot hozzáadni, ha van virtuális metódusa (mivel így lehet dokumentálni). Magához a GObjecthez használhatjuk a kapcsolódó szakaszok dokumentációit, a példánystruktúrához külön blokkot kell létrehozni, ami akkor hasznos, ha a példánynak nyilvános mezői vannak. Ennek egyik hátránya, hogy ez két azonos nevű indexbejegyzést hoz létre (a struktúra és a szakasz). Felsorolás megjegyzésblokkja Felsorolás megjegyzésblokkja /** * Something: * @SOMETHING_FOO: valamilyen izé * @SOMETHING_BAR: valamilyen bigyó * * A dologhoz használt felsorolásértékek a dolog meghatározásához. */ typedef enum { SOMETHING_FOO, SOMETHING_BAR, /*< private >*/ SOMETHING_COUNT } Something; Használja a /*< private >*/ jelölést azon privát felsorolásértékek előtt, amelyeket el szeretne rejteni. Használja a /*< public >*/ jelölést a fordított viselkedésért. Beágyazott program dokumentációja Dokumentálhat programokat és a parancssori interfészüket beágyazott dokumentáció használatával. Címkék PROGRAM Meghatározza egy program dokumentációjának kezdetét. @short_description: Meghatározza a program rövid leírását (nem kötelező). @synopsis: Meghatározza az argumentumokat vagy az argumentumok listáját, amelyeket a program elfogadhat (nem kötelező). @see_also: Lásd még a kézikönyvoldal szakaszát (nem kötelező). @arg: A programnak átadott argumentumok és leírásaik (nem kötelező). Leírás: A program hosszabb leírása. Returns: Annak megadása, hogy a program milyen értékeket ad vissza (nem kötelező). Példa egy program dokumentációjára. Program dokumentációs blokkja /** * PROGRAM:test-program * @short_description: Egy tesztprogram * @synopsis: test-program [*KAPCSOLÓK*...] --arg1 *arg* *FÁJL* * @see_also: test(1) * @--arg1 *arg*: az arg1 beállítása *arg* értékre * @--arg2 *arg*: az arg2 beállítása *arg* értékre * @-v, --version: A verziószám kiírása * @-h, --help: A súgóüzenet kiírása * * A program hosszú leírása. * * Returns: Siker esetén nulla, sikertelenség esetén nem nulla */ int main(int argc, char *argv[]) { return 0; } Hasznos DocBook-címkék Íme néhány DocBook-címke, amelyek a leghasznosabbak a kód dokumentálásakor. A GTK dokumentációjának egy másik szakaszára való hivatkozáshoz: <link linkend="glib-Hash-Tables">Hasítótáblák</link> A hivatkozás vége az SGML/XML azonosítója annak az oldalnak a legfelső elemén, amelyre hivatkozni kíván. A legtöbb oldal esetében ez jelenleg a („gtk”, „gdk”, „glib”) rész, majd az oldal címe („Hasítótáblák”). A felületi elemek esetében ez csak az osztály neve. A szóközök és az aláhúzások az SGML/XML-nek való megfelelés érdekében „-” karakterre vannak átalakítva. Egy külső függvényre, például egy szabványos C függvényre való hivatkozáshoz: <function>...</function> Példakód beillesztéséhez: <example> <title>Egy GHashTable használata.</title> <programlisting language="C"> ... </programlisting> </example> vagy esetleg ez, a nagyon rövid kódrészletekhez, amelyeknek nincs szükségük címre: <informalexample> <programlisting language="C"> ... </programlisting> </informalexample> Mindkét esetben a language attribútum elhagyható, és a szintaxiskiemelő motornak (pygments a HTML kimenethez) szolgál segítségül. Ez utóbbihoz a GTK-Doc egy rövidítést is támogat: |[<!-- language="C" --> ... ]| Felsorolásos listák beillesztéséhez: <itemizedlist> <listitem> <para> ... </para> </listitem> <listitem> <para> ... </para> </listitem> </itemizedlist> A szövegből kiemelkedő megjegyzés beillesztéséhez: <note> <para> Győződjön meg arról, hogy használat után felszabadította-e az adatokat. </para> </note> Egy típusra való hivatkozáshoz: <type>unsigned char</type> Egy külső (nem a GTK dokumentációban ismertetett) struktúrára való hivatkozáshoz: <structname>XFontStruct</structname> Egy struktúra mezőjére való hivatkozáshoz: <structfield>len</structfield> Egy osztálynévre való hivatkozáshoz esetleg használhatjuk a következőt: <classname>GtkWidget</classname> de valószínűleg a #GtkWidget lesz használva helyette (hogy automatikusan létrehozzon egy hivatkozást a GtkWidget oldalára – nézze meg a rövidítéseket). A szöveg hangsúlyozásához: <emphasis>Ez fontos</emphasis> Fájlnevekhez használja ezt: <filename>/home/user/documents</filename> Billentyűkre való hivatkozáshoz használja ezt: <keycombo><keycap>Control</keycap><keycap>L</keycap></keycombo> A további fájlok kitöltése Van néhány további fájl, amelyeket a forráskód beágyazott megjegyzéseivel együtt kell karbantartani: <csomag>.types, <csomag>-docs.xml (régebben .sgml), <csomag>-sections.txt. A típusok fájl szerkesztése Ha a könyvtár vagy az alkalmazás GObjecteket tartalmaz, akkor a dokumentációban meg szeretné jeleníteni a szignálokat, argumentumokat, paramétereket és a hierarchiában elfoglalt helyüket. Mindössze annyit kell tennie, hogy felsorolja a xxx_get_type függvényeket az include-jaikkal együtt a <csomag>.types fájlon belül. Példa a <csomag>.types-fájlra #include <gtk/gtk.h> gtk_accel_label_get_type gtk_adjustment_get_type gtk_alignment_get_type gtk_arrow_get_type A GTK-Doc 1.8 óta az gtkdoc-scan képes előállítani ezt a listát Önnek. Csak adja hozzá a „--rebuild-types” kapcsolót a SCAN_OPTIONS értékeihez a Makefile.am fájlban. Ha ezt a megközelítést használja, akkor nem kell terjesztenie a típusok fájlt, és nem is kell verziókövetés alatt tartania. A mesterdokumentum szerkesztése A GTK-Doc DocBook SGML/XML formátumú dokumentációt készít. A beágyazott forrásmegjegyzések feldolgozásakor a GTK-Doc eszközei osztályonként vagy modulonként egy dokumentációs oldalt állítanak elő külön fájlként. A mesterdokumentum tartalmazza ezeket, és sorrendbe helyezi őket. Noha a GTK-Doc létrehoz egy sablon mesterdokumentumot Önnek, a későbbi futtatások nem nyúlnak hozzá újra. Ez azt jelenti, hogy szabadon szerkesztheti a dokumentációt. Ez magában foglalja az oldalak csoportosítását és a további oldalak hozzáadását. A GTK-Doc mostantól rendelkezik egy tesztcsomaggal, ahol a mesterdokumentum is újra létrejön a semmiből. Jó ötlet erre időről-időre ránézni és észrevenni, hogy vannak-e újdonságok, amik bevezetésre kerültek. Ne hozzon létre oktatóanyagokat külön dokumentumként. Csak írjon további fejezeteket. A programkönyvtára oktatóanyagának az API-dokumentációba való közvetlen beágyazásának az az előnye, hogy könnyen összekapcsolható az oktatóanyag a szimbólum dokumentációjával. Emellett nagyobb az esélye annak, hogy az oktatóanyag a programkönyvtárral együtt kap frissítéseket. Mik azok a dolgok, amelyeket a mesterdokumentumon belül meg kell változtatni? Kezdetnek csak egy keveset. Van ott néhány helykitöltő (szögletes zárójelben lévő szöveg), amelyekre vigyázni kell. Mesterdokumentum fejléce <bookinfo> <title>MODULENAME hivatkozási kézikönyv</title> <releaseinfo> MODULENAME [VERSION] A dokumentáció legfrissebb változata megtalálható a <ulink role="online-location" url="http://[SERVER]/MODULENAME/index.html">http://[SERVER]/MODULENAME/</ulink> internetes oldalon. </releaseinfo> </bookinfo> <chapter> <title>[Cím beszúrása ide]</title> Ezenkívül néhány választható elem is létrehozásra kerül megjegyzésekkel ellátott formában. Ezeket áttekintheti, és tetszés szerint engedélyezheti. Választható rész a mesterdokumentumban <!-- engedélyezze ezt, ha GObject Introspection megjegyzéseket használ <xi:include href="xml/annotation-glossary.xml"><xi:fallback /></xi:include> --> Végül új szakaszt kell hozzáadni, amikor bevezet egyet. A gtkdoc-check eszköz emlékeztetni fogja az újonnan előállított XML-fájlokra, amelyek még nem szerepelnek a dokumentációban. Előállított szakaszok beágyazása <chapter> <title>Az én programkönyvtáram</title> <xi:include href="xml/object.xml"/> ... A szakaszfájl szerkesztése A szakaszfájl a GTK-Doc által kiírt dokumentáció rendszerezésére szolgál. Itt adhatjuk meg, hogy melyik szimbólum melyik modulhoz vagy osztályhoz tartozik, és szabályozhatjuk a láthatóságot (publikus vagy privát). A szakaszfájl egy egyszerű szöveges fájl, címkékkel elválasztott szakaszokkal. Az üres sorok figyelmen kívül maradnak, és a „#” karakterrel kezdődő sorok megjegyzésként vannak kezelve. Noha a címkék miatt a fájl XML-nek tűnik, nem az. Ne zárja le a címkéket, mint például a <SUBSECTION> címkét. Előállított szakaszok beágyazása <INCLUDE>libmeep/meep.h</INCLUDE> <SECTION> <FILE>meepapp</FILE> <TITLE>MeepApp</TITLE> MeepApp <SUBSECTION Standard> MEEP_APP ... MeepAppClass meep_app_get_type </SECTION> A <FILE> ... </FILE> címke a fájl nevének megadására szolgál, utótag nélkül. Például a „<FILE>gnome-config</FILE>” használata azt eredményezi, hogy a szakaszdeklarációk kiírásra kerülnek a tmpl/gnome-config.sgml sablonfájlban, amely az xml/gnome-config.xml vagy az xml/gnome-config.sgml DocBook XML-fájlra lesz átalakítva. (A HTML-fájl neve a modul nevén és a szakasz címén alapul, vagy GObjectek esetén a GObjectek osztálynevén alapul kisbetűssé alakítva). A <TITLE> ... </TITLE> címke a szakasz címének megadására szolgál. Ez csak a sablonok (ha használjuk) kezdeti létrehozása előtt hasznos, mivel a sablonfájlban beállított cím felülírja ezt. Ha valaki a forrásokban is használja a SECTION megjegyzést, akkor ez elavult. Csoportosíthatja a szakaszban lévő elemeket a <SUBSECTION> címke használatával. Jelenleg üres sort ír ki az alfejezetek között az összefoglaló szakaszban. Használhatja a <SUBSECTION Standard> címkét is a szabványos GObject deklarációkhoz (például az olyan függvényekhez, mint a g_object_get_type és az olyan makrókhoz, mint a G_OBJECT(), G_IS_OBJECT() stb.). Jelenleg ezek kimaradnak a dokumentációból. Használhatja a <SUBSECTION Private> címkét is a privát deklarációkhoz, amelyek nem kerülnek kiírásra (ez egy praktikus módja annak, hogy elkerülje a nem használt deklarációkról szóló figyelmeztető üzeneteket). Ha a programkönyvtára olyan privát típusokat tartalmaz, amelyeket nem szeretne, hogy megjelenjenek az objektumhierarchiában és a megvalósított vagy szükséges interfészek listájában, adja őket egy Private alszakaszhoz. A GObject és GObjectClass típusú struktúrák publikus vagy a Standard szakaszba helyezése attól függ, hogy vannak-e publikus bejegyzéseik (változók, virtuális metódusok). Használhatja az <INCLUDE> ... </INCLUDE> jelölést is az #include fájlok megadásához, amelyek az összefoglaló szakaszokban jelennek meg. Az #include fájlok vesszővel elválasztott listáját tartalmazza, szögletes zárójelek nélkül. Ha bármelyik szakaszon kívül állítja be, akkor a fájl végéig az összes szakaszra vonatkozik. Ha egy szakaszon belül állítja be, akkor csak arra a szakaszra vonatkozik. Az eredmény ellenőrzése A GTK-Doc futtatása jelentésfájlokat állít elő a dokumentációs könyvtáron belül. Az előállított fájlok neve: <csomag>-undocumented.txt, <csomag>-undeclared.txt és <csomag>-unused.txt. Ezek mind egyszerű szöveges fájlok, amelyek könnyen megtekinthetők és utólagosan feldolgozhatók. A <csomag>-undocumented.txt fájl a dokumentáció lefedettségének összefoglalójával kezdődik. Alatta két, üres sorokkal elválasztott szakasz található. Az első szakasz a dokumentálatlan vagy hiányos szimbólumokat sorolja fel. A második szakasz ugyanezt teszi a szakaszok dokumentációira. A hiányos bejegyzések azok, amelyeknek van dokumentációja, de ahol például új paraméter került hozzáadásra. A <csomag>-undeclared.txt fájl a <csomag>-sections.txt fájlban megadott, de a forrásokban nem található szimbólumokat sorolja fel. Ellenőrizze, hogy nem kerültek-e eltávolításra, vagy nincsenek-e hibásan írva. A <csomag>-unused.txt fájl azokat a szimbólumneveket sorolja fel, ahol a GTK-Doc átvizsgáló talált dokumentációt, de nem tudja, hova tegye azt. Ez azt jelenti, hogy a szimbólum még nem lett hozzáadva a <csomag>-sections.txt fájlhoz. Engedélyezze vagy adja hozzá a sort a Makefile.am fájlhoz. Ha legalább GTK-Doc 1.9 van telepítve, akkor ez józansági ellenőrzéseket futtat a make check futtatása során. A forráskód-átvizsgáló által előállított fájlokat is megnézhetjük: <csomag>-decl-list.txt és <csomag>-decl.txt. Az elsőt össze lehet hasonlítani a szakaszfájllal, ha az kézzel van karbantartva. A második a fejlécekből származó összes deklarációt sorolja fel. Ha egy szimbólum hiányzik, akkor ellenőrizhetjük, hogy ez a fájl tartalmazza-e. Ha a projekt GObject-alapú, akkor az objektum-átvizsgáló által előállított fájlokat is megnézhetjük: <csomag>.args.txt, <csomag>.hierarchy.txt, <csomag>.interfaces.txt, <csomag>.prerequisites.txt és <csomag>.signals.txt. Ha ezek bármelyikéből hiányoznak szimbólumok, akkor a GTK_DOC_KEEP_INTERMEDIATE=1 make futtatásával megkérhetjük a GTK-Doc eszközt arra, hogy tartsa meg a köztes átvizsgálási fájlt a további elemzéshez. A dokumentáció korszerűsítése A GTK-Doc már jó ideje létezik. Ebben a részben felsoroljuk az új funkciókat a verzióval együtt, amióta elérhetők. GTK-Doc 1.9 Ha SGML helyett XML-t használunk, a mesterdokumentumot <csomag>-docs.xml néven is elnevezhetjük. Ez a verzió támogatja a kapcsolót a Makefile.am fájlban. Ha ez engedélyezve van, akkor a <csomag>-sections.txt fájl automatikusan előállításra kerül, és eltávolítható a verziókövető rendszerből. Ez csak olyan projekteknél működik jól, amelyek rendkívül szabályos szerkezettel rendelkeznek (például minden .{c,h} pár új szakaszt hoz létre). Ha valaki egy ehhez közeli projektet szervez, egy kézzel karbantartott szakaszfájl frissítése olyan egyszerű lehet, mint a meld <csomag>-decl-list.txt <csomag>-sections.txt kód futtatása. Az 1.8-as verzió már bevezette a szintaxist a szakaszok forrásokban történő dokumentálásához a tmpl alatti különálló fájlok helyett. Ez a verzió olyan kapcsolókat ad hozzá, amelyekkel az egész dokumentációs modult át lehet kapcsolni úgy, hogy egyáltalán ne használja a további sablon-összeállítási lépést. Ehhez a kapcsolót kell használni a configure.ac fájlban. Ha még nincs tmpl könyvtár lekérve a forráskövető rendszerében, és még nem lett átváltva, akkor csak adja hozzá a jelzőt a configure.ac fájlhoz, és már kész is van. GTK-Doc 1.10 Ez a verzió támogatja a kapcsolót a Makefile.am fájlban. Ha ez engedélyezve van, akkor a <csomag>.types fájl automatikusan előállításra kerül, és eltávolítható a verziókövető rendszerből. A funkció használatakor fontos, hogy az IGNORE_HFILES is be legyen állítva a Makefile.am fájlban a feltételesen összeállított kódhoz. GTK-Doc 1.16 Ez a verzió egy új, gtkdoc-check nevű eszközt tartalmaz. Ez az eszköz képes lefuttatni egy sor józansági ellenőrzést a dokumentáción. Az engedélyezéshez hozzá kell adni ezeket a sorokat a Makefile.am fájl végéhez. A gtkdoc-check engedélyezése if ENABLE_GTK_DOC TESTS_ENVIRONMENT = \ DOC_MODULE=$(DOC_MODULE) DOC_MAIN_SGML_FILE=$(DOC_MAIN_SGML_FILE) \ SRCDIR=$(abs_srcdir) BUILDDIR=$(abs_builddir) TESTS = $(GTKDOC_CHECK) endif GTK-Doc 1.20 Az 1.18-as verzió hozott némi kezdeti Markdown-támogatást. A Markdown használata a dokumentációs megjegyzésekben kevésbé tolakodó, mint a DocBook XML írása. Ez a verzió sokat javít ezen, és sokkal több stílust ad hozzá. A megjegyzés szintaxisát magyarázó szakasz minden részletet tartalmaz. GTK-Doc 1.25 Az ezzel a verzióval szállított makefile-ok létrehoznak egy entitásfájlt az xml/gtkdocentities.ent fájlban, amely például a package_name és package_version entitásokat tartalmazza. Ezt használhatja például a fő XML-fájlban, hogy elkerülje a verziószám kézi megadását. Az alábbiakban egy példa azt mutatja be, hogy az entitásfájl hogyan kerül a mestersablonba, és hogyan kell használni az entitásokat. Az entitások az összes előállított fájlban is használhatók, a GTK-Doc ugyanazt az XML-fejlécet fogja használni az előállított XML-fájlokban. Előre előállított entitások használata <?xml version="1.0"?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ <!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'"> <!ENTITY % gtkdocentities SYSTEM "xml/gtkdocentities.ent"> %gtkdocentities; ]> <book id="index" xmlns:xi="http://www.w3.org/2003/XInclude"> <bookinfo> <title>&package_name; hivatkozási kézikönyv</title> <releaseinfo> for &package_string;. A dokumentáció legfrissebb változata megtalálható a <ulink role="online-location" url="http://[SERVER]/&package_name;/index.html">http://[SERVER]/&package_name;/</ulink> internetes oldalon. </releaseinfo> </bookinfo> Egyéb interfészek dokumentálása Eddig a GTK-Doc eszközt használtuk a kód API-jának dokumentálásához. A következő szakaszok javaslatokat tartalmaznak arra vonatkozóan, hogy az eszközök hogyan használhatók egyéb interfészek dokumentálásához is. Parancssori kapcsolók és kézikönyvoldalak Mivel kézikönyvoldalakat is elő lehet állítani egy DocBook-hivatkozási bejegyzéshez, jó ötletnek tűnik, hogy erre a célra használjuk. Így az interfész a hivatkozás része lesz, a kézikönyvoldalt pedig ingyen megkapjuk. Az eszköz dokumentálása Hozzon létre eszközönként egy hivatkozásibejegyzés-fájlt. A példánkat követve elnevezhetjük meep/docs/reference/meeper/meep.xml néven. A használandó XML-címkék megtekinthetők az XML alkönyvtárban lévő előállított fájlban, valamint példák is találhatók például a glib csomagban. A további beállítás-ellenőrzés hozzáadása További beállítás-ellenőrzések AC_ARG_ENABLE(man, [AC_HELP_STRING([--enable-man], [regenerate man pages from Docbook [default=no]])],enable_man=yes, enable_man=no) AC_PATH_PROG([XSLTPROC], [xsltproc]) AM_CONDITIONAL(ENABLE_MAN, test x$enable_man != xno) A további makefile-szabályok hozzáadása További beállítás-ellenőrzések man_MANS = \ meeper.1 if ENABLE_GTK_DOC if ENABLE_MAN %.1 : %.xml @XSLTPROC@ -nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $< endif endif BUILT_EXTRA_DIST = $(man_MANS) EXTRA_DIST += meep.xml DBus interfészek (JAVÍTS KI: http://hal.freedesktop.org/docs/DeviceKit/DeviceKit.html, http://cgit.freedesktop.org/DeviceKit/DeviceKit/tree/doc/dbus) Gyakran ismételt kérdések Kérdés Válasz Nincs osztályhierarchia. Az objektumok xxx_get_type() függvénye nem került be a <csomag>.types fájlba. Még mindig nincs osztályhierarchia. Hiányzó vagy hibás elnevezés a <csomag>-sections.txt fájlban (nézze meg a magyarázatot). A fenébe, még mindig nincs osztályhierarchiám. Az objektum neve (a példánystruktúra neve, például GtkWidget) a normál szakasz része (ne tegye ezt a Standard vagy Private alszakaszokba)? Nincs szimbólumindex. A <csomag>-docs.{xml,sgml} tartalmaz olyan indexet, amely xi:include-olja az előállított indexet? A szimbólumok nem kapcsolódnak a dokumentumszakaszukhoz. A doc-comment a megfelelő jelölést használja (hozzáadott #, % vagy () jelölőket)? Ellenőrizze, hogy a gtkdoc-fixxref figyelmeztet-e a nem feloldható xref-ekre. Egy új osztály nem jelenik meg a dokumentációban. Az új oldal xi:include-olva van a <csomag>-docs.{xml,sgml} fájlból? Egy új szimbólum nem jelenik meg a dokumentációban. Megfelelően van formázva a doc-comment tulajdonság? Ellenőrizze, hogy nincsenek-e helyesírási hibák a megjegyzés elején. Ellenőrizze, hogy a gtkdoc-fixxref figyelmeztet-e a feloldhatatlan xref-ekre. Ellenőrizze, hogy a szimbólum helyesen van-e felsorolva a <csomag>-sections.txt fájl egy nyilvános alszakaszában. Egy típus hiányzik az osztályhierarchiából. Ha a típus fel van sorolva a <csomag>.hierarchy fájlban, de nincs az xml/tree_index.sgml fájlban, akkor ellenőrizze kétszer is, hogy a típus helyesen van-e elhelyezve a <csomag>-sections.txt fájlban. Ha a típuspéldány (például GtkWidget) nincs felsorolva vagy véletlenül privátként van megjelölve, akkor nem fog megjelenni. Az összes gobject megjegyzéshez foldoc hivatkozásokat kapok. Ellenőrizze, hogy az xml/annotation-glossary.xml fájl xi:include-olva van-e a <csomag>-docs.{xml,sgml} fájlból. A paraméter le van írva a forráskód megjegyzésblokkjában, de nem létezik Ellenőrizze, hogy a fejlécben lévő prototípusnak más paraméternevei vannak-e, mint a forrásban. Több „azonosító” a korlátozó hivatkozásvéghez: XYZ Az XYZ szimbólum kétszer jelenik meg a <csomag>-sections.txt fájlban. A „” névtérben lévő típusnév elem megtalálható a bekezdésben, de nincs megfelelő sablon. A GTK-Doc kapcsolódó eszközei GtkDocPlugin – egy Trac GTK-Doc integrációs bővítmény, amely API-dokumentációkat ad egy trac oldalhoz, és integrálódik a trac keresővel. Gtkdoc-depscan – egy eszköz (a GTK-Doc része), amely ellenőrzi a használt API-t, hogy mióta vannak a címkék az API-ban, hogy meghatározza a minimálisan szükséges verziót. 1.1-es verzió, 2000. március 2000Free Software Foundation, Inc.
Free Software Foundation, Inc. 51 Franklin Street, Suite 330, Boston, MA 02110-1301 USA
A jelen licencdokumentumot bárki szabadon lemásolhatja és a pontos másolatait terjesztheti, de a módosítása tilos. GNU Free Documentation License (nem hivatalos magyar fordítás) 0. ELŐSZÓ The purpose of this License is to make a manual, textbook, or other written document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. A jelen Licenc a szabad szoftverek kézikönyveihez való használatra készült, hiszen a szabad szoftver egyben szabad dokumentációt is igényel: egy szabad programot olyan kézikönyvvel kell ellátni, amely ugyanazon szabadságokat biztosítja, mint maga a program. Mindazonáltal a jelen Licenc nem korlátozódik pusztán kézikönyvekre; feltételei tetszőleges tárgykörű írott dokumentumra alkalmazhatók, függetlenül attól, hogy az könyvformában valaha megjelent-e. Mindamellett e Licencet főként olyan munkákhoz ajánljuk, melyek elsődleges célja az útmutatás vagy a tájékoztatás. 1. ALKALMAZHATÓSÁG ÉS DEFINÍCIÓK This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. A Modified Version of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A Secondary Section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The Invariant Sections are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not Transparent is called Opaque. Az Átlátszóság kritériumainak megfelelő formátumok között megtalálható például a jelölőnyelvet nem használó egyszerű ASCII, a Texinfo beviteli formátum, a LaTeX beviteli formátum, az SGML vagy az XML egy általánosan hozzáférhető DTD használatával, és a szabványnak megfelelő, emberi módosításra tervezett egyszerű HTML. Az Átlátszatlan formátumok közé sorolhatóak a PostScript, a PDF, a szellemi tulajdont képező formátumok, amelyeket csak szellemi tulajdont képező szövegszerkesztőkkel lehet elolvasni, az olyan SGML vagy XML, amelyhez a szükséges DTD és/vagy egyéb feldolgozó eszközök nem általánosan hozzáférhetők, és az olyan gépileg generált HTML formátum, amely kizárólag egyes szövegszerkesztők kimeneti formátumaként áll elő. The Title Page means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Page means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. 2. SZÓ SZERINTI SOKSZOROSÍTÁS You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. A fenti feltételeket betartva kölcsönözhet is példányokat, de akár nyilvánosan is közzéteheti a szöveget. 3. SOKSZOROSÍTÁS NAGYOBB MENNYISÉGBEN If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. Abban az esetben, ha a borítólapok bármelyikén megkövetelt szövegrészek túl hosszúnak bizonyulnának az olvasható közzétételhez, úgy csak az elsőként felsoroltakat kell feltüntetnie (amennyi józan belátás szerint elfér) a tényleges borítón, a továbbiak pedig átkerülhetnek a következő oldalakra. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MÓDOSÍTÁSOK You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C State on the Title Page the name of the publisher of the Modified Version, as the publisher. D Preserve all the copyright notices of the Document. E Saját módosításaira vonatkozóan is tegyen közzé egy szerzői jogi megjegyzést, a többi ilyen jellegű figyelmeztetés mellett. F Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H Mellékelje a jelen Licenc egy eredeti példányát. I Preserve the section entitled History, and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled History in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the History section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K In any section entitled Acknowledgements or Dedications, preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M Delete any section entitled Endorsements. Such a section may not be included in the Modified Version. N Do not retitle any existing section as Endorsements or to conflict in title with any Invariant Section. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section entitled Endorsements, provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version . 5. KOMBINÁLT DOKUMENTUMOK You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled History in the various original documents, forming one section entitled History; likewise combine any sections entitled Acknowledgements, and any sections entitled Dedications. You must delete all sections entitled Endorsements. 6. DOKUMENTUMGYŰJTEMÉNYEK You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. Tetszése szerint ki is emelhet egy meghatározott dokumentumot a gyűjteményből, továbbá terjesztheti azt jelen Licenc feltételei alapján, feltéve, hogy a szóban forgó dokumentumhoz mellékeli a jelen Licenc egy példányát, és minden egyéb tekintetben betartja jelen Licenc előírásait a dokumentum szó szerinti sokszorosítására vonatkozóan. 7. ÖSSZEFŰZÉS FÜGGETLEN MUNKÁKKAL A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an aggregate, and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. 8. FORDÍTÁS Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. 9. MEGSZŰNÉS You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. JELEN LICENC JÖVŐBENI JAVÍTÁSAI The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License or any later version applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. Függelék Ha a jelen Licencet egy Ön által írt dokumentumban kívánja használni, akkor mellékelje hozzá a Licenc egy példányát, továbbá vezesse rá az alábbi szerzői jogi és licencközleményeket, rögtön a címlapot követően:
Copyright (C) ÉV AZ ÖN NEVE. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled GNU Free Documentation License.
If you have no Invariant Sections, write with no Invariant Sections instead of saying which ones are invariant. If you have no Front-Cover Texts, write no Front-Cover Texts instead of Front-Cover Texts being LIST; likewise for Back-Cover Texts. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.