From 1fe6241a5e6b52be451b8536d945a9630369673c Mon Sep 17 00:00:00 2001 From: John Cupitt Date: Thu, 28 Jul 2011 12:22:44 +0100 Subject: [PATCH] move enum gtk-doc move the enum gtk-doc comments into the headers, matching glib's style I hope this might fix some warnings during gtk-doc generation, but they seeem to still be there, ah well --- doc/src/figs/arch8.svg | 5 +- libvips/include/vips/image.h | 103 +++++++++++++++++++++++++++++++++- libvips/include/vips/object.h | 38 +++++-------- libvips/include/vips/util.h | 27 +++++++-- libvips/iofuncs/image.c | 100 --------------------------------- 5 files changed, 141 insertions(+), 132 deletions(-) diff --git a/doc/src/figs/arch8.svg b/doc/src/figs/arch8.svg index ca87cbb7..6ff90ceb 100644 --- a/doc/src/figs/arch8.svg +++ b/doc/src/figs/arch8.svg @@ -15,7 +15,10 @@ id="svg2" version="1.1" inkscape:version="0.48.1 r9760" - sodipodi:docname="New document 1"> + sodipodi:docname="arch8.svg" + inkscape:export-filename="/home/john/Desktop/arch8.png" + inkscape:export-xdpi="72.058372" + inkscape:export-ydpi="72.058372"> unsigned short. + */ typedef enum { VIPS_FORMAT_NOTSET = -1, VIPS_FORMAT_UCHAR = 0, @@ -106,6 +188,21 @@ typedef enum { VIPS_FORMAT_LAST = 10 } VipsBandFormat; +/** + * VipsCoding: + * @VIPS_CODING_NONE: pixels are not coded + * @VIPS_CODING_LABQ: pixels encode 3 float CIELAB values as 4 uchar + * @VIPS_CODING_RAD: pixels encode 3 float RGB as 4 uchar (Radiance coding) + * + * How pixels are coded. + * + * Normally, pixels are uncoded and can be manipulated as you would expect. + * However some file formats code pixels for compression, and sometimes it's + * useful to be able to manipulate images in the coded format. + * + * The gaps in the numbering are historical and must be maintained. Allocate + * new numbers from the end. + */ typedef enum { VIPS_CODING_NONE = 0, VIPS_CODING_LABQ = 2, diff --git a/libvips/include/vips/object.h b/libvips/include/vips/object.h index f6081165..8f7af978 100644 --- a/libvips/include/vips/object.h +++ b/libvips/include/vips/object.h @@ -44,36 +44,28 @@ typedef struct _VipsObjectClass VipsObjectClass; /* Track extra stuff for arguments to objects */ -/* Flags we associate with each argument. +/** + * VipsArgumentFlags: + * @VIPS_ARGUMENT_NONE: no flags + * @VIPS_ARGUMENT_REQUIRED: must be set in the constructor + * @VIPS_ARGUMENT_CONSTRUCT: can only be set in the constructor + * @VIPS_ARGUMENT_SET_ONCE: can only be set once + * @VIPS_ARGUMENT_INPUT: is an input argument (one we depend on) + * @VIPS_ARGUMENT_OUTPUT: is an output argument (depends on us) + * + * Flags we associate with each object argument. + * + * Have separate input & output flags. Both set is an error; neither set is OK. + * + * Input gobjects are automatically reffed, output gobjects automatically ref + * us. We also automatically watch for "destroy" and unlink. */ typedef enum { VIPS_ARGUMENT_NONE = 0, - - /* Must be set in the constructor. - */ VIPS_ARGUMENT_REQUIRED = 1, - - /* Can only be set in the constructor. - */ VIPS_ARGUMENT_CONSTRUCT = 2, - - /* Can only be set once. - */ VIPS_ARGUMENT_SET_ONCE = 4, - - /* Have input & output flags. Both set is an error; neither set is OK. - */ - - /* Is an input argument (one we depend on) ... if it's a gobject, we - * should ref it. In our _dispose(), we should unref it. - */ VIPS_ARGUMENT_INPUT = 8, - - /* Is an output argument (one that depends on us) ... if it's a - * gobject, we should ref ourselves. We watch "destroy" on the - * argument: if it goes, we unref ourselves. If we dispose, we - * disconnect the signal. - */ VIPS_ARGUMENT_OUTPUT = 16 } VipsArgumentFlags; diff --git a/libvips/include/vips/util.h b/libvips/include/vips/util.h index 30fd88b1..03aec437 100644 --- a/libvips/include/vips/util.h +++ b/libvips/include/vips/util.h @@ -217,12 +217,29 @@ int vips_existsf( const char *name, ... ) FILE *vips_popenf( const char *fmt, const char *mode, ... ) __attribute__((format(printf, 1, 3))); +/** + * VipsToken: + * @VIPS_TOKEN_LEFT: left bracket + * @VIPS_TOKEN_RIGHT: right bracket + * @VIPS_TOKEN_STRING: string constant + * @VIPS_TOKEN_EQUALS: equals sign + * @VIPS_TOKEN_COMMA: comma + * + * Tokens returned by the vips lexical analyzer, see vips__token_get(). This + * is used to parse option strings for arguments. + * + * Left and right brackets can be any of (, {, [, <. + * + * Strings may be in double quotes, and may contain escaped quote characters, + * for example string, "string" and "str\"ing". + * + */ typedef enum { - VIPS_TOKEN_LEFT = 1, /* ({[ */ - VIPS_TOKEN_RIGHT, /* ]}) */ - VIPS_TOKEN_STRING, /* string or "str\"ing" */ - VIPS_TOKEN_EQUALS, /* = */ - VIPS_TOKEN_COMMA /* , */ + VIPS_TOKEN_LEFT = 1, + VIPS_TOKEN_RIGHT, + VIPS_TOKEN_STRING, + VIPS_TOKEN_EQUALS, + VIPS_TOKEN_COMMA } VipsToken; const char *vips__token_get( const char *buffer, diff --git a/libvips/iofuncs/image.c b/libvips/iofuncs/image.c index 07eaaf05..328d2b6f 100644 --- a/libvips/iofuncs/image.c +++ b/libvips/iofuncs/image.c @@ -81,106 +81,6 @@ * The first four bytes of a VIPS file in SPARC byte ordering. */ -/** - * VipsDemandStyle: - * @VIPS_DEMAND_STYLE_SMALLTILE: demand in small (typically 64x64 pixel) tiles - * @VIPS_DEMAND_STYLE_FATSTRIP: demand in fat (typically 10 pixel high) strips - * @VIPS_DEMAND_STYLE_THINSTRIP: demand in thin (typically 1 pixel high) strips - * @VIPS_DEMAND_STYLE_ANY: demand geometry does not matter - * - * See vips_demand_hint(). Operations can hint to the VIPS image IO system about - * the kind of demand geometry they prefer. - * - * These demand styles are given below in order of increasing - * restrictiveness. When demanding output from a pipeline, - * vips_image_generate() - * will use the most restrictive of the styles requested by the operations - * in the pipeline. - * - * VIPS_DEMAND_STYLE_THINSTRIP --- This operation would like to output strips - * the width of the image and a few pels high. This is option suitable for - * point-to-point operations, such as those in the arithmetic package. - * - * This option is only efficient for cases where each output pel depends - * upon the pel in the corresponding position in the input image. - * - * VIPS_DEMAND_STYLE_FATSTRIP --- This operation would like to output strips - * the width of the image and as high as possible. This option is suitable - * for area operations which do not violently transform coordinates, such - * as im_conv(). - * - * VIPS_DEMAND_STYLE_SMALLTILE --- This is the most general demand format. - * Output is demanded in small (around 100x100 pel) sections. This style works - * reasonably efficiently, even for bizzare operations like 45 degree rotate. - * - * VIPS_DEMAND_STYLE_ANY --- This image is not being demand-read from a disc - * file (even indirectly) so any demand style is OK. It's used for things like - * im_black() where the pixels are calculated. - * - * See also: vips_demand_hint(). - */ - -/** - * VipsInterpretation: - * @VIPS_TYPE_MULTIBAND: generic many-band image - * @VIPS_TYPE_B_W: some kind of single-band image - * @VIPS_TYPE_HISTOGRAM: a 1D image such as a histogram or lookup table - * @VIPS_TYPE_FOURIER: image is in fourier space - * @VIPS_TYPE_XYZ: the first three bands are colours in CIE XYZ colourspace - * @VIPS_TYPE_LAB: pixels are in CIE Lab space - * @VIPS_TYPE_CMYK: the first four bands are in CMYK space - * @VIPS_TYPE_LABQ: implies #VIPS_CODING_LABQ - * @VIPS_TYPE_RGB: generic RGB space - * @VIPS_TYPE_UCS: a uniform colourspace based on CMC - * @VIPS_TYPE_LCH: pixels are in CIE LCh space - * @VIPS_TYPE_LABS: pixels are CIE LAB coded as three signed 16-bit values - * @VIPS_TYPE_sRGB: pixels are sRGB - * @VIPS_TYPE_YXY: pixels are CIE Yxy - * @VIPS_TYPE_RGB16: generic 16-bit RGB - * @VIPS_TYPE_GREY16: generic 16-bit mono - * - * How the values in an image should be interpreted. For example, a - * three-band float image of type #VIPS_TYPE_LAB should have its pixels - * interpreted as coordinates in CIE Lab space. - * - * These values are set by operations as hints to user-interfaces built on top - * of VIPS to help them show images to the user in a meaningful way. - * Operations do not use these values to decide their action. - */ - -/** - * VipsBandFormat: - * @VIPS_FORMAT_NOTSET: invalid setting - * @VIPS_FORMAT_UCHAR: unsigned char format - * @VIPS_FORMAT_CHAR: char format - * @VIPS_FORMAT_USHORT: unsigned short format - * @VIPS_FORMAT_SHORT: short format - * @VIPS_FORMAT_UINT: unsigned int format - * @VIPS_FORMAT_INT: int format - * @VIPS_FORMAT_FLOAT: float format - * @VIPS_FORMAT_COMPLEX: complex (two floats) format - * @VIPS_FORMAT_DOUBLE: double float format - * @VIPS_FORMAT_DPCOMPLEX: double complex (two double) format - * - * The format used for each band element. - * - * Each corresponnds to a native C type for the current machine. For example, - * #VIPS_FORMAT_USHORT is unsigned short. - */ - -/** - * VipsCoding: - * @VIPS_CODING_NONE: pixels are not coded - * @VIPS_CODING_LABQ: pixels encode 3 float CIELAB values as 4 uchar - * @VIPS_CODING_RAD: pixels encode 3 float RGB as 4 uchar (Radiance coding) - * - * How pixels are coded. - * - * Normally, pixels are uncoded and can be manipulated as you would expect. - * However some file formats code pixels for compression, and sometimes it's - * useful to be able to manipulate images in the coded format. - */ - /** * VipsProgress: * @run: Time we have been running