'\" t .\" Man page generated from reStructuredText .\" by the Docutils 0.23 manpage writer. . . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .TH "gdbus-codegen" "1" "" "" "دستورات کاربر" .SH "نام (NAME)" gdbus-codegen \- تولیدکننده کدهای C و مستندات D-Bus .\" This has to be duplicated from above to make it machine-readable by `reuse`: .\" SPDX-FileCopyrightText: 2011, 2013, 2016 Red Hat, Inc. .\" SPDX-FileCopyrightText: 2013, 2022 Emmanuele Bassi .\" SPDX-FileCopyrightText: 2017 Patrick Griffis .\" SPDX-FileCopyrightText: 2018 Iñigo Martínez .\" SPDX-FileCopyrightText: 2018, 2019 Endless Mobile, Inc. .\" SPDX-FileCopyrightText: 2020 Endless OS Foundation, LLC .\" SPDX-FileCopyrightText: 2020 Chun-wei Fan .\" SPDX-License-Identifier: LGPL-2.1-or-later . .SH "خلاصه دستور (SYNOPSIS)" .nf \fBgdbus\-codegen\fP .in +2 [\-\-help] [\-\-interface\-prefix \fIorg.project.Prefix\fP] [\-\-header | \-\-body | \-\-interface\-info\-header | \-\-interface\-info\-body | \-\-generate\-c\-code \fIOUTFILES\fP] [\-\-c\-namespace \fIYourProject\fP] [\-\-c\-generate\-object\-manager] [\-\-c\-generate\-autocleanup none|objects|all] [\-\-output\-directory \fIOUTDIR\fP | \-\-output \fIOUTFILE\fP] [\-\-generate\-docbook \fIOUTFILES\fP] [\-\-generate\-md \fIOUTFILES\fP] [\-\-generate\-rst \fIOUTFILES\fP] [\-\-pragma\-once] [\-\-xml\-files \fIFILE\fP] [\-\-symbol\-decorator \fIDECORATOR\fP [\-\-symbol\-decorator\-header \fIHEADER\fP] [\-\-symbol\-decorator\-define \fIDEFINE\fP]] [\-\-annotate \fIELEMENT\fP \fIKEY\fP \fIVALUE\fP]… [\-\-glib\-min\-required \fIVERSION\fP] [\-\-glib\-max\-allowed \fIVERSION\fP] [\-\-extension\-path \fIEXTENSION_PATH\fP] \fIFILE\fP… .in -2 .fi .sp .SH "توضیحات (DESCRIPTION)" .sp دستور \fBgdbus\-codegen\fP برای تولید کد و/یا مستندات برای یک یا چند رابط گذرگاه D\-Bus به کار می‌رود. .sp دستور \fBgdbus\-codegen\fP پرونده‌های XML درون‌نگری گذرگاه D\-Bus \% را از پرونده‌هایی که به عنوان آرگومان‌های خط فرمان ارسال شده‌اند می‌خواند و پرونده‌های خروجی را تولید می‌کند. در حال حاضر از تولید کد مبدأ C (از طریق \fB\-\-body\fP) یا سرایند (از طریق \fB\-\-header\fP) و DocBook XML (از طریق \fB\-\-generate\-docbook\fP) پشتیبانی می‌کند. همچنین می‌توان کدهای مبدأ و سرایندهای C محدودتری تولید کرد که فقط حاوی اطلاعات رابط (به عنوان ساختارهای \fBGDBusInterfaceInfo\fP) باشند که با استفاده از گزینه‌های \fB\-\-interface\-info\-body\fP و \fB\-\-interface\-info\-header\fP انجام می‌شود. .SH "تولید کد C (GENERATING C CODE)" .sp هنگام تولید کد C، یک نوع مشتق‌شده از \fBGInterface\fP برای هر رابط D\-Bus تولید می‌شود. علاوه بر این، به ازای هر نوع تولیدشده، \fBFooBar\fP، دو نوع ملموس و قابل نمونه‌سازی با نام‌های \fBFooBarProxy\fP و \fBFooBarSkeleton\fP که رابط مذکور را پیاده‌سازی می‌کنند نیز تولید می‌شوند. نوع اول از \fBGDBusProxy\fP مشتق شده و برای استفاده در سمت کلاینت در نظر گرفته شده است، در حالی که نوع دوم از نوع \fBGDBusInterfaceSkeleton\fP مشتق شده و برون‌ریزی (export) آن را روی یک \fBGDBusConnection\fP چه مستقیماً و چه از طریق یک نمونه از \fBGDBusObjectManagerServer\fP آسان می‌سازد. .sp برای تولید کد C می‌توان از \fB\-\-body\fP (تولید کد مبدأ)، \fB\-\-header\fP (تولید سرایندها)، \fB\-\-interface\-info\-body\fP (تولید کد مبدأ اطلاعات رابط)، یا \fB\-\-interface\-info\-header\fP (تولید سرایندهای اطلاعات رابط) استفاده کرد. این گزینه‌ها باید همراه با \fB\-\-output\fP استفاده شوند، که برای تعیین پرونده خروجی به کار می‌رود. .sp هر دو پرونده را می‌توان به طور همزمان با استفاده از \fB\-\-generate\-c\-code\fP تولید کرد، اما این گزینه منسوخ شده است. در این حالت به دلیل تولید چند پرونده نمی‌توان از \fB\-\-output\fP استفاده کرد؛ در عوض باید گزینه \fB\-\-output\-directory\fP را برای مشخص کردن پوشه/دایرکتوری خروجی مشخص کنید. به صورت پیشفرض پوشه فعلی استفاده خواهد شد. .sp نام هر نوع C تولیدشده از نام رابط D\-Bus با حذف پیشوند ارائه‌شده توسط \fB\-\-interface\-prefix\fP، حذف نقطه‌ها و بزرگ نوشتن حروف اول مشتق می‌شود. برای نمونه، برای رابط D\-Bus با عنوان \fBcom.acme.Coyote\fP، نام استفاده‌شده \fBComAcmeCoyote\fP خواهد بود. برای رابط D\-Bus با عنوان \fBorg.project.Bar.Frobnicator\fP که مقدار \fB\-\-interface\-prefix\fP بر روی \fBorg.project.\fP تنظیم شده است، نام استفاده‌شده \fBBarFrobnicator\fP خواهد بود. .sp برای متدها، سیگنال‌ها و ویژگی‌ها، در صورت مشخص نشدن، نام به صورت پیشفرض به نام همان متد، سیگنال یا ویژگی درمی‌آید. .sp دو شکل از نام استفاده می‌شود — شکل CamelCase و شکل حروف کوچک (lower-case). شکل CamelCase برای نام‌های \fBGType\fP و ساختار به کار می‌رود، در حالی که شکل حروف کوچک در نام توابع به کار گرفته می‌شود. شکل حروف کوچک با تبدیل از CamelCase به حروف کوچک و درج خط زیر (underscore) در مرز کلمات (با استفاده از اصول هیوریستیک خاص) به دست می‌آید. .sp اگر مقدار ارائه‌شده توسط یادداشت \fBorg.gtk.GDBus.C.Name\fP یا گزینه \fB\-\-c\-namespace\fP حاوی یک خط زیر باشد (که گاهی \fIUgly_Case\fP نامیده می‌شود)، نام camel-case با حذف تمام خط‌های زیر، و نام حروف کوچک با تبدیل کل رشته به حروف کوچک به دست می‌آید. این موضوع در برخی موارد که از کوته‌نوشت‌ها استفاده می‌شود مفید است. برای نمونه، اگر این یادداشت بر روی رابط \fBnet.MyCorp.MyApp.iSCSITarget\fP با مقدار \fBiSCSI_Target\fP استفاده شود، شکل CamelCase آن \fBiSCSITarget\fP خواهد بود، در حالی که شکل حروف کوچک آن \fBiscsi_target\fP است. اگر یادداشت روی متد \fBEjectTheiPod\fP با مقدار \fBEject_The_iPod\fP استفاده شود، شکل حروف کوچک \fBeject_the_ipod\fP خواهد بود. .SH "تولید مستندات DOCBOOK (GENERATING DOCBOOK DOCUMENTATION)" .sp هر پرونده DocBook XML تولیدشده (برای جزئیات به گزینه \fB\-\-generate\-docbook\fP نگاه کنید) یک مقاله \fBRefEntry\fP است که رابط D\-Bus را توصیف می‌کند. (مستندات DocBook در \% را ببینید.) .SH "تولید مستندات MARKDOWN (GENERATING MARKDOWN DOCUMENTATION)" .sp هر پرونده Markdown تولیدشده (برای جزئیات به گزینه \fB\-\-generate\-md\fP نگاه کنید) یک سند متنی ساده مارک‌داون است که رابط D\-Bus را شرح می‌دهد. .SH "تولید مستندات RESTRUCTUREDTEXT (GENERATING RESTRUCTUREDTEXT DOCUMENTATION)" .sp هر پرونده reStructuredText تولیدشده (برای جزئیات به گزینه \fB\-\-generate\-rst\fP نگاه کنید) یک سند متنی ساده reStructuredText \% است که رابط D\-Bus را شرح می‌دهد. .SH "گزینهها (OPTIONS)" .sp گزینه‌های زیر پشتیبانی می‌شوند: .sp \fB\-h\fP, \fB\-\-help\fP .INDENT 0.0 .INDENT 3.5 نمایش پیام راهنما و خروج. .UNINDENT .UNINDENT .sp \fB\-\-xml\-files\fP \fIFILE\fP .INDENT 0.0 .INDENT 3.5 این گزینه منسوخ شده است؛ به جای آن از آرگومان‌های مکانی استفاده کنید. پرونده XML درون‌نگری D\-Bus. .UNINDENT .UNINDENT .sp \fB\-\-interface\-prefix\fP \fIorg.project.Prefix.\fP .INDENT 0.0 .INDENT 3.5 پیشوندی که باید هنگام محاسبه نام نوع برای پیوند C و ویژگی \fBsortas\fP در DocBook \% از ابتدای تمام نام‌های رابط D\-Bus حذف شود. .UNINDENT .UNINDENT .sp \fB\-\-generate\-docbook\fP \fIOUTFILES\fP .INDENT 0.0 .INDENT 3.5 تولید مستندات DocBook برای هر رابط D\-Bus و قرار دادن آن در \fBOUTFILES\-NAME.xml\fP که در آن \fBNAME\fP جایگاهی برای نام رابط است، مانند \fBnet.Corp.FooBar\fP و غیره. .sp برای تعیین پوشه/دایرکتوری قرارگیری پرونده‌های خروجی، گزینه \fB\-\-output\-directory\fP را پاس دهید. به صورت پیشفرض از پوشه فعلی استفاده خواهد شد. .UNINDENT .UNINDENT .sp \fB\-\-generate\-md\fP \fIOUTFILES\fP .INDENT 0.0 .INDENT 3.5 تولید مستندات مارک‌داون برای هر رابط D\-Bus و قرار دادن آن در \fBOUTFILES\-NAME.md\fP که در آن \fBNAME\fP جایگاهی برای نام رابط است، مانند \fBnet.Corp.FooBar\fP و غیره. .sp برای تعیین پوشه/دایرکتوری قرارگیری پرونده‌های خروجی، گزینه \fB\-\-output\-directory\fP را پاس دهید. به صورت پیشفرض از پوشه فعلی استفاده خواهد شد. .UNINDENT .UNINDENT .sp \fB\-\-generate\-rst\fP \fIOUTFILES\fP .INDENT 0.0 .INDENT 3.5 تولید مستندات reStructuredText برای هر رابط D\-Bus و قرار دادن آن در \fBOUTFILES\-NAME.rst\fP که در آن \fBNAME\fP جایگاهی برای نام رابط است، مانند \fBnet.Corp.FooBar\fP و غیره. .sp برای تعیین پوشه/دایرکتوری قرارگیری پرونده‌های خروجی، گزینه \fB\-\-output\-directory\fP را پاس دهید. به صورت پیشفرض از پوشه فعلی استفاده خواهد شد. .UNINDENT .UNINDENT .sp \fB\-\-generate\-c\-code\fP \fIOUTFILES\fP .INDENT 0.0 .INDENT 3.5 تولید کد C برای تمام رابط‌های D\-Bus و قرار دادن آن در \fBOUTFILES.c\fP و \fBOUTFILES.h\fP شامل هرگونه زیرپوشه. اگر می‌خواهید پرونده‌ها در مکان متفاوتی قرار گیرند از \fB\-\-output\-directory\fP استفاده کنید زیرا به \fBOUTFILES.h\fP (شامل زیرپوشه‌ها) از درون \fBOUTFILES.c\fP ارجاع داده خواهد شد. .sp مسیرهای کامل در این صورت عبارت خواهند بود از: \fB$(OUTDIR)/$(dirname $OUTFILES)/$(basename $OUTFILES).{c,h}\fP\&. .UNINDENT .UNINDENT .sp \fB\-\-c\-namespace\fP \fIYourProject\fP .INDENT 0.0 .INDENT 3.5 فضای نام (Namespace) مورد استفاده برای کدهای C تولیدشده. انتظار می‌رود این مقدار به قالب CamelCase \% یا \fIUgly_Case\fP (توضیح داده شده در بالا) باشد. .UNINDENT .UNINDENT .sp \fB\-\-pragma\-once\fP .INDENT 0.0 .INDENT 3.5 در صورت ارسال این گزینه، دستور پیش‌پردازنده #pragma once \% به جای محافظ‌های شمول (include guards) استفاده می‌شود. .UNINDENT .UNINDENT .sp \fB\-\-c\-generate\-object\-manager\fP .INDENT 0.0 .INDENT 3.5 در صورت ارسال این گزینه، زیرکلاس‌های مناسب از \fBGDBusObject\fP، \fBGDBusObjectProxy\fP، \fBGDBusObjectSkeleton\fP و \fBGDBusObjectManagerClient\fP تولید می‌شوند. .UNINDENT .UNINDENT .sp \fB\-\-c\-generate\-autocleanup\fP none|objects|all .INDENT 0.0 .INDENT 3.5 این گزینه تعیین می‌کند که توابع پاکسازی خودکار (autocleanup) برای چه انواعی تولید شوند. مقدار \fBnone\fP به معنای عدم تولید هیچ تابع پاکسازی خودکار است؛ \fBobjects\fP به معنای تولید آن‌ها برای انواع اشیاء (object types) است و \fBall\fP به معنای تولید آن‌ها برای هم انواع اشیاء و هم رابط‌ها است. مقدار پیشفرض به دلیل سازگاری با موارد خاص در پروژه‌های قدیمی \fBobjects\fP است، اما بهتر است پروژه خود را به استفاده از \fBall\fP تغییر دهید. این گزینه در GLib 2.50 اضافه شد. .UNINDENT .UNINDENT .sp \fB\-\-output\-directory\fP \fIOUTDIR\fP .INDENT 0.0 .INDENT 3.5 پوشه/دایرکتوری خروجی کدهای مبدأ تولیدشده. معادل تغییر پوشه قبل از شروع تولید کد است. .sp این گزینه را نمی‌توان همراه با \fB\-\-body\fP، \fB\-\-header\fP، \fB\-\-interface\-info\-body\fP یا \fB\-\-interface\-info\-header\fP استفاده کرد؛ در این موارد باید از \fB\-\-output\fP استفاده شود. .UNINDENT .UNINDENT .sp \fB\-\-header\fP .INDENT 0.0 .INDENT 3.5 اگر این گزینه داده شود، کد سرایند را تولید کرده و با استفاده از مسیر و نام پرونده مشخص‌شده توسط \fB\-\-output\fP روی دیسک می‌نویسد. .sp استفاده از \fB\-\-generate\-c\-code\fP، \fB\-\-generate\-docbook\fP یا \fB\-\-output\-directory\fP همراه با گزینه‌های \fB\-\-header\fP و \fB\-\-body\fP مجاز نیست، زیرا این گزینه‌ها فقط برای تولید یک پرونده واحد استفاده می‌شوند. .UNINDENT .UNINDENT .sp \fB\-\-body\fP .INDENT 0.0 .INDENT 3.5 اگر این گزینه داده شود، کد مبدأ را تولید کرده و با استفاده از مسیر و نام پرونده مشخص‌شده توسط \fB\-\-output\fP روی دیسک می‌نویسد. .sp استفاده از \fB\-\-generate\-c\-code\fP، \fB\-\-generate\-docbook\fP یا \fB\-\-output\-directory\fP همراه با گزینه‌های \fB\-\-header\fP و \fB\-\-body\fP مجاز نیست، زیرا این گزینه‌ها فقط برای تولید یک پرونده واحد استفاده می‌شوند. .UNINDENT .UNINDENT .sp \fB\-\-interface\-info\-header\fP .INDENT 0.0 .INDENT 3.5 اگر این گزینه داده شود، کد سرایند را فقط برای ساختارهای \fBGDBusInterfaceInfo\fP تولید کرده و با استفاده از مسیر و نام پرونده ارائه‌شده توسط \fB\-\-output\fP بر روی دیسک ذخیره می‌کند. .sp استفاده از \fB\-\-generate\-c\-code\fP، \fB\-\-generate\-docbook\fP یا \fB\-\-output\-directory\fP همراه با گزینه‌های \fB\-\-interface\-info\-header\fP و \fB\-\-interface\-info\-body\fP مجاز نیست، زیرا این گزینه‌ها برای تولید تنها یک پرونده استفاده می‌شوند. .UNINDENT .UNINDENT .sp \fB\-\-interface\-info\-body\fP .INDENT 0.0 .INDENT 3.5 اگر این گزینه داده شود، کد مبدأ را فقط برای ساختارهای \fBGDBusInterfaceInfo\fP تولید کرده و با استفاده از مسیر و نام پرونده ارائه‌شده توسط \fB\-\-output\fP بر روی دیسک ذخیره می‌کند. .sp استفاده از \fB\-\-generate\-c\-code\fP، \fB\-\-generate\-docbook\fP یا \fB\-\-output\-directory\fP همراه با گزینه‌های \fB\-\-interface\-info\-header\fP و \fB\-\-interface\-info\-body\fP مجاز نیست، زیرا این گزینه‌ها برای تولید تنها یک پرونده استفاده می‌شوند. .UNINDENT .UNINDENT .sp \fB\-\-symbol\-decorator\fP \fIDECORATOR\fP .INDENT 0.0 .INDENT 3.5 چنانچه یک \fBDECORATOR\fP با این گزینه مشخص شود، تمامی پیش‌نمونه‌های توابع تولیدشده در سرایند با \fBDECORATOR\fP نشانه‌گذاری خواهند شد. این کار برای مثال جهت برون‌ریزی (export) نمادها از کدهای تولیدشده با \fBgdbus\-codegen\fP کاربرد دارد. .sp این گزینه در GLib 2.66 اضافه شد. .UNINDENT .UNINDENT .sp \fB\-\-symbol\-decorator\-header\fP \fIHEADER\fP .INDENT 0.0 .INDENT 3.5 چنانچه یک \fBHEADER\fP با این گزینه مشخص شود، سرایند تولیدشده یک عبارت \fB#include HEADER\fP را قبل از بقیه موارد (به جز محافظ‌های شمول یا \fB#pragma once\fP در صورت استفاده از \fB\-\-pragma\-once\fP) قرار خواهد داد. این حالت زمانی کاربرد دارد که برای تعریف دکوراتور مشخص‌شده با \fB\-\-symbol\-decorator\fP، گنجاندن پرونده سرایند دیگری لازم باشد. .sp این گزینه در GLib 2.66 اضافه شد. .sp این گزینه تنها زمانی قابل استفاده است که از \fB\-\-symbol\-decorator\fP استفاده شده باشد. .UNINDENT .UNINDENT .sp \fB\-\-symbol\-decorator\-define\fP \fIDEFINE\fP .INDENT 0.0 .INDENT 3.5 چنانچه یک \fBDEFINE\fP با این گزینه مشخص شود، کد مبدأ تولیدشده عبارت \fB#define DEFINE\fP را پیش از سایر موارد اضافه خواهد کرد. این حالت زمانی استفاده می‌شود که ماکروی خاصی لازم باشد تا اطمینان حاصل شود دکوراتور داده‌شده از طریق \fB\-\-symbol\-decorator\fP هنگام کامپایل کد مبدأ از تعریف درستی استفاده می‌کند. .sp این گزینه در GLib 2.66 اضافه شد. .sp این گزینه تنها زمانی قابل استفاده است که از \fB\-\-symbol\-decorator\fP استفاده شده باشد. .UNINDENT .UNINDENT .sp \fB\-\-output\fP \fIOUTFILE\fP .INDENT 0.0 .INDENT 3.5 مسیر کاملی که سرایند (\fB\-\-header\fP، \fB\-\-interface\-info\-header\fP) یا کد مبدأ (\fB\-\-body\fP، \fB\-\-interface\-info\-body\fP) با استفاده از مسیر و نام پرونده مشخص‌شده توسط \fB\-\-output\fP در آن نوشته می‌شود. مسیر کامل می‌تواند چیزی شبیه به \fB$($OUTFILE).{c,h}\fP باشد. .sp استفاده از گزینه‌های \fB\-\-generate\-c\-code\fP، \fB\-\-generate\-docbook\fP یا \fB\-\-output\-directory\fP در کنار \fB\-\-output\fP مجاز نیست، زیرا مورد اخیر فقط برای تولید یک پرونده به کار می‌رود. .sp از نسخه GLib 2.80، اگر \fIOUTFILE\fP رشته دقیق \fB\-\fP باشد، سرایند یا کد مبدأ به خروجی استاندارد نوشته می‌شود. .sp برای \fB\-\-body\fP و \fB\-\-interface\-info\-body\fP، کد تولیدشده هنگام نوشتن در خروجی استاندارد به طور خودکار پرونده سرایند متناظر را \fB#include\fP نخواهد کرد، چرا که نام مشخصی برای آن پرونده سرایند وجود ندارد. این امر ممکن است استفاده از \fBcc \-include foo.h\fP یا تولید پرونده‌ای مانند \fBfoo\-impl.h\fP و \fB#include\fP کردن آن در یک پرونده پوششی \fB\&.c\fP را ضروری کند. .sp برای \fB\-\-header\fP و \fB\-\-interface\-info\-header\fP، هیچ نام مشخصی برای محافظ شمول سنتی هنگام ارسال به خروجی استاندارد وجود ندارد، بنابراین استفاده از گزینه \fB\-\-pragma\-once\fP توصیه می‌شود. .sp در وضعیت‌های نادری که نام پرونده خروجی مورد نظر با \fB\-\fP آغاز شود، باید پیشوند \fB\&./\fP به آن افزوده شود. .UNINDENT .UNINDENT .sp \fB\-\-annotate\fP \fIELEMENT\fP \fIKEY\fP \fIVALUE\fP .INDENT 0.0 .INDENT 3.5 برای تزریق یادداشت‌های D\-Bus به پرونده‌های XML داده‌شده استفاده می‌شود. می‌توان از آن به شیوه زیر برای رابط‌ها، متدها، سیگنال‌ها، ویژگی‌ها و آرگومان‌ها استفاده کرد: .INDENT 0.0 .INDENT 3.5 .sp .EX gdbus\-codegen \-\-c\-namespace MyApp \e \-\-generate\-c\-code myapp\-generated \e \-\-annotate \(dqorg.project.InterfaceName\(dq \e org.gtk.GDBus.C.Name MyFrobnicator \e \-\-annotate \(dqorg.project.InterfaceName:Property\(dq \e bar bat \e \-\-annotate \(dqorg.project.InterfaceName.Method()\(dq \e org.freedesktop.DBus.Deprecated true \e \-\-annotate \(dqorg.project.InterfaceName.Method()[arg_name]\(dq \e snake hiss \e \-\-annotate \(dqorg.project.InterfaceName::Signal\(dq \e cat meow \e \-\-annotate \(dqorg.project.InterfaceName::Signal[arg_name]\(dq \e dog wuff \e myapp\-dbus\-interfaces.xml .EE .UNINDENT .UNINDENT .sp هر رشته UTF\-8 می‌تواند برای \fIKEY\fP و \fIVALUE\fP استفاده شود. .UNINDENT .UNINDENT .sp \fB\-\-glib\-min\-required\fP \fIVERSION\fP .INDENT 0.0 .INDENT 3.5 حداقل نسخه GLib را مشخص می‌کند که کد تولیدشده توسط \fBgdbus\-codegen\fP می‌تواند به آن وابسته باشد. از این گزینه می‌توان برای ایجاد تغییرات ناسازگار با گذشته در خروجی یا رفتار \fBgdbus\-codegen\fP در آینده استفاده کرد، که کاربران با افزایش مقدار ارسالی برای \fB\-\-glib\-min\-required\fP می‌توانند آن را فعال سازند. اگر این گزینه پاس داده نشود، سازگاری خروجی \fBgdbus\-codegen\fP با تمام نسخه‌های GLib از 2.30 به بالا تضمین می‌شود، زیرا نخستین بار \fBgdbus\-codegen\fP در این نسخه منتشر شد. .sp توجه داشته باشید که برخی پارامترهای نسخه تغییرات ناسازگار ایجاد می‌کنند: ممکن است لازم باشد تمام فراخوان‌های کد تولیدشده به‌روزرسانی شوند، و اگر کد تولیدشده بخشی از API یا ABI یک کتابخانه باشد، افزایش پارامتر نسخه می‌تواند باعث شکستن API یا ABI شود. .sp شماره نسخه باید به شکل \fBMAJOR.MINOR.MICRO\fP باشد که تمام بخش‌های آن اعداد صحیح هستند. بخش‌های \fBMINOR\fP و \fBMICRO\fP اختیاری هستند. شماره نسخه نمی‌تواند کوچکتر از \fB2.30\fP باشد. .sp اگر شماره نسخه \fB2.64\fP یا بالاتر باشد، کد تولیدشده دارای ویژگی‌های زیر خواهد بود: .INDENT 0.0 .IP 1. 3 اگر متدی دارای پارامتر(های) \fBh\fP (توصیف‌کننده پرونده) باشد، پارامتر \fBGUnixFDList\fP در کد تولیدشده برای آن وجود خواهد داشت (در حالی که قبلاً یادداشت \fBorg.gtk.GDBus.C.UnixFD\fP لازم بود)، و .IP 2. 3 توابع فراخوانی متد دارای دو آرگومان اضافه خواهند بود تا به کاربر امکان دهند \fBGDBusCallFlags\fP و مقدار مهلت زمانی (timeout) را مشخص کند، همان‌طور که هنگام استفاده از \fBg_dbus_proxy_call()\fP امکان‌پذیر است. .UNINDENT .UNINDENT .UNINDENT .sp \fB\-\-glib\-max\-allowed\fP \fIVERSION\fP .INDENT 0.0 .INDENT 3.5 حداکثر نسخه GLib را مشخص می‌کند که کد تولیدشده توسط \fBgdbus\-codegen\fP می‌تواند به آن وابسته باشد. از این گزینه می‌توان اطمینان حاصل کرد که کدهای تولیدشده توسط \fBgdbus\-codegen\fP با نسخه‌های قدیمی‌تر خاص GLib که نرم‌افزار شما باید از آن‌ها پشتیبانی کند قابل کامپایل باشند. .sp شماره نسخه باید به شکل \fBMAJOR.MINOR.MICRO\fP باشد که در آن تمام بخش‌ها اعداد صحیح هستند. بخش‌های \fBMINOR\fP و \fBMICRO\fP اختیاری هستند. شماره نسخه باید بزرگتر یا مساوی با مقدار ارسالی به \fB\-\-glib\-min\-required\fP باشد. به صورت پیشفرض مقدار آن برابر با نسخه GLib ارائه‌دهنده این \fBgdbus\-codegen\fP است. .UNINDENT .UNINDENT .sp \fB\-\-extension\-path\fP \fIEXTENSION_PATH\fP .INDENT 0.0 .INDENT 3.5 برای بارگذاری یک افزونه در codegen استفاده می‌شود. شناسه \fIEXTENSION_PATH\fP مسیری به یک پرونده پایتون است که به عنوان ماژول بارگذاری خواهد شد. این افزونه باید دست‌کم تابع \fBdef init(args, options)\fP را تعریف کند که در آن \fBargs\fP یک \fBargparse.Namespace\fP و \fBoptions\fP یک فرهنگ‌لغت حاوی کلید \fBversion\fP است. .sp تمام دیگر رابط‌های برنامه‌نویسی (API) که افزونه می‌تواند استفاده کند داخلی بوده و بنابراین ناپایدارند، اما تلاش می‌شود با تغییر این موارد داخلی، فیلد \fBversion\fP افزایش یابد. در صورتی که تمایل به استفاده از این سازوکار دارید، لطفاً با ثبت یک گزارش در \% مورد کاربردی خود را با ما در میان بگذارید. .UNINDENT .UNINDENT .SH "یادداشت‌های D-BUS پشتیبانی‌شده (SUPPORTED D-BUS ANNOTATIONS)" .sp یادداشت‌های D\-Bus زیر توسط \fBgdbus\-codegen\fP پشتیبانی می‌شوند: .sp \fBorg.freedesktop.DBus.Deprecated\fP .INDENT 0.0 .INDENT 3.5 می‌تواند روی هر عنصر \fB\fP، \fB\fP، \fB\fP و \fB\fP استفاده شود تا در صورتی که مقدار آن \fBtrue\fP باشد، منسوخ بودن آن عنصر را مشخص سازد. توجه داشته باشید که این یادداشت در مشخصات گذرگاه D\-Bus \% تعریف شده است و تنها می‌تواند مقادیر \fBtrue\fP و \fBfalse\fP را بپذیرد. به طور خاص، شما نمی‌توانید نسخه‌ای که عنصر در آن منسوخ شده یا پیامی توضیحی برای منسوخ شدن مشخص کنید؛ چنین اطلاعاتی باید در مستندات عنصر درج شوند. .sp هنگام تولید کد C، این یادداشت برای اضافه کردن ماکروی \fBG_GNUC_DEPRECATED\fP به توابع تولیدشده برای آن عنصر به کار می‌رود. .sp هنگام تولید DocBook XML، یک هشدار منسوخ‌شدگی در کنار مستندات آن عنصر پدیدار خواهد شد. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.Since\fP .INDENT 0.0 .INDENT 3.5 می‌تواند روی هر عنصر \fB\fP، \fB\fP، \fB\fP و \fB\fP به کار رود تا نسخه‌ای را که عنصر در آن پدیدار شده است مشخص کند (هر رشته با قالب آزاد اما با تابعی آگاه از نسخه مقایسه می‌شود). .sp هنگام تولید کد C، این فیلد برای اطمینان از ترتیب اشاره‌گرهای توابع جهت حفظ سازگاری ABI/API استفاده می‌شود؛ بخش «تضمین‌های پایداری» را ببینید. .sp هنگام تولید DocBook XML، مقدار این تگ در مستندات ظاهر می‌شود. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.DocString\fP .INDENT 0.0 .INDENT 3.5 رشته‌ای حاوی محتوای DocBook برای مستندسازی. این یادداشت می‌تواند روی عناصر \fB\fP، \fB\fP، \fB\fP، \fB\fP و \fB\fP استفاده شود. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.DocString.Short\fP .INDENT 0.0 .INDENT 3.5 رشته‌ای با محتوای DocBook برای مستندسازی کوتاه و مختصر. این یادداشت تنها روی عناصر \fB\fP قابل استفاده است. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.C.Name\fP .INDENT 0.0 .INDENT 3.5 می‌تواند روی هر عنصر \fB\fP، \fB\fP، \fB\fP و \fB\fP استفاده شود تا نام مورد استفاده در هنگام تولید کد C را مشخص کند. مقدار آن باید به شکل CamelCase \% یا \fIUgly_Case\fP (توضیح داده شده در بالا) باشد. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.C.ForceGVariant\fP .INDENT 0.0 .INDENT 3.5 در صورت تنظیم بر روی یک رشته غیرخالی، به جای نوع طبیعی C از یک نمونه \fBGVariant\fP استفاده خواهد شد. این یادداشت می‌تواند روی هر عنصر \fB\fP و \fB\fP استفاده شود. .UNINDENT .UNINDENT .sp \fBorg.gtk.GDBus.C.UnixFD\fP .INDENT 0.0 .INDENT 3.5 در صورت تنظیم بر روی یک رشته غیرخالی، کد تولیدشده شامل پارامترهایی برای تبادل توصیف‌کننده‌های پرونده با استفاده از نوع \fBGUnixFDList\fP خواهد بود. این یادداشت می‌تواند روی عناصر \fB\fP استفاده شود. .UNINDENT .UNINDENT .sp به عنوان راهکاری ساده‌تر به جای استفاده از یادداشت \fBorg.gtk.GDBus.DocString\fP، توجه داشته باشید که تجزیه‌کننده مورد استفاده توسط \fBgdbus\-codegen\fP یادداشت‌های توضیحی XML را به روشی مشابه gtk\-doc \% تجزیه می‌کند: .INDENT 0.0 .INDENT 3.5 .sp .EX .EE .UNINDENT .UNINDENT .sp توجه داشته باشید که \fB@since\fP می‌تواند در هر بخش از مستندات درون‌خطی (مثلاً برای رابط‌ها، متدها، سیگنال‌ها و ویژگی‌ها) جهت تنظیم یادداشت \fBorg.gtk.GDBus.Since\fP استفاده شود. برای یادداشت \fBorg.gtk.GDBus.DocString\fP (و توضیحات درون‌خطی)، دقت کنید که زیررشته‌هایی به شکل \fB#net.Corp.Bar\fP، \fBnet.Corp.Bar.FooMethod()\fP، \fB#net.Corp.Bar::BarSignal\fP و \fB#net.Corp.InlineDocs:BazProperty\fP همگی به پیوندهایی به رابط، متد، سیگنال و ویژگی مربوطه گسترش می‌یابند. علاوه بر این، زیررشته‌هایی که با کاراکترهای \fB@\fP و \fB%\fP آغاز می‌شوند به ترتیب به صورت پارامتر \% و ثوابت \% رندر می‌شوند. .sp اگر هر دو مورد توضیحات XML و یادداشت‌های \fBorg.gtk.GDBus.DocString\fP یا \fBorg.gtk.GDBus.DocString.Short\fP وجود داشته باشند، اولویت با یادداشت‌ها خواهد بود. .SH "مثال (EXAMPLE)" .sp پرونده XML درون‌نگری گذرگاه D\-Bus زیر را در نظر بگیرید: .INDENT 0.0 .INDENT 3.5 .sp .EX .EE .UNINDENT .UNINDENT .sp اگر \fBgdbus\-codegen\fP روی این پرونده به صورت زیر اجرا شود: .INDENT 0.0 .INDENT 3.5 .sp .EX gdbus\-codegen \-\-generate\-c\-code myapp\-generated \e \-\-c\-namespace MyApp \e \-\-interface\-prefix net.corp.MyApp. \e net.Corp.MyApp.Frobber.xml .EE .UNINDENT .UNINDENT .sp دو پرونده به نام‌های \fBmyapp\-generated.[ch]\fP تولید می‌شوند. این پرونده‌ها یک نوع انتزاعی مشتق‌شده از \fBGTypeInterface\fP با نام \fBMyAppFrobber\fP و همچنین دو نوع قابل نمونه‌سازی با همان نام اما با پسوندهای \fBProxy\fP و \fBSkeleton\fP ارائه می‌دهند. پرونده تولیدشده، به طور کلی، شامل امکانات زیر است: .INDENT 0.0 .INDENT 3.5 .sp .EX /* GType macros for the three generated types */ #define MY_APP_TYPE_FROBBER (my_app_frobber_get_type ()) #define MY_APP_TYPE_FROBBER_SKELETON (my_app_frobber_skeleton_get_type ()) #define MY_APP_TYPE_FROBBER_PROXY (my_app_frobber_proxy_get_type ()) typedef struct _MyAppFrobber MyAppFrobber; /* Dummy typedef */ typedef struct { GTypeInterface parent_iface; /* Signal handler for the ::notification signal */ void (*notification) (MyAppFrobber *proxy, GVariant *icon_blob, gint height, const gchar* const *messages); /* Signal handler for the ::handle\-hello\-world signal */ gboolean (*handle_hello_world) (MyAppFrobber *proxy, GDBusMethodInvocation *invocation, const gchar *greeting); } MyAppFrobberIface; /* Asynchronously calls HelloWorld() */ void my_app_frobber_call_hello_world (MyAppFrobber *proxy, const gchar *greeting, GCancellable *cancellable, GAsyncReadyCallback callback, gpointer user_data); gboolean my_app_frobber_call_hello_world_finish (MyAppFrobber *proxy, gchar **out_response, GAsyncResult *res, GError **error); /* Synchronously calls HelloWorld(). Blocks calling thread. */ gboolean my_app_frobber_call_hello_world_sync (MyAppFrobber *proxy, const gchar *greeting, gchar **out_response, GCancellable *cancellable, GError **error); /* Completes handling the HelloWorld() method call */ void my_app_frobber_complete_hello_world (MyAppFrobber *object, GDBusMethodInvocation *invocation, const gchar *response); /* Emits the ::notification signal / Notification() D\-Bus signal */ void my_app_frobber_emit_notification (MyAppFrobber *object, GVariant *icon_blob, gint height, const gchar* const *messages); /* Gets the :verbose GObject property / Verbose D\-Bus property. * Does no blocking I/O. */ gboolean my_app_frobber_get_verbose (MyAppFrobber *object); /* Sets the :verbose GObject property / Verbose D\-Bus property. * Does no blocking I/O. */ void my_app_frobber_set_verbose (MyAppFrobber *object, gboolean value); /* Gets the interface info */ GDBusInterfaceInfo *my_app_frobber_interface_info (void); /* Creates a new skeleton object, ready to be exported */ MyAppFrobber *my_app_frobber_skeleton_new (void); /* Client\-side proxy constructors. * * Additionally, _new_for_bus(), _new_for_bus_finish() and * _new_for_bus_sync() proxy constructors are also generated. */ void my_app_frobber_proxy_new (GDBusConnection *connection, GDBusProxyFlags flags, const gchar *name, const gchar *object_path, GCancellable *cancellable, GAsyncReadyCallback callback, gpointer user_data); MyAppFrobber * my_app_frobber_proxy_new_finish (GAsyncResult *res, GError **error); MyAppFrobber * my_app_frobber_proxy_new_sync (GDBusConnection *connection, GDBusProxyFlags flags, const gchar *name, const gchar *object_path, GCancellable *cancellable, GError **error); .EE .UNINDENT .UNINDENT .sp بنابراین، به ازای هر متد D\-Bus، سه تابع C برای فراخوانی متد، یک سیگنال \fBGObject\fP برای مدیریت فراخوانی ورودی و یک تابع C برای تکمیل فراخوانی ورودی وجود خواهد داشت. به ازای هر سیگنال D\-Bus، یک سیگنال \fBGObject\fP و یک تابع C برای ارسال آن وجود دارد. به ازای هر ویژگی D\-Bus، دو تابع C (یکی setter و دیگری getter) و یک ویژگی \fBGObject\fP تولید می‌شود. جدول زیر امکانات تولیدشده و محل کاربرد آن‌ها را خلاصه می‌کند: .TS box center; l|l|l. T{ نوع نماد T} T{ کلاینت T} T{ سرور T} _ T{ انواع (Types) T} T{ استفاده از \fBMyAppFrobberProxy\fP\&. T} T{ هر نوعی که رابط \fBMyAppFrobber\fP را پیاده‌سازی کند. T} _ T{ متدها (Methods) T} T{ استفاده از \fBm_a_f_hello_world()\fP برای فراخوانی. T} T{ دریافت از طریق گرداننده سیگنال \fBhandle_hello_world()\fP\&. تکمیل فراخوانی با \fBm_a_f_complete_hello_world()\fP\&. T} _ T{ سیگنال‌ها (Signals) T} T{ اتصال به سیگنال \fB::notification\fP\&. T} T{ استفاده از \fBm_a_f_emit_notification()\fP برای ارسال سیگنال. T} _ T{ ویژگی‌ها (خواندن) T} T{ استفاده از \fBm_a_f_get_verbose()\fP یا ویژگی \fB:verbose\fP\&. T} T{ پیاده‌سازی تابع مجازی \fBget_property()\fP در \fBGObject\fP\&. T} _ T{ ویژگی‌ها (نوشتن) T} T{ استفاده از \fBm_a_f_set_verbose()\fP یا ویژگی \fB:verbose\fP\&. T} T{ پیاده‌سازی تابع مجازی \fBset_property()\fP در \fBGObject\fP\&. T} .TE .SS "استفاده در سمت کلاینت (Client-side usage)" .sp شما می‌توانید از نوع پراکسی تولیدشده همراه با سازنده‌های تولیدشده استفاده کنید: .INDENT 0.0 .INDENT 3.5 .sp .EX MyAppFrobber *proxy; GError *error; error = NULL; proxy = my_app_frobber_proxy_new_for_bus_sync ( G_BUS_TYPE_SESSION, G_DBUS_PROXY_FLAGS_NONE, \(dqnet.Corp.MyApp\(dq, /* bus name */ \(dq/net/Corp/MyApp/SomeFrobber\(dq, /* object */ NULL, /* GCancellable* */ &error); /* do stuff with proxy */ g_object_unref (proxy); .EE .UNINDENT .UNINDENT .sp به جای استفاده از امکانات عمومی \fBGDBusProxy\fP، می‌توان از متدهای تولیدشده مانند \fBmy_app_frobber_call_hello_world()\fP برای فراخوانی متد D\-Bus با نام \fBnet.Corp.MyApp.Frobber.HelloWorld()\fP استفاده کرد، به سیگنال \fBGObject\fP با عنوان \fB::notification\fP برای دریافت سیگنال D\-Bus با نام \fBnet.Corp.MyApp.Frobber::Notification\fP متصل شد و ویژگی D\-Bus با نام \fBnet.Corp.MyApp.Frobber:Verbose\fP را با استفاده از ویژگی \fB:verbose\fP در \fBGObject\fP یا متدهای \fBmy_app_get_verbose()\fP و \fBmy_app_set_verbose()\fP دریافت کرد یا مقدار داد. برای گوش فرا دادن به تغییرات ویژگی‌ها، از سیگنال استاندارد \fBGObject::notify\fP استفاده کنید. .sp توجه داشته باشید که تمام دسترسی‌ها به ویژگی‌ها از طریق حافظه نهان (cache) ویژگی \fBGDBusProxy\fP انجام می‌شود، بنابراین هنگام خواندن ویژگی‌ها هیچ عملیات I/O انجام نمی‌گیرد. همچنین توجه داشته باشید که تنظیم یک ویژگی باعث فراخوانی متد \fBorg.freedesktop.DBus.Properties.Set\fP (مستندات \%) بر روی شیء دوردست (remote) می‌شود. با این حال، این فراخوانی ناهمگام (asynchronous) است، بنابراین مقداردهی ویژگی مسدودکننده (blocking) نخواهد بود. علاوه بر این، اعمال تغییر با تأخیر همراه است و امکان بررسی خطا وجود ندارد. .SS "استفاده در سمت سرور (Server-side usage)" .sp رابط تولیدشده \fBMyAppFrobber\fP به گونه‌ای طراحی شده است که پیاده‌سازی آن در یک زیرکلاس از \fBGObject\fP ساده باشد. برای نمونه، جهت رسیدگی به فراخوانی‌های متد \fBHelloWorld()\fP، تابع مجازی \fBhandle_hello_world()\fP را در ساختار \fBMyAppFrobberIface\fP تنظیم کنید. به طور مشابه، جهت رسیدگی به ویژگی \fBnet.Corp.MyApp.Frobber:Verbose\fP، ویژگی \fB:verbose\fP در \fBGObject\fP را از زیرکلاس بازنویسی (override) نمایید. برای ارسال یک سیگنال، مثلاً از \fBmy_app_emit_signal()\fP یا \fBg_signal_emit_by_name()\fP استفاده کنید. .sp به جای ایجاد زیرکلاس، اغلب ساده‌تر است که از زیرکلاس تولیدشده \fBMyAppFrobberSkeleton\fP استفاده کنید. برای مدیریت فراخوانی‌های متد ورودی، از \fBg_signal_connect()\fP با سیگنال‌های \fB::handle\-*\fP استفاده کنید و به جای بازنویسی توابع مجازی \fBget_property()\fP و \fBset_property()\fP از \fBGObject\fP، توابع \fBg_object_get()\fP و \fBg_object_set()\fP یا گترها و سترهای ویژگی‌های تولیدشده را به کار ببرید (کلاس تولیدشده دارای یک پیاده‌سازی داخلی از بسته ویژگی‌ها است). .sp برای مثال: .INDENT 0.0 .INDENT 3.5 .sp .EX static gboolean on_handle_hello_world (MyAppFrobber *interface, GDBusMethodInvocation *invocation, const gchar *greeting, gpointer user_data) { if (g_strcmp0 (greeting, \(dqBoo\(dq) != 0) { gchar *response; response = g_strdup_printf (\(dqWord! You said ‘%s’.\(dq, greeting); my_app_complete_hello_world (interface, invocation, response); g_free (response); } else { g_dbus_method_invocation_return_error (invocation, MY_APP_ERROR, MY_APP_ERROR_NO_WHINING, \(dqHey, %s, there will be no whining!\(dq, g_dbus_method_invocation_get_sender (invocation)); } return TRUE; } […] interface = my_app_frobber_skeleton_new (); my_app_frobber_set_verbose (interface, TRUE); g_signal_connect (interface, \(dqhandle\-hello\-world\(dq, G_CALLBACK (on_handle_hello_world), some_user_data); […] error = NULL; if (!g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (interface), connection, \(dq/path/of/dbus_object\(dq, &error)) { /* handle error */ } .EE .UNINDENT .UNINDENT .sp برای تسهیل تغییرات دسته‌ای و اتمیک (تغییر چند ویژگی به طور همزمان)، سیگنال‌های \fBGObject::notify\fP هنگام دریافت در صف قرار می‌گیرند. این صف در یک رسیدگی‌کننده بیکار (idle handler که از حلقه اصلی پیشفرض ریسه سازنده شیء اسکلتون فراخوانی می‌شود) تخلیه می‌شود و باعث ارسال سیگنال \fBorg.freedesktop.DBus.Properties::PropertiesChanged\fP (مستندات \%) به همراه تمام ویژگی‌های تغییر یافته خواهد شد. برای خالی کردن فوری صف، از \fBg_dbus_interface_skeleton_flush()\fP یا \fBg_dbus_object_skeleton_flush()\fP استفاده کنید. چنانچه روی ریسه (thread) دیگری هستید، برای اعمال تغییرات اتمیک از \fBg_object_freeze_notify()\fP و \fBg_object_thaw_notify()\fP استفاده کنید. .SH "نگاشت انواع داده C (C TYPE MAPPING)" .sp انواع اسکالر (رشته‌های نوع \fBb\fP، \fBy\fP، \fBn\fP، \fBq\fP، \fBi\fP، \fBu\fP، \fBx\fP، \fBt\fP و \fBd\fP)، رشته‌ها (رشته‌های نوع \fBs\fP، \fBay\fP، \fBo\fP و \fBg\fP) و آرایه‌های رشته‌ای (رشته‌های نوع \fBas\fP، \fBao\fP و \fBaay\fP) به انواع طبیعی نگاشت می‌شوند، مانند \fBgboolean\fP، \fBgdouble\fP، \fBgint\fP، \fBgchar*\fP، \fBgchar**\fP و غیره. هر چیز دیگری به نوع \fBGVariant\fP نگاشت می‌گردد. .sp این نگاشت خودکار را می‌توان با استفاده از یادداشت \fBorg.gtk.GDBus.C.ForceGVariant\fP غیرفعال کرد — در صورت استفاده، همواره به جای نوع بومی متناظر در C، یک \fBGVariant\fP مبادله می‌شود. این یادداشت ممکن است هنگام استفاده از رشته‌های بایتی (رشته نوع \fBay\fP) برای داده‌هایی که ممکن است دارای بایت‌های تهی (nul bytes) توکار باشند، مفید باشد. .SH "تضمین‌های پایداری (STABILITY GUARANTEES)" .sp توابع C تولیدشده تضمین می‌شوند که ABI خود را تغییر ندهند. بدین معنا که اگر یک متد، سیگنال یا ویژگی امضای خود را در XML درون‌نگری تغییر ندهد، توابع C تولیدشده نیز ABI زبان C خود را تغییر نخواهند داد. ساختار کلاس و نمونه‌های تولیدشده نیز حفظ خواهد شد. .sp سازگاری ABI نمونه‌های \fBGType\fP تولیدشده تنها در صورتی حفظ خواهد شد که یادداشت \fBorg.gtk.GDBus.Since\fP با دقت و هوشمندانه استفاده شود — این امر به این دلیل است که VTable برای \fBGInterface\fP بر اشاره‌گرهای توابع برای گرداننده‌های سیگنال متکی است. به طور مشخص، اگر یک متد، ویژگی یا سیگنال D\-Bus به رابط D\-Bus اضافه شود، ABI نوع \fBGInterface\fP تولیدشده اگر و تنها اگر حفظ می‌شود که هر متد، ویژگی یا سیگنال اضافه شده با یادداشت \fBorg.gtk.GDBus.Since\fP همراه با شماره نسخه‌ای بالاتر از نسخه‌های پیشین نشانه‌گذاری شود. .sp کدهای C تولیدشده در حال حاضر با توضیحات و یادداشت‌های gtk\-doc \% و GObject Introspection \% نشانه‌گذاری می‌شوند. چیدمان و محتوا ممکن است در آینده تغییر کند، بنابراین هیچ تضمینی در مورد کاربرد مواردی مانند \fBSECTION\fP و غیره داده نمی‌شود. .sp در حالی که انتظار نمی‌رود پرونده‌های DocBook تولیدشده برای رابط‌های D\-Bus تغییر کنند، در حال حاضر هیچ تضمینی داده نمی‌شود. .sp نکته مهم این است که کدهای تولیدشده نباید در سیستم‌های کنترل نسخه ذخیره شوند و نباید در آرشیوهای توزیع کد مبدأ قرار گیرند. .SH "گزارش خطاها (BUGS)" .sp لطفاً گزارش‌های خطا را به ردیاب خطاهای توزیع یا ردیاب خطاهای بالادستی در \% ارسال فرمایید. .SH "همچنین ببینید (SEE ALSO)" .sp gdbus(1) \% .\" End of generated man page.