From 8b77c86a061df01069c94f8e16713a7345c99b9c Mon Sep 17 00:00:00 2001 From: Alan Coopersmith Date: Sat, 2 Aug 2025 18:38:26 -0700 Subject: [PATCH] Strip trailing whitespace from source files Performed with: `git ls-files | xargs perl -i -p -e 's{[ \t]+$}{}'` `git diff -w` & `git diff -b` show no diffs from this change Signed-off-by: Alan Coopersmith Part-of: --- .gitignore | 4 +- man/xkb/Makefile.am | 2 +- modules/im/ximcp/imLcIc.c | 2 +- modules/im/ximcp/imRm.c | 14 +- modules/im/ximcp/imThaiFlt.c | 22 +- modules/om/generic/omGeneric.c | 2 +- nls/C/XLC_LOCALE.pre | 10 +- nls/armscii-8/XLC_LOCALE.pre | 12 +- nls/en_US.UTF-8/XLC_LOCALE.pre | 36 +- nls/georgian-academy/XLC_LOCALE.pre | 12 +- nls/georgian-ps/XLC_LOCALE.pre | 14 +- nls/ibm-cp1133/XLC_LOCALE.pre | 12 +- nls/iscii-dev/XLC_LOCALE.pre | 12 +- nls/isiri-3342/XLC_LOCALE.pre | 14 +- nls/iso8859-1/XLC_LOCALE.pre | 14 +- nls/iso8859-10/XLC_LOCALE.pre | 14 +- nls/iso8859-11/XLC_LOCALE.pre | 14 +- nls/iso8859-13/XLC_LOCALE.pre | 14 +- nls/iso8859-14/XLC_LOCALE.pre | 14 +- nls/iso8859-15/XLC_LOCALE.pre | 16 +- nls/iso8859-2/Compose.pre | 4 +- nls/iso8859-2/XLC_LOCALE.pre | 14 +- nls/iso8859-3/XLC_LOCALE.pre | 14 +- nls/iso8859-4/XLC_LOCALE.pre | 14 +- nls/iso8859-5/XLC_LOCALE.pre | 14 +- nls/iso8859-6/XLC_LOCALE.pre | 14 +- nls/iso8859-7/XLC_LOCALE.pre | 14 +- nls/iso8859-8/XLC_LOCALE.pre | 14 +- nls/iso8859-9/XLC_LOCALE.pre | 14 +- nls/iso8859-9e/XLC_LOCALE.pre | 14 +- nls/ja.JIS/XLC_LOCALE.pre | 12 +- nls/ja.SJIS/XLC_LOCALE.pre | 12 +- nls/ja/XLC_LOCALE.pre | 12 +- nls/ja_JP.UTF-8/XLC_LOCALE.pre | 14 +- nls/ko/XLC_LOCALE.pre | 12 +- nls/ko_KR.UTF-8/XLC_LOCALE.pre | 14 +- nls/koi8-c/XLC_LOCALE.pre | 12 +- nls/koi8-r/XLC_LOCALE.pre | 14 +- nls/koi8-u/XLC_LOCALE.pre | 12 +- nls/locale.alias.pre | 2 +- nls/microsoft-cp1251/XLC_LOCALE.pre | 14 +- nls/microsoft-cp1255/XLC_LOCALE.pre | 14 +- nls/microsoft-cp1256/XLC_LOCALE.pre | 14 +- nls/mulelao-1/XLC_LOCALE.pre | 12 +- nls/nokhchi-1/XLC_LOCALE.pre | 14 +- nls/pt_BR.UTF-8/XLC_LOCALE.pre | 16 +- nls/pt_PT.UTF-8/XLC_LOCALE.pre | 16 +- nls/tatar-cyr/XLC_LOCALE.pre | 14 +- nls/th_TH.UTF-8/XLC_LOCALE.pre | 10 +- nls/th_TH/XLC_LOCALE.pre | 10 +- nls/tscii-0/XLC_LOCALE.pre | 12 +- nls/vi_VN.tcvn/XLC_LOCALE.pre | 12 +- nls/vi_VN.viscii/XLC_LOCALE.pre | 12 +- nls/zh_CN.UTF-8/XLC_LOCALE.pre | 10 +- nls/zh_CN.gb18030/XLC_LOCALE.pre | 10 +- nls/zh_CN.gbk/XLC_LOCALE.pre | 12 +- nls/zh_HK.UTF-8/XLC_LOCALE.pre | 10 +- nls/zh_HK.big5/XLC_LOCALE.pre | 12 +- nls/zh_HK.big5hkscs/XLC_LOCALE.pre | 2 +- nls/zh_TW.UTF-8/XLC_LOCALE.pre | 12 +- nls/zh_TW/XLC_LOCALE.pre | 16 +- specs/i18n/trans/trans.xml | 2 +- specs/libX11/AppC.xml | 468 ++++++++--------- specs/libX11/AppD.xml | 204 ++++---- specs/libX11/CH02.xml | 172 +++---- specs/libX11/CH03.xml | 554 ++++++++++---------- specs/libX11/CH04.xml | 214 ++++---- specs/libX11/CH05.xml | 58 +-- specs/libX11/CH06.xml | 426 ++++++++-------- specs/libX11/CH07.xml | 208 ++++---- specs/libX11/CH08.xml | 534 ++++++++++---------- specs/libX11/CH09.xml | 104 ++-- specs/libX11/CH10.xml | 656 ++++++++++++------------ specs/libX11/CH11.xml | 156 +++--- specs/libX11/CH12.xml | 414 +++++++-------- specs/libX11/CH13.xml | 754 ++++++++++++++-------------- specs/libX11/CH14.xml | 586 ++++++++++----------- specs/libX11/CH15.xml | 120 ++--- specs/libX11/CH16.xml | 166 +++--- specs/libX11/credits.xml | 64 +-- specs/libX11/glossary.xml | 308 ++++++------ specs/libX11/libX11.xml | 18 +- src/XErrorDB | 18 +- src/util/mkks.sh | 2 +- src/xlibi18n/lcGeneric.c | 2 +- src/xlibi18n/lcUTF8.c | 8 +- src/xlibi18n/lcUniConv/iso8859_9e.h | 2 +- 87 files changed, 3486 insertions(+), 3486 deletions(-) diff --git a/.gitignore b/.gitignore index 554c7d2a..166719fe 100644 --- a/.gitignore +++ b/.gitignore @@ -72,10 +72,10 @@ core *.tar.bz2 *.tar.gz # -# Add & Override patterns for libX11 +# Add & Override patterns for libX11 # # Edit the following section as needed # For example, !report.pc overrides *.pc. See 'man gitignore' -# +# doltcompile doltlibtool diff --git a/man/xkb/Makefile.am b/man/xkb/Makefile.am index 411f03b5..92f3881a 100644 --- a/man/xkb/Makefile.am +++ b/man/xkb/Makefile.am @@ -190,7 +190,7 @@ libman_PRE = \ XkbTranslateKeyCode.man \ XkbTranslateKeySym.man \ XkbUpdateMapFromCore.man \ - XkbVirtualModsToReal.man + XkbVirtualModsToReal.man libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@) diff --git a/modules/im/ximcp/imLcIc.c b/modules/im/ximcp/imLcIc.c index a3b6c1f5..cdddb0eb 100644 --- a/modules/im/ximcp/imLcIc.c +++ b/modules/im/ximcp/imLcIc.c @@ -200,7 +200,7 @@ Set_Error : Xfree(ic->private.local.ic_resources); ic->private.local.ic_resources = NULL; - + Xfree(ic); return((XIC)NULL); } diff --git a/modules/im/ximcp/imRm.c b/modules/im/ximcp/imRm.c index cdd30521..69d40b9d 100644 --- a/modules/im/ximcp/imRm.c +++ b/modules/im/ximcp/imRm.c @@ -511,7 +511,7 @@ _XimDefaultResName( Xim im = (Xim)ic->core.im; char **out; char *string; - + if(im->core.res_name == (char *)NULL) { return True; } @@ -519,12 +519,12 @@ _XimDefaultResName( string=strdup(im->core.res_name); if ( string == NULL) return False; - + out = (char **)((char *)top + info->offset); Xfree(*out); /* free old im->core.res_name */ *out =string; - + return True; } @@ -547,12 +547,12 @@ _XimDefaultResClass( string=strdup(im->core.res_class); if (string == NULL) return False; - + out = (char **)((char *)top + info->offset); - + Xfree(*out); /* free old im->core.res_class */ *out = string; - + return True; } @@ -836,7 +836,7 @@ _XimEncodeString( } out = (char **)((char *)top + info->offset); - + Xfree(*out); *out = string; return True; diff --git a/modules/im/ximcp/imThaiFlt.c b/modules/im/ximcp/imThaiFlt.c index 2b41a6ec..1ba3bf5c 100644 --- a/modules/im/ximcp/imThaiFlt.c +++ b/modules/im/ximcp/imThaiFlt.c @@ -81,7 +81,7 @@ SOFTWARE. /* character classification table */ #define TACTIS_CHARS 256 -static +static char const tactis_chtype[TACTIS_CHARS] = { CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, /* 0 - 7 */ CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, CTRL, /* 8 - 15 */ @@ -127,7 +127,7 @@ char const tactis_chtype[TACTIS_CHARS] = { #define CH_CLASSES 17 /* 17 classes of chars */ -static +static char const write_rules_lookup[CH_CLASSES][CH_CLASSES] = { /* Table 0: writing/outputting rules */ /* row: leading char, column: following char */ @@ -151,7 +151,7 @@ char const write_rules_lookup[CH_CLASSES][CH_CLASSES] = { ,{XC, NC, NC, NC, NC, NC, NC, NC, NC, NC, CP, NC, CP, NC, NC, NC, NC}/*AV3*/ }; -static +static char const wtt_isc1_lookup[CH_CLASSES][CH_CLASSES] = { /* Table 1: WTT default input sequence check rules */ /* row: leading char, column: following char */ @@ -175,7 +175,7 @@ char const wtt_isc1_lookup[CH_CLASSES][CH_CLASSES] = { ,{XC, AC, AC, AC, AC, AC, AC, RJ, RJ, RJ, CP, RJ, CP, RJ, RJ, RJ, RJ}/*AV3*/ }; -static +static char const wtt_isc2_lookup[CH_CLASSES][CH_CLASSES] = { /* Table 2: WTT strict input sequence check rules */ /* row: leading char, column: following char */ @@ -199,7 +199,7 @@ char const wtt_isc2_lookup[CH_CLASSES][CH_CLASSES] = { ,{XC, AC, AC, AC, RJ, RJ, AC, RJ, RJ, RJ, CP, RJ, CP, RJ, RJ, RJ, RJ}/*AV3*/ }; -static +static char const thaicat_isc_lookup[CH_CLASSES][CH_CLASSES] = { /* Table 3: Thaicat input sequence check rules */ /* row: leading char, column: following char */ @@ -1018,7 +1018,7 @@ ComputeMaskFromKeytrans( #define FIRST_COMPOSE_KEY_STATE 1 #define SECOND_COMPOSE_KEY_STATE 2 -static +static KeySym HexIMNormalKey( XicThaiPart *thai_part, KeySym symbol, @@ -1034,7 +1034,7 @@ KeySym HexIMNormalKey( } -static +static KeySym HexIMFirstComposeKey( XicThaiPart *thai_part, KeySym symbol, @@ -1057,7 +1057,7 @@ KeySym HexIMFirstComposeKey( return NoSymbol; } -static +static KeySym HexIMSecondComposeKey( XicThaiPart *thai_part, KeySym symbol, @@ -1092,7 +1092,7 @@ KeySym HexIMSecondComposeKey( * The current implementation of this routine returns ISO Latin Keysyms. */ -static +static KeySym HexIMComposeSequence(KeySym ks1, KeySym ks2) { int hi_digit; @@ -1129,7 +1129,7 @@ int tactis_code; * 2) whether cancelling key event should be processed or ignored */ -static +static int IsCancelComposeKey( KeySym *symbol, XKeyEvent *event) @@ -1161,7 +1161,7 @@ int IsCancelComposeKey( * set specified keyboard LED on or off */ -static +static void SetLed( Display *dpy, int num, diff --git a/modules/om/generic/omGeneric.c b/modules/om/generic/omGeneric.c index 370072f3..d2399305 100644 --- a/modules/om/generic/omGeneric.c +++ b/modules/om/generic/omGeneric.c @@ -1640,7 +1640,7 @@ close_om( for (count = gen->data_num; count-- > 0; data++) { Xfree(data->charset_list); data->charset_list = NULL; - + /* free font_data for om */ free_fontdataOM(data->font_data,data->font_data_count); Xfree(data->font_data); diff --git a/nls/C/XLC_LOCALE.pre b/nls/C/XLC_LOCALE.pre index 8334363d..da85dd73 100644 --- a/nls/C/XLC_LOCALE.pre +++ b/nls/C/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for C. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -17,9 +17,9 @@ fs0 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name STRING diff --git a/nls/armscii-8/XLC_LOCALE.pre b/nls/armscii-8/XLC_LOCALE.pre index 4fab6394..4fa2707b 100644 --- a/nls/armscii-8/XLC_LOCALE.pre +++ b/nls/armscii-8/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for armscii-8. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset ARMSCII-8:GR font ARMSCII-8:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ARMSCII-8 diff --git a/nls/en_US.UTF-8/XLC_LOCALE.pre b/nls/en_US.UTF-8/XLC_LOCALE.pre index 7b794a9a..ab1c9c21 100644 --- a/nls/en_US.UTF-8/XLC_LOCALE.pre +++ b/nls/en_US.UTF-8/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for en_US.UTF-8 -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -168,9 +168,9 @@ fs16 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -190,70 +190,70 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side GR length 1 ct_encoding ISO8859-2:GR } - + XCOMM cs3 class cs3 { side GR length 1 ct_encoding ISO8859-3:GR } - + XCOMM cs4 class cs4 { side GR length 1 ct_encoding ISO8859-4:GR } - + XCOMM cs5 class cs5 { side GR length 1 ct_encoding ISO8859-5:GR } - + XCOMM cs6 class cs6 { side GR length 1 ct_encoding ISO8859-7:GR } - + XCOMM cs7 class cs7 { side GR length 1 ct_encoding ISO8859-9:GR } - + XCOMM cs8 class cs8 { side GR length 1 ct_encoding ISO8859-13:GR } - + XCOMM cs9 class cs9 { side GR length 1 ct_encoding ISO8859-14:GR } - + XCOMM cs10 class cs10 { side GR length 1 ct_encoding ISO8859-15:GR } - + XCOMM cs11 class cs11 { side GR @@ -269,21 +269,21 @@ cs12 { ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR;\ KSC5601.1987-1:GL; KSC5601.1987-1:GR } - + XCOMM cs13 class cs13 { side GR length 2 ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR } - + XCOMM cs14 class cs14 { side GR length 1 ct_encoding JISX0201.1976-0:GR } - + XCOMM cs15 class cs15 { side none diff --git a/nls/georgian-academy/XLC_LOCALE.pre b/nls/georgian-academy/XLC_LOCALE.pre index 50bc3c8f..50ef0b61 100644 --- a/nls/georgian-academy/XLC_LOCALE.pre +++ b/nls/georgian-academy/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for georgian-academy -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset GEORGIAN-ACADEMY:GR font GEORGIAN-ACADEMY:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name GEORGIAN-ACADEMY diff --git a/nls/georgian-ps/XLC_LOCALE.pre b/nls/georgian-ps/XLC_LOCALE.pre index 9f03ebb9..f78e4a10 100644 --- a/nls/georgian-ps/XLC_LOCALE.pre +++ b/nls/georgian-ps/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for georgian-ps -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -11,11 +11,11 @@ fs0 { name ISO8859-1:GL } font { - primary GEORGIAN-PS:GL + primary GEORGIAN-PS:GL substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset GEORGIAN-PS:GR font GEORGIAN-PS:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name GEORGIAN-PS diff --git a/nls/ibm-cp1133/XLC_LOCALE.pre b/nls/ibm-cp1133/XLC_LOCALE.pre index cdc543a4..485af88c 100644 --- a/nls/ibm-cp1133/XLC_LOCALE.pre +++ b/nls/ibm-cp1133/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for ibm-cp1133. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset IBM-CP1133:GR font IBM-CP1133:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name IBM-CP1133 diff --git a/nls/iscii-dev/XLC_LOCALE.pre b/nls/iscii-dev/XLC_LOCALE.pre index e8631560..d52a4fff 100644 --- a/nls/iscii-dev/XLC_LOCALE.pre +++ b/nls/iscii-dev/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for mulelao-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset ISCII-DEV:GR font ISCII-DEV:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISCII-DEV diff --git a/nls/isiri-3342/XLC_LOCALE.pre b/nls/isiri-3342/XLC_LOCALE.pre index 4ec74f87..42e833fa 100644 --- a/nls/isiri-3342/XLC_LOCALE.pre +++ b/nls/isiri-3342/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for mulelao-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -11,11 +11,11 @@ fs0 { name ISO8859-1:GL } font { - primary ISIRI-3342:GL + primary ISIRI-3342:GL substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset ISIRI-3342:GR font ISIRI-3342:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISIRI-3342 diff --git a/nls/iso8859-1/XLC_LOCALE.pre b/nls/iso8859-1/XLC_LOCALE.pre index 11772b80..716f9e05 100644 --- a/nls/iso8859-1/XLC_LOCALE.pre +++ b/nls/iso8859-1/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -15,7 +15,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-1:GR @@ -26,9 +26,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-1 diff --git a/nls/iso8859-10/XLC_LOCALE.pre b/nls/iso8859-10/XLC_LOCALE.pre index e6fc488b..28d4b7a2 100644 --- a/nls/iso8859-10/XLC_LOCALE.pre +++ b/nls/iso8859-10/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-4. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-10:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-10 diff --git a/nls/iso8859-11/XLC_LOCALE.pre b/nls/iso8859-11/XLC_LOCALE.pre index ee5073de..6b5e63a1 100644 --- a/nls/iso8859-11/XLC_LOCALE.pre +++ b/nls/iso8859-11/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-11. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-11:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-11 diff --git a/nls/iso8859-13/XLC_LOCALE.pre b/nls/iso8859-13/XLC_LOCALE.pre index 82a5a0a2..3196cc5b 100644 --- a/nls/iso8859-13/XLC_LOCALE.pre +++ b/nls/iso8859-13/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-13. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-13:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-13 diff --git a/nls/iso8859-14/XLC_LOCALE.pre b/nls/iso8859-14/XLC_LOCALE.pre index 05bbd245..d39b22da 100644 --- a/nls/iso8859-14/XLC_LOCALE.pre +++ b/nls/iso8859-14/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-14. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-14:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-14 diff --git a/nls/iso8859-15/XLC_LOCALE.pre b/nls/iso8859-15/XLC_LOCALE.pre index 09ce32d3..b0482bc1 100644 --- a/nls/iso8859-15/XLC_LOCALE.pre +++ b/nls/iso8859-15/XLC_LOCALE.pre @@ -4,14 +4,14 @@ XCOMM then this file will be renamed iso8859-15. XCOMM This file is provided as preliminary support for the Latin-9 XCOMM (a.k.a. Latin-0) character set so that Europeans who want XCOMM the Euro currency character can do so. -XCOMM -XCOMM +XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -22,7 +22,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-15:GR @@ -33,9 +33,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-15 diff --git a/nls/iso8859-2/Compose.pre b/nls/iso8859-2/Compose.pre index 876e82c6..0752d2ab 100644 --- a/nls/iso8859-2/Compose.pre +++ b/nls/iso8859-2/Compose.pre @@ -458,7 +458,7 @@ XCOMM traditional sequences : "\342" acircumflex : "\356" icircumflex : "\364" ocircumflex - : "\373" ucircumflex + : "\373" ucircumflex : "\136" asciicircum : "\136" asciicircum : "\136" asciicircum @@ -478,7 +478,7 @@ XCOMM traditional sequences : "\261" aogonek : "\347" iogonek : "\352" eogonek - : "\371" uogonek + : "\371" uogonek : "\662" ogonek : "\662" ogonek : "\662" ogonek diff --git a/nls/iso8859-2/XLC_LOCALE.pre b/nls/iso8859-2/XLC_LOCALE.pre index d7c6170d..fe3dcd49 100644 --- a/nls/iso8859-2/XLC_LOCALE.pre +++ b/nls/iso8859-2/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-2. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-2:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-2 diff --git a/nls/iso8859-3/XLC_LOCALE.pre b/nls/iso8859-3/XLC_LOCALE.pre index 5a79380f..7c8b24ac 100644 --- a/nls/iso8859-3/XLC_LOCALE.pre +++ b/nls/iso8859-3/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-3. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-3:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-3 diff --git a/nls/iso8859-4/XLC_LOCALE.pre b/nls/iso8859-4/XLC_LOCALE.pre index c349a6f8..a18078a4 100644 --- a/nls/iso8859-4/XLC_LOCALE.pre +++ b/nls/iso8859-4/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-4. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-4:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-4 diff --git a/nls/iso8859-5/XLC_LOCALE.pre b/nls/iso8859-5/XLC_LOCALE.pre index f271c6d5..2a282e04 100644 --- a/nls/iso8859-5/XLC_LOCALE.pre +++ b/nls/iso8859-5/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-5. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-5:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-5 diff --git a/nls/iso8859-6/XLC_LOCALE.pre b/nls/iso8859-6/XLC_LOCALE.pre index c2a5107f..31c43510 100644 --- a/nls/iso8859-6/XLC_LOCALE.pre +++ b/nls/iso8859-6/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-6. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-6:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-6 diff --git a/nls/iso8859-7/XLC_LOCALE.pre b/nls/iso8859-7/XLC_LOCALE.pre index e1099ba2..67537d06 100644 --- a/nls/iso8859-7/XLC_LOCALE.pre +++ b/nls/iso8859-7/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-7. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-7:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-7 diff --git a/nls/iso8859-8/XLC_LOCALE.pre b/nls/iso8859-8/XLC_LOCALE.pre index 7c4ed314..6fa3e7f9 100644 --- a/nls/iso8859-8/XLC_LOCALE.pre +++ b/nls/iso8859-8/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-8. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-8:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-8 diff --git a/nls/iso8859-9/XLC_LOCALE.pre b/nls/iso8859-9/XLC_LOCALE.pre index 2e0e66b0..ee6fd297 100644 --- a/nls/iso8859-9/XLC_LOCALE.pre +++ b/nls/iso8859-9/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-9. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-9:GR @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-9 diff --git a/nls/iso8859-9e/XLC_LOCALE.pre b/nls/iso8859-9e/XLC_LOCALE.pre index 8c252f1a..459d78a4 100644 --- a/nls/iso8859-9e/XLC_LOCALE.pre +++ b/nls/iso8859-9e/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for iso8859-9e. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name ISO8859-9E:GR @@ -39,9 +39,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ISO8859-9E diff --git a/nls/ja.JIS/XLC_LOCALE.pre b/nls/ja.JIS/XLC_LOCALE.pre index be037774..a6b8115d 100644 --- a/nls/ja.JIS/XLC_LOCALE.pre +++ b/nls/ja.JIS/XLC_LOCALE.pre @@ -1,10 +1,10 @@ -XCOMM +XCOMM XCOMM XLocale Database Sample for ja_JP.jis -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -49,9 +49,9 @@ XCOMM } XCOMM } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ja.jis diff --git a/nls/ja.SJIS/XLC_LOCALE.pre b/nls/ja.SJIS/XLC_LOCALE.pre index be320cba..1b8031ef 100644 --- a/nls/ja.SJIS/XLC_LOCALE.pre +++ b/nls/ja.SJIS/XLC_LOCALE.pre @@ -1,11 +1,11 @@ -XCOMM +XCOMM XCOMM XLocale Database Sample for ja_JP.sjis -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -50,9 +50,9 @@ XCOMM } XCOMM } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ja.sjis diff --git a/nls/ja/XLC_LOCALE.pre b/nls/ja/XLC_LOCALE.pre index 0e205a47..b856dfe5 100644 --- a/nls/ja/XLC_LOCALE.pre +++ b/nls/ja/XLC_LOCALE.pre @@ -1,10 +1,10 @@ XCOMM -XCOMM XLocale Database Sample for ja_JP.euc -XCOMM +XCOMM XLocale Database Sample for ja_JP.euc +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -51,9 +51,9 @@ XCOMM } XCOMM } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ja.euc diff --git a/nls/ja_JP.UTF-8/XLC_LOCALE.pre b/nls/ja_JP.UTF-8/XLC_LOCALE.pre index 0f5ebe29..3c453d8c 100644 --- a/nls/ja_JP.UTF-8/XLC_LOCALE.pre +++ b/nls/ja_JP.UTF-8/XLC_LOCALE.pre @@ -1,8 +1,8 @@ -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -87,9 +87,9 @@ fs6 { END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -125,14 +125,14 @@ cs3 { ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR; KSC5601.1987-1:GL; KSC5601.1987-1:GR } - + XCOMM cs4 class cs4 { side GR length 2 ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR } - + XCOMM cs5 class cs5 { side GR diff --git a/nls/ko/XLC_LOCALE.pre b/nls/ko/XLC_LOCALE.pre index dc79e661..d3ee10a8 100644 --- a/nls/ko/XLC_LOCALE.pre +++ b/nls/ko/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for ko. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name KSC5601.1987-0:GL @@ -27,9 +27,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name ko.euc diff --git a/nls/ko_KR.UTF-8/XLC_LOCALE.pre b/nls/ko_KR.UTF-8/XLC_LOCALE.pre index b3db89da..32c7da9d 100644 --- a/nls/ko_KR.UTF-8/XLC_LOCALE.pre +++ b/nls/ko_KR.UTF-8/XLC_LOCALE.pre @@ -1,7 +1,7 @@ -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -85,9 +85,9 @@ fs6 { END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -115,7 +115,7 @@ cs2 { ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR; KSC5601.1987-1:GL; KSC5601.1987-1:GR } - + XCOMM cs3 class cs3 { side GR @@ -123,14 +123,14 @@ cs3 { ct_encoding JISX0208.1983-0:GL; JISX0208.1983-0:GR; JISX0208.1983-1:GL; JISX0208.1983-1:GR } - + XCOMM cs4 class cs4 { side GR length 2 ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR } - + XCOMM cs5 class cs5 { side GR diff --git a/nls/koi8-c/XLC_LOCALE.pre b/nls/koi8-c/XLC_LOCALE.pre index adf5db0b..e4c80f1f 100644 --- a/nls/koi8-c/XLC_LOCALE.pre +++ b/nls/koi8-c/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for koi8-c. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset KOI8-C:GR font KOI8-C:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name KOI8-C diff --git a/nls/koi8-r/XLC_LOCALE.pre b/nls/koi8-r/XLC_LOCALE.pre index 1c487d78..96309ce7 100644 --- a/nls/koi8-r/XLC_LOCALE.pre +++ b/nls/koi8-r/XLC_LOCALE.pre @@ -1,10 +1,10 @@ XCOMM XLocale Database Sample for koi8-r. -XCOMM -XCOMM +XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -16,7 +16,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset KOI8-R:GR font KOI8-R:GR @@ -36,9 +36,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name KOI8-R diff --git a/nls/koi8-u/XLC_LOCALE.pre b/nls/koi8-u/XLC_LOCALE.pre index 0516d98e..4e5bd071 100644 --- a/nls/koi8-u/XLC_LOCALE.pre +++ b/nls/koi8-u/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for koi8-u. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset KOI8-U:GR font KOI8-U:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name KOI8-U diff --git a/nls/locale.alias.pre b/nls/locale.alias.pre index 810067e3..d9f77d7c 100644 --- a/nls/locale.alias.pre +++ b/nls/locale.alias.pre @@ -1207,7 +1207,7 @@ thai: th_TH.ISO8859-11 univ.utf8: en_US.UTF-8 XCOMM Digital Unix utf universal.utf8@ucs4: en_US.UTF-8 -XCOMM Solaris and SunOS have iso_8859_1 and iso_8859_15 LC_CTYPES +XCOMM Solaris and SunOS have iso_8859_1 and iso_8859_15 LC_CTYPES XCOMM to augment LANG=C iso_8859_1: en_US.ISO8859-1 iso_8859_15: en_US.ISO8859-15 diff --git a/nls/microsoft-cp1251/XLC_LOCALE.pre b/nls/microsoft-cp1251/XLC_LOCALE.pre index c96d9085..06c04b16 100644 --- a/nls/microsoft-cp1251/XLC_LOCALE.pre +++ b/nls/microsoft-cp1251/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for microsoft-cp1251. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name MICROSOFT-CP1251:GR @@ -40,9 +40,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name MICROSOFT-CP1251 diff --git a/nls/microsoft-cp1255/XLC_LOCALE.pre b/nls/microsoft-cp1255/XLC_LOCALE.pre index c1b009ba..bd2a8945 100644 --- a/nls/microsoft-cp1255/XLC_LOCALE.pre +++ b/nls/microsoft-cp1255/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for microsoft-cp1255. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name MICROSOFT-CP1255:GR @@ -40,9 +40,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name MICROSOFT-CP1255 diff --git a/nls/microsoft-cp1256/XLC_LOCALE.pre b/nls/microsoft-cp1256/XLC_LOCALE.pre index 6165feed..7a2331b7 100644 --- a/nls/microsoft-cp1256/XLC_LOCALE.pre +++ b/nls/microsoft-cp1256/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for microsoft-cp1256. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name MICROSOFT-CP1256:GR @@ -40,9 +40,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name MICROSOFT-CP1256 diff --git a/nls/mulelao-1/XLC_LOCALE.pre b/nls/mulelao-1/XLC_LOCALE.pre index 24af6d8c..99249736 100644 --- a/nls/mulelao-1/XLC_LOCALE.pre +++ b/nls/mulelao-1/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for mulelao-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset MULELAO-1:GR font MULELAO-1:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name MULELAO-1 diff --git a/nls/nokhchi-1/XLC_LOCALE.pre b/nls/nokhchi-1/XLC_LOCALE.pre index 6f231cde..f1625975 100644 --- a/nls/nokhchi-1/XLC_LOCALE.pre +++ b/nls/nokhchi-1/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for mulelao-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -11,11 +11,11 @@ fs0 { name ISO8859-1:GL } font { - primary NOKHCHI-1:GL + primary NOKHCHI-1:GL substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset NOKHCHI-1:GR font NOKHCHI-1:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name NOKHCHI-1 diff --git a/nls/pt_BR.UTF-8/XLC_LOCALE.pre b/nls/pt_BR.UTF-8/XLC_LOCALE.pre index e53dd508..1cd5f417 100644 --- a/nls/pt_BR.UTF-8/XLC_LOCALE.pre +++ b/nls/pt_BR.UTF-8/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for pt_BR.UTF-8 XCOMM XCOMM Based on XLocale Database Sample for en_US.UTF-8 -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -80,9 +80,9 @@ fs6 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -102,7 +102,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side GR @@ -118,14 +118,14 @@ cs3 { ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR;\ KSC5601.1987-1:GL; KSC5601.1987-1:GR } - + XCOMM cs4 class cs4 { side GR length 2 ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR } - + XCOMM cs5 class cs5 { side GR diff --git a/nls/pt_PT.UTF-8/XLC_LOCALE.pre b/nls/pt_PT.UTF-8/XLC_LOCALE.pre index 115621f2..434c7062 100644 --- a/nls/pt_PT.UTF-8/XLC_LOCALE.pre +++ b/nls/pt_PT.UTF-8/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for pt_PT.UTF-8 XCOMM XCOMM Based on XLocale Database Sample for en_US.UTF-8 -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -80,9 +80,9 @@ fs6 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -102,7 +102,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side GR @@ -118,14 +118,14 @@ cs3 { ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR;\ KSC5601.1987-1:GL; KSC5601.1987-1:GR } - + XCOMM cs4 class cs4 { side GR length 2 ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR } - + XCOMM cs5 class cs5 { side GR diff --git a/nls/tatar-cyr/XLC_LOCALE.pre b/nls/tatar-cyr/XLC_LOCALE.pre index c7c5581f..3933d5b6 100644 --- a/nls/tatar-cyr/XLC_LOCALE.pre +++ b/nls/tatar-cyr/XLC_LOCALE.pre @@ -1,11 +1,11 @@ XCOMM XLocale Database Sample for tatar-cyr. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET -XCOMM fs0 class +XCOMM fs0 class fs0 { charset { name ISO8859-1:GL @@ -16,7 +16,7 @@ fs0 { vertical_rotate all } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset { name TATAR-CYR:GR @@ -40,9 +40,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name TATAR-CYR diff --git a/nls/th_TH.UTF-8/XLC_LOCALE.pre b/nls/th_TH.UTF-8/XLC_LOCALE.pre index 6f766430..e8e962fb 100644 --- a/nls/th_TH.UTF-8/XLC_LOCALE.pre +++ b/nls/th_TH.UTF-8/XLC_LOCALE.pre @@ -3,9 +3,9 @@ XCOMM XCOMM XCOMM Modified from original th_TH.TACTIS -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class fs0 { @@ -23,16 +23,16 @@ fs1 { charset ISO8859-1:GL font ISO8859-1:GL } -XCOMM fs1 class (Thai) +XCOMM fs1 class (Thai) fs2 { charset ISO8859-11:GR font ISO8859-11:GR } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 diff --git a/nls/th_TH/XLC_LOCALE.pre b/nls/th_TH/XLC_LOCALE.pre index b2de6334..21818a42 100644 --- a/nls/th_TH/XLC_LOCALE.pre +++ b/nls/th_TH/XLC_LOCALE.pre @@ -3,25 +3,25 @@ XCOMM XCOMM XCOMM Modified from original th_TH.TACTIS -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { charset ISO8859-1:GL font ISO8859-1:GL } -XCOMM fs1 class (Thai) +XCOMM fs1 class (Thai) fs1 { charset ISO8859-11:GR font ISO8859-11:GR } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name TIS620 diff --git a/nls/tscii-0/XLC_LOCALE.pre b/nls/tscii-0/XLC_LOCALE.pre index bffffe49..2a18a074 100644 --- a/nls/tscii-0/XLC_LOCALE.pre +++ b/nls/tscii-0/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for mulelao-1. -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset TSCII-0:GR font TSCII-0:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name TSCII-0 diff --git a/nls/vi_VN.tcvn/XLC_LOCALE.pre b/nls/vi_VN.tcvn/XLC_LOCALE.pre index 90324fd3..88ef21ae 100644 --- a/nls/vi_VN.tcvn/XLC_LOCALE.pre +++ b/nls/vi_VN.tcvn/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for vi_VN.TCVN -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset TCVN-5712:GR font TCVN-5712:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name TCVN-5712 diff --git a/nls/vi_VN.viscii/XLC_LOCALE.pre b/nls/vi_VN.viscii/XLC_LOCALE.pre index 730996bb..1383ea09 100644 --- a/nls/vi_VN.viscii/XLC_LOCALE.pre +++ b/nls/vi_VN.viscii/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for vi_VN.VISCII -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -15,7 +15,7 @@ fs0 { substitute ISO8859-1:GL } } -XCOMM fs1 class +XCOMM fs1 class fs1 { charset VISCII1.1-1:GR font VISCII1.1-1:GR @@ -35,9 +35,9 @@ csd0 { } END XLC_CHARSET_DEFINE -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name VISCII1.1-1 diff --git a/nls/zh_CN.UTF-8/XLC_LOCALE.pre b/nls/zh_CN.UTF-8/XLC_LOCALE.pre index 6f05d7a8..23bf50b3 100644 --- a/nls/zh_CN.UTF-8/XLC_LOCALE.pre +++ b/nls/zh_CN.UTF-8/XLC_LOCALE.pre @@ -3,9 +3,9 @@ XCOMM Modified from xc/nls/XLC_LOCALE/en_US.UTF-8 XCOMM by James Su XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -67,9 +67,9 @@ fs4 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -89,7 +89,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side GR diff --git a/nls/zh_CN.gb18030/XLC_LOCALE.pre b/nls/zh_CN.gb18030/XLC_LOCALE.pre index f9544c70..d920e5a6 100644 --- a/nls/zh_CN.gb18030/XLC_LOCALE.pre +++ b/nls/zh_CN.gb18030/XLC_LOCALE.pre @@ -2,9 +2,9 @@ XCOMM XFree86 NLS for Chinese encoding GB18030 XCOMM Modified from xc/nls/XLC_LOCALE/en_US.UTF-8 XCOMM by James Su -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -67,9 +67,9 @@ fs4 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name GB18030 @@ -89,7 +89,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side GR diff --git a/nls/zh_CN.gbk/XLC_LOCALE.pre b/nls/zh_CN.gbk/XLC_LOCALE.pre index 302818bc..b228ec8f 100644 --- a/nls/zh_CN.gbk/XLC_LOCALE.pre +++ b/nls/zh_CN.gbk/XLC_LOCALE.pre @@ -1,12 +1,12 @@ -XCOMM +XCOMM XCOMM X11R6 L10N for Chinese GBK Encoding. XCOMM modified from xc/nls/XLC_LOCALE/zh_TW.Big5 XCOMM by Sean Chen -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -30,9 +30,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name zh_CN.GBK diff --git a/nls/zh_HK.UTF-8/XLC_LOCALE.pre b/nls/zh_HK.UTF-8/XLC_LOCALE.pre index c0880325..b3d689da 100644 --- a/nls/zh_HK.UTF-8/XLC_LOCALE.pre +++ b/nls/zh_HK.UTF-8/XLC_LOCALE.pre @@ -2,9 +2,9 @@ XCOMM XFree86 NLS for Chinese locale zh_HK.UTF-8 XCOMM Modified from xc/nls/XLC_LOCALE/en_US.UTF-8 XCOMM by James Su -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -56,9 +56,9 @@ fs3 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -78,7 +78,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side none diff --git a/nls/zh_HK.big5/XLC_LOCALE.pre b/nls/zh_HK.big5/XLC_LOCALE.pre index 03f9d08f..e5fd54a5 100644 --- a/nls/zh_HK.big5/XLC_LOCALE.pre +++ b/nls/zh_HK.big5/XLC_LOCALE.pre @@ -1,11 +1,11 @@ -XCOMM +XCOMM XCOMM (c) 1996, X11R6 L10N for Taiwan and Big5 Encoding Project -XCOMM +XCOMM XCOMM modified for X11R6.3 by Hung-Chi Chu 1998/01/10 -XCOMM +XCOMM XCOMM XLC_FONTSET category XCOMM -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -29,9 +29,9 @@ fs1 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name zh_HK.Big5 diff --git a/nls/zh_HK.big5hkscs/XLC_LOCALE.pre b/nls/zh_HK.big5hkscs/XLC_LOCALE.pre index dc19438d..03a0a07b 100644 --- a/nls/zh_HK.big5hkscs/XLC_LOCALE.pre +++ b/nls/zh_HK.big5hkscs/XLC_LOCALE.pre @@ -2,7 +2,7 @@ XCOMM XCOMM (c) 1996, X11R6 L10N for Taiwan and Big5 Encoding Project XCOMM XCOMM modified for X11R6.3 by Hung-Chi Chu 1998/01/10 -XCOMM modified for Big5HKSCS by Roger So +XCOMM modified for Big5HKSCS by Roger So XCOMM XCOMM XCOMM XLC_FONTSET category diff --git a/nls/zh_TW.UTF-8/XLC_LOCALE.pre b/nls/zh_TW.UTF-8/XLC_LOCALE.pre index d5b19c03..28a1cec9 100644 --- a/nls/zh_TW.UTF-8/XLC_LOCALE.pre +++ b/nls/zh_TW.UTF-8/XLC_LOCALE.pre @@ -1,9 +1,9 @@ XCOMM XLocale Database Sample for zh_TW.UTF-8 -XCOMM +XCOMM -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET on_demand_loading True @@ -52,9 +52,9 @@ fs3 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name UTF-8 @@ -74,7 +74,7 @@ cs1 { length 1 ct_encoding ISO8859-1:GR } - + XCOMM cs2 class cs2 { side none diff --git a/nls/zh_TW/XLC_LOCALE.pre b/nls/zh_TW/XLC_LOCALE.pre index ffbb462e..cd797848 100644 --- a/nls/zh_TW/XLC_LOCALE.pre +++ b/nls/zh_TW/XLC_LOCALE.pre @@ -1,5 +1,5 @@ XCOMM XLocale Database Sample for zh_TW -XCOMM +XCOMM XCOMM Note: In lib/X11/lcCT.c, charset names for CNS11643 coded character XCOMM sets are defined as CNS11643.1986-1 and -2. In the ECMA Registry, XCOMM CNS coded character sets 1-7 are registered as CNS 11643-1992. @@ -10,9 +10,9 @@ XCOMM X11R6 organization of fsN/csN as it is and only changed "CNS11643-*" XCOMM to "CNS11643.1986-*". XCOMM 1995-10-24 T. Numata (numa@rp.open.cs.fujitsu.co.jp) -XCOMM +XCOMM XCOMM XLC_FONTSET category -XCOMM +XCOMM XLC_FONTSET XCOMM fs0 class (7 bit ASCII) fs0 { @@ -42,7 +42,7 @@ fs2 { primary CNS11643.1986-2:GL } } -XCOMM fs3 class +XCOMM fs3 class fs3 { charset { name CNS11643.1986-14:GL @@ -51,7 +51,7 @@ fs3 { primary CNS11643.1986-14:GL } } -XCOMM fs4 class +XCOMM fs4 class fs4 { charset { name CNS11643.1986-15:GL @@ -60,7 +60,7 @@ fs4 { primary CNS11643.1986-15:GL } } -XCOMM fs5 class +XCOMM fs5 class fs5 { charset { name CNS11643.1986-16:GL @@ -71,9 +71,9 @@ fs5 { } END XLC_FONTSET -XCOMM +XCOMM XCOMM XLC_XLOCALE category -XCOMM +XCOMM XLC_XLOCALE encoding_name zh_TW.euc diff --git a/specs/i18n/trans/trans.xml b/specs/i18n/trans/trans.xml index 68611ea3..e672bbb4 100644 --- a/specs/i18n/trans/trans.xml +++ b/specs/i18n/trans/trans.xml @@ -30,7 +30,7 @@ which makes various channels usable such as X protocol or TCP/IP, DECnet and etc -Permission to use, copy, modify, and distribute this documentation for any purpose +Permission to use, copy, modify, and distribute this documentation for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. Fujitsu makes no representations about the suitability for any purpose of the diff --git a/specs/libX11/AppC.xml b/specs/libX11/AppC.xml index c787a8f0..4cefe7aa 100644 --- a/specs/libX11/AppC.xml +++ b/specs/libX11/AppC.xml @@ -5,19 +5,19 @@ Extensions -Because X can evolve by extensions to the core protocol, +Because X can evolve by extensions to the core protocol, it is important that extensions not be perceived as second-class citizens. -At some point, -your favorite extensions may be adopted as additional parts of the +At some point, +your favorite extensions may be adopted as additional parts of the X Standard. -Therefore, there should be little to distinguish the use of an extension from +Therefore, there should be little to distinguish the use of an extension from that of the core protocol. -To avoid having to initialize extensions explicitly in application programs, +To avoid having to initialize extensions explicitly in application programs, it is also important that extensions perform lazy evaluations, -automatically initializing themselves when called for the first time. +automatically initializing themselves when called for the first time. @@ -41,7 +41,7 @@ The symbols and macros used for writing stubs to Xlib are listed in Basic Protocol Support Routines -The basic protocol requests for extensions are +The basic protocol requests for extensions are and . @@ -97,7 +97,7 @@ and The -function determines if the named extension is present. +function determines if the named extension is present. If the extension is not present, returns @@ -110,18 +110,18 @@ returns the major opcode for the extension to major_opcode_return; otherwise, it returns zero. Any minor opcode and the request formats are specific to the -extension. -If the extension involves additional event types, +extension. +If the extension involves additional event types, returns the base event type code to first_event_return; -otherwise, -it returns zero. -The format of the events is specific to the extension. -If the extension involves additional error codes, +otherwise, +it returns zero. +The format of the events is specific to the extension. +If the extension involves additional error codes, returns the base error code to first_error_return; -otherwise, -it returns zero. +otherwise, +it returns zero. The format of additional data in the errors is specific to the extension. @@ -129,7 +129,7 @@ The format of additional data in the errors is specific to the extension. If the extension name is not in the Host Portable Character Encoding the result is implementation-dependent. Uppercase and lowercase matter; -the strings ``thing'', ``Thing'', and ``thinG'' +the strings ``thing'', ``Thing'', and ``thinG'' are all considered different names. XListExtensions @@ -200,7 +200,7 @@ Specifies the list of extension names. The -function frees the memory allocated by +function frees the memory allocated by . @@ -208,8 +208,8 @@ function frees the memory allocated by Hooking into Xlib -These functions allow you to hook into the library. -They are not normally used by application programmers but are used +These functions allow you to hook into the library. +They are not normally used by application programmers but are used by people who need to extend the core X protocol and the X library interface. The functions, which generate protocol requests for X, are typically @@ -217,24 +217,24 @@ called stubs. -In extensions, stubs first should check to see if they have initialized +In extensions, stubs first should check to see if they have initialized themselves on a connection. -If they have not, they then should call +If they have not, they then should call to attempt to initialize themselves on the connection. If the extension needs to be informed of GC/font allocation or -deallocation or if the extension defines new event types, -the functions described here allow the extension to be +deallocation or if the extension defines new event types, +the functions described here allow the extension to be called when these events occur. The XExtCodes -structure returns the information from +structure returns the information from and is defined in <X11/Xlib.h>: @@ -293,9 +293,9 @@ Specifies the extension name. The -function determines if the named extension exists. -Then, it allocates storage for maintaining the -information about the extension on the connection, +function determines if the named extension exists. +Then, it allocates storage for maintaining the +information about the extension on the connection, chains this onto the extension list for the connection, and returns the information the stub implementor will need to access the extension. @@ -308,15 +308,15 @@ returns NULL. If the extension name is not in the Host Portable Character Encoding, the result is implementation-dependent. Uppercase and lowercase matter; -the strings ``thing'', ``Thing'', and ``thinG'' +the strings ``thing'', ``Thing'', and ``thinG'' are all considered different names. -The extension number in the +The extension number in the XExtCodes structure is -needed in the other calls that follow. +needed in the other calls that follow. This extension number is unique only to a single connection. @@ -418,15 +418,15 @@ The function defines a procedure to be called whenever XCloseDisplay -is called. +is called. It returns any previously defined procedure, usually NULL. -When +When XCloseDisplay -is called, -your procedure is called +is called, +your procedure is called with these arguments: @@ -485,12 +485,12 @@ Specifies the procedure to call when a GC is closed. The function defines a procedure to be called whenever -a new GC is created. +a new GC is created. It returns any previously defined procedure, usually NULL. -When a GC is created, +When a GC is created, your procedure is called with these arguments: @@ -552,12 +552,12 @@ Specifies the procedure to call when GC components are copied. The function defines a procedure to be called whenever -a GC is copied. +a GC is copied. It returns any previously defined procedure, usually NULL. -When a GC is copied, +When a GC is copied, your procedure is called with these arguments: @@ -614,12 +614,12 @@ Specifies the procedure to call when a GC is freed. The function defines a procedure to be called whenever -a GC is freed. +a GC is freed. It returns any previously defined procedure, usually NULL. -When a GC is freed, +When a GC is freed, your procedure is called with these arguments: @@ -689,16 +689,16 @@ function defines a procedure to be called whenever and -are called. +are called. It returns any previously defined procedure, usually NULL. -When +When or -is called, +is called, your procedure is called with these arguments: @@ -766,12 +766,12 @@ The function defines a procedure to be called whenever -is called. +is called. It returns any previously defined procedure, usually NULL. -When +When is called, your procedure is called with these arguments: @@ -791,12 +791,12 @@ is called, your procedure is called with these arguments: -The +The and functions allow you to define new events to the library. -An +An XEvent structure always has a type code (type int) @@ -877,9 +877,9 @@ Specifies the procedure to call when converting an event. The function defines a procedure to be called when an event -needs to be converted from wire format +needs to be converted from wire format (xEvent) -to host format +to host format (XEvent). The event number defines which protocol event number to install a conversion procedure for. @@ -888,7 +888,7 @@ returns any previously defined procedure. You can replace a core event conversion function with one of your own, although this is not encouraged. -It would, however, allow you to intercept a core event +It would, however, allow you to intercept a core event and modify it before being placed in the queue or otherwise examined. When Xlib needs to convert an event from wire format to host @@ -911,19 +911,19 @@ format, your procedure is called with these arguments: Your procedure must return status to indicate if the conversion succeeded. The re argument is a pointer to where the host format event should be stored, and the event argument is the 32-byte wire event structure. -In the +In the XEvent -structure you are creating, +structure you are creating, you must fill in the five required members of the event structure. -You should fill in the type member with the type specified for the +You should fill in the type member with the type specified for the xEvent structure. -You should copy all other members from the +You should copy all other members from the xEvent structure (wire format) to the XEvent structure (host format). -Your conversion procedure should return +Your conversion procedure should return True if the event should be placed in the queue or False @@ -1031,7 +1031,7 @@ needs to be converted from host format (XEvent) to wire format (xEvent) -form. +form. The event number defines which protocol event number to install a conversion procedure for. @@ -1039,11 +1039,11 @@ returns any previously defined procedure. It returns zero if the conversion fails or nonzero otherwise. You can replace a core event conversion function with one -of your own, although this is not encouraged. -It would, however, allow you to intercept a core event +of your own, although this is not encouraged. +It would, however, allow you to intercept a core event and modify it before being sent to another client. -When Xlib needs to convert an event from host format to wire format, +When Xlib needs to convert an event from host format to wire format, your procedure is called with these arguments: @@ -1061,12 +1061,12 @@ your procedure is called with these arguments: The re argument is a pointer to the host format event, -and the event argument is a pointer to where the 32-byte wire event +and the event argument is a pointer to where the 32-byte wire event structure should be stored. -You should fill in the type with the type from the +You should fill in the type with the type from the XEvent structure. -All other members then should be copied from the host format to the +All other members then should be copied from the host format to the xEvent structure. @@ -1219,7 +1219,7 @@ case, and are typically programmed to be synchronous). -When Xlib detects a protocol error in +When Xlib detects a protocol error in , it calls your procedure with these arguments: @@ -1240,19 +1240,19 @@ it calls your procedure with these arguments: The err argument is a pointer to the 32-byte wire format error. The codes argument is a pointer to the extension codes structure. -The ret_code argument is the return code you may want +The ret_code argument is the return code you may want returned to. -If your procedure returns a zero value, -the error is not suppressed, and +If your procedure returns a zero value, +the error is not suppressed, and the client's error handler is called. (For further information, see section 11.8.2.) -If your procedure returns nonzero, -the error is suppressed, and +If your procedure returns nonzero, +the error is suppressed, and returns the value of ret_code. @@ -1302,7 +1302,7 @@ Specifies the procedure to call to obtain an error string. -The +The function returns a string to the user for an error. @@ -1515,7 +1515,7 @@ Specifies the procedure to call when a buffer is flushed. The XESetBeforeFlush function defines a procedure to be called when data is about to be -sent to the server. When data is about to be sent, your procedure is +sent to the server. When data is about to be sent, your procedure is called one or more times with these arguments: @@ -1551,16 +1551,16 @@ These structures are Screen, ScreenFormat, Display, -and +and XFontStruct. -Because the list pointer is always the first member in the structure, +Because the list pointer is always the first member in the structure, a single set of procedures can be used to manipulate the data on these lists. The following structure is used in the functions in this section -and is defined in +and is defined in <X11/Xlib.h> @@ -1581,11 +1581,11 @@ typedef struct _XExtData { -When any of the data structures listed above are freed, -the list is walked, and the structure's free procedure (if any) is called. -If free is NULL, +When any of the data structures listed above are freed, +the list is walked, and the structure's free procedure (if any) is called. +If free is NULL, then the library frees both the data pointed to by the private_data member -and the structure itself. +and the structure itself. @@ -1631,7 +1631,7 @@ The function returns a pointer to the list of extension structures attached to the specified object. -In concert with +In concert with , allows an extension to attach arbitrary data to any of the structures @@ -1725,9 +1725,9 @@ There is no way to find additional structures. -The +The -macro, which allocates and returns a resource ID, is defined in +macro, which allocates and returns a resource ID, is defined in <X11/Xlib.h>. XAllocID @@ -1754,14 +1754,14 @@ Specifies the connection to the X server. -This macro is a call through the +This macro is a call through the Display structure to an internal resource ID allocator. It returns a resource ID that you can use when creating new resources. -The +The macro allocates and returns an array of resource ID. @@ -1811,7 +1811,7 @@ Specifies the number of resource IDs requested. -This macro is a call through the +This macro is a call through the Display structure to an internal resource ID allocator. It returns resource IDs to the array supplied by the caller. @@ -1835,7 +1835,7 @@ in its GC. -The +The macro checks the dirty bits in the library's GC structure and calls @@ -1887,7 +1887,7 @@ forcing a protocol request, the resource might be destroyed before being set into the GC. You can use the -procedure +procedure to force the cache to be flushed. The @@ -1934,20 +1934,20 @@ Specifies the GC. If you extend X to add more poly graphics primitives, you may be able to -take advantage of facilities in the library to allow back-to-back +take advantage of facilities in the library to allow back-to-back single calls to be transformed into poly requests. This may dramatically improve performance of programs that are not -written using poly requests. -A pointer to an +written using poly requests. +A pointer to an xReq, -called last_req in the display structure, is the last request being processed. +called last_req in the display structure, is the last request being processed. By checking that the last request type, drawable, gc, and other options are the same as the new one and that there is enough space left in the buffer, you may be able to just extend the previous graphics request by extending the length -field of the request and appending the data to the buffer. -This can improve performance by five times or more in naive programs. -For example, here is the source for the +field of the request and appending the data to the buffer. +This can improve performance by five times or more in naive programs. +For example, here is the source for the stub. (Writing extension stubs is discussed in the next section.) @@ -2003,13 +2003,13 @@ XDrawPoint(dpy, d, gc, x, y) -To keep clients from generating very long requests that may monopolize the +To keep clients from generating very long requests that may monopolize the server, there is a symbol defined in <X11/Xlibint.h> of EPERBATCH on the number of requests batched. Most of the performance benefit occurs in the first few merged requests. -Note that +Note that is called before picking up the value of last_req, because it may modify this field. @@ -2034,33 +2034,33 @@ see Requests, Replies, and Xproto.h -The +The <X11/Xproto.h> file contains three sets of definitions that -are of interest to the stub implementor: +are of interest to the stub implementor: request names, request structures, and reply structures. -You need to generate a file equivalent to +You need to generate a file equivalent to <X11/Xproto.h> for your extension and need to include it in your stub procedure. -Each stub procedure also must include +Each stub procedure also must include <X11/Xlibint.h>. The identifiers are deliberately chosen in such a way that, if the request is called X_DoSomething, then its request structure is -xDoSomethingReq, and its reply is xDoSomethingReply. -The GetReq family of macros, defined in +xDoSomethingReq, and its reply is xDoSomethingReply. +The GetReq family of macros, defined in <X11/Xlibint.h>, takes advantage of this naming scheme. -For each X request, -there is a definition in +For each X request, +there is a definition in <X11/Xproto.h> that looks similar to this: @@ -2070,8 +2070,8 @@ that looks similar to this: #define X_DoSomething 42 -In your extension header file, -this will be a minor opcode, +In your extension header file, +this will be a minor opcode, instead of a major opcode. @@ -2080,18 +2080,18 @@ instead of a major opcode. Every request contains an 8-bit major opcode and a 16-bit length field -expressed in units of 4 bytes. +expressed in units of 4 bytes. Every request consists of 4 bytes of header (containing the major opcode, the length field, and a data byte) followed by -zero or more additional bytes of data. +zero or more additional bytes of data. The length field defines the total length of the request, including the header. -The length field in a request must equal the minimum length required to contain -the request. -If the specified length is smaller or larger than the required length, -the server should generate a +The length field in a request must equal the minimum length required to contain +the request. +If the specified length is smaller or larger than the required length, +the server should generate a BadLength error. -Unused bytes in a request are not required to be zero. +Unused bytes in a request are not required to be zero. Extensions should be designed in such a way that long protocol requests can be split up into smaller requests, if it is possible to exceed the maximum request size of the server. @@ -2101,9 +2101,9 @@ The protocol guarantees the maximum request size to be no smaller than Major opcodes 128 through 255 are reserved for extensions. -Extensions are intended to contain multiple requests, -so extension requests typically have an additional minor opcode encoded -in the second data byte in the request header, +Extensions are intended to contain multiple requests, +so extension requests typically have an additional minor opcode encoded +in the second data byte in the request header, but the placement and interpretation of this minor opcode as well as all other fields in extension requests are not defined by the core protocol. Every request is implicitly assigned a sequence number (starting with one) @@ -2135,13 +2135,13 @@ typedef struct _DoSomethingReq { -If a core protocol request has a single 32-bit argument, +If a core protocol request has a single 32-bit argument, you need not declare a request structure in your extension header file. Instead, such requests use the xResourceReq structure in <X11/Xproto.h>. -This structure is used for any request whose single argument is a +This structure is used for any request whose single argument is a Window, Pixmap, Drawable, @@ -2172,24 +2172,24 @@ typedef struct _ResourceReq { If convenient, -you can do something similar in your extension header file. +you can do something similar in your extension header file. -In both of these structures, -the reqType field identifies the type of the request (for example, -X_MapWindow or X_CreatePixmap). +In both of these structures, +the reqType field identifies the type of the request (for example, +X_MapWindow or X_CreatePixmap). The length field tells how long the request is -in units of 4-byte longwords. +in units of 4-byte longwords. This length includes both the request structure itself and any variable-length data, such as strings or lists, that follow the -request structure. -Request structures come in different sizes, +request structure. +Request structures come in different sizes, but all requests are padded to be multiples of four bytes long. -A few protocol requests take no arguments at all. +A few protocol requests take no arguments at all. Instead, they use the xReq structure in @@ -2198,7 +2198,7 @@ which contains only a reqType and a length (and a pad byte). -If the protocol request requires a reply, +If the protocol request requires a reply, then <X11/Xproto.h> also contains a reply structure typedef: @@ -2224,12 +2224,12 @@ typedef struct _DoSomethingReply { -Most of these reply structures are 32 bytes long. -If there are not that many reply values, +Most of these reply structures are 32 bytes long. +If there are not that many reply values, then they contain a sufficient number of pad fields -to bring them up to 32 bytes. -The length field is the total number of bytes in the request minus 32, -divided by 4. +to bring them up to 32 bytes. +The length field is the total number of bytes in the request minus 32, +divided by 4. This length will be nonzero only if: @@ -2247,7 +2247,7 @@ The reply structure is longer than 32 bytes. -Only +Only GetWindowAttributesl, QueryFont, QueryKeymap, @@ -2257,10 +2257,10 @@ have reply structures longer than 32 bytes in the core protocol. -A few protocol requests return replies that contain no data. +A few protocol requests return replies that contain no data. <X11/Xproto.h> does not define reply structures for these. -Instead, they use the +Instead, they use the xGenericReply structure, which contains only a type, length, and sequence number (and sufficient padding to make it 32 bytes long). @@ -2285,7 +2285,7 @@ XDoSomething (arguments, ... ) register XDoSomethingReq *req; ... -If the protocol request has a reply, +If the protocol request has a reply, then the variable declarations should include the reply structure for the request. The following is an example: @@ -2307,7 +2307,7 @@ each stub will need to lock its critical section. Generally, this section is the point from just before the appropriate GetReq call until all arguments to the call have been stored into the buffer. The precise instructions needed for this locking depend upon the machine -architecture. +architecture. Two calls, which are generally implemented as macros, have been provided. LockDisplay @@ -2347,30 +2347,30 @@ Specifies the connection to the X server. Sending the Protocol Request and Arguments -After the variable declarations, -a stub procedure should call one of four macros defined in +After the variable declarations, +a stub procedure should call one of four macros defined in <X11/Xlibint.h>: GetReq, GetReqExtra, GetResReq, -or +or GetEmptyReq. All of these macros take, as their first argument, -the name of the protocol request as declared in +the name of the protocol request as declared in <X11/Xproto.h> -except with X_ removed. -Each one declares a +except with X_ removed. +Each one declares a Display structure pointer, called dpy, and a pointer to a request structure, called req, which is of the appropriate type. -The macro then appends the request structure to the output buffer, +The macro then appends the request structure to the output buffer, fills in its type and length field, and sets req to point to it. If the protocol request has no arguments (for instance, X_GrabServer), -then use +then use GetEmptyReq. @@ -2385,9 +2385,9 @@ If the protocol request has a single 32-bit argument (such as a Drawable, Atom, and so on), -then use +then use GetResReq. -The second argument to the macro is the 32-bit object. +The second argument to the macro is the 32-bit object. X_MapWindow is a good example. @@ -2397,17 +2397,17 @@ is a good example. GetResReq (DoSomething, rid, req); -The rid argument is the +The rid argument is the Pixmap, Window, or other resource ID. -If the protocol request takes any other argument list, -then call +If the protocol request takes any other argument list, +then call GetReq. -After the +After the GetReq, you need to set all the other fields in the request structure, usually from arguments to the stub procedure. @@ -2422,15 +2422,15 @@ req->arg1 = arg1; req->arg2 = arg2; ... -A few stub procedures (such as +A few stub procedures (such as -and +and ) return a resource ID to the caller but pass a resource ID as an argument -to the protocol request. -Such procedures use the macro +to the protocol request. +Such procedures use the macro -to allocate a resource ID from the range of IDs +to allocate a resource ID from the range of IDs that were assigned to this client when it opened the connection. @@ -2442,21 +2442,21 @@ rid = req->rid = XAllocID(); return (rid); Finally, some stub procedures transmit a fixed amount of variable-length -data after the request. +data after the request. Typically, these procedures (such as -and +and ) -are special cases of more general functions like +are special cases of more general functions like -and +and . -These procedures use +These procedures use GetReqExtra, -which is the same as +which is the same as GetReq except that it takes an additional argument (the number of -extra bytes to allocate in the output buffer after the request structure). +extra bytes to allocate in the output buffer after the request structure). This number should always be a multiple of four. Note that it is possible for req to be set to NULL as a defensive measure if the requested length exceeds the Xlib's buffer size (normally 16K). @@ -2467,20 +2467,20 @@ exceeds the Xlib's buffer size (normally 16K). Some protocol requests take additional variable-length data that -follow the +follow the xDoSomethingReq -structure. -The format of this data varies from request to request. -Some requests require a sequence of 8-bit bytes, -others a sequence of 16-bit or 32-bit entities, +structure. +The format of this data varies from request to request. +Some requests require a sequence of 8-bit bytes, +others a sequence of 16-bit or 32-bit entities, and still others a sequence of structures. It is necessary to add the length of any variable-length data to the -length field of the request structure. -That length field is in units of 32-bit longwords. -If the data is a string or other sequence of 8-bit bytes, +length field of the request structure. +That length field is in units of 32-bit longwords. +If the data is a string or other sequence of 8-bit bytes, then you must round the length up and shift it before adding: @@ -2489,21 +2489,21 @@ then you must round the length up and shift it before adding: req->length += (nbytes+3)>>2; -To transmit variable-length data, use the +To transmit variable-length data, use the macros. -If the data fits into the output buffer, -then this macro copies it to the buffer. +If the data fits into the output buffer, +then this macro copies it to the buffer. If it does not fit, however, -the +the -macro calls +macro calls _XSend, which transmits first the contents of the buffer and then your data. -The +The -macros take three arguments: -the display, a pointer to the beginning of the data, +macros take three arguments: +the display, a pointer to the beginning of the data, and the number of bytes to be sent. @@ -2537,23 +2537,23 @@ and Data32 are macros that may use their last argument more than once, so that argument should be a variable rather than -an expression such as ``nitems*sizeof(item)''. -You should do that kind of computation in a separate statement before calling +an expression such as ``nitems*sizeof(item)''. +You should do that kind of computation in a separate statement before calling them. Use the appropriate macro when sending byte, short, or long data. -If the protocol request requires a reply, -then call the procedure +If the protocol request requires a reply, +then call the procedure _XSend -instead of the +instead of the -macro. +macro. _XSend -takes the same arguments, but because it sends your data immediately instead of +takes the same arguments, but because it sends your data immediately instead of copying it into the output buffer (which would later be flushed -anyway by the following call on +anyway by the following call on ), it is faster. @@ -2562,15 +2562,15 @@ it is faster. Replies -If the protocol request has a reply, -then call +If the protocol request has a reply, +then call -after you have finished dealing with -all the fixed-length and variable-length arguments. +after you have finished dealing with +all the fixed-length and variable-length arguments. -flushes the output buffer and waits for an +flushes the output buffer and waits for an xReply -packet to arrive. +packet to arrive. If any events arrive in the meantime, places them in the queue for later use. @@ -2636,7 +2636,7 @@ should be discarded. The function waits for a reply packet and copies its contents into the -specified rep. +specified rep. handles error and event packets that occur before the reply is received. @@ -2645,21 +2645,21 @@ takes four arguments: -A +A Display * structure -A pointer to a reply structure (which must be cast to an +A pointer to a reply structure (which must be cast to an xReply *) -The number of additional 32-bit words (beyond +The number of additional 32-bit words (beyond sizeof( xReply) = 32 bytes) in the reply structure @@ -2676,42 +2676,42 @@ beyond those it was told to read -Because most reply structures are 32 bytes long, -the third argument is usually 0. -The only core protocol exceptions are the replies to +Because most reply structures are 32 bytes long, +the third argument is usually 0. +The only core protocol exceptions are the replies to GetWindowAttributesl, QueryFont, QueryKeymap, -and +and GetKeyboardControl, which have longer replies. -The last argument should be +The last argument should be False if the reply structure is followed -by additional variable-length data (such as a list or string). -It should be +by additional variable-length data (such as a list or string). +It should be True if there is not any variable-length data. This last argument is provided for upward-compatibility reasons to allow a client to communicate properly with a hypothetical later version of the server that sends more data than the client expected. -For example, some later version of +For example, some later version of GetWindowAttributesl might use a -larger, but compatible, +larger, but compatible, xGetWindowAttributesReply that contains additional attribute data at the end. -returns +returns True -if it received a reply successfully or +if it received a reply successfully or False -if it received any sort of error. +if it received any sort of error. @@ -2732,10 +2732,10 @@ SyncHandle(); return (rep.ret4); } -If there is variable-length data after the reply, -change the +If there is variable-length data after the reply, +change the True -to +to False, and use the appropriate @@ -3005,7 +3005,7 @@ reads and discards up to three additional pad bytes. -Each protocol request is a little different. +Each protocol request is a little different. For further information, see the Xlib sources for examples. @@ -3014,10 +3014,10 @@ see the Xlib sources for examples. Synchronous Calling -Each procedure should have a call, just before returning to the user, +Each procedure should have a call, just before returning to the user, to a macro called SyncHandle. -If synchronous mode is enabled (see +If synchronous mode is enabled (see XSynchronize), the request is sent immediately. The library, however, waits until any error the procedure could generate @@ -3028,7 +3028,7 @@ at the server has been handled. Allocating and Deallocating Memory -To support the possible reentry of these procedures, +To support the possible reentry of these procedures, you must observe several conventions when allocating and deallocating memory, most often done when returning data to the user from the window system of a size the caller could not know in advance @@ -3045,10 +3045,10 @@ C library functions. -If you need a single scratch buffer inside a critical section +If you need a single scratch buffer inside a critical section (for example, to pack and unpack data to and from the wire protocol), the general memory allocators may be too expensive to use -(particularly in output functions, which are performance critical). +(particularly in output functions, which are performance critical). The following function returns a scratch buffer for use within a critical section: @@ -3225,8 +3225,8 @@ avoided completely if at all possible. -This code may run on machines with 16-bit ints. -So, if any integer argument, variable, or return value either can take +This code may run on machines with 16-bit ints. +So, if any integer argument, variable, or return value either can take only nonnegative values or is declared as a CARD16 in the protocol, be sure to declare it as @@ -3238,10 +3238,10 @@ and not as -Similarly, +Similarly, if any integer argument or return value is declared CARD32 -in the protocol, +in the protocol, declare it as an unsigned long @@ -3273,9 +3273,9 @@ protocol as CARD32 or INT32 but have to be converted to arrays of 64-bit long when passed to or from client applications. -The +The PackData -macro is a half-hearted attempt to deal with the possibility of 32 bit shorts. +macro is a half-hearted attempt to deal with the possibility of 32 bit shorts. However, much more work is needed to make this work properly. @@ -3285,18 +3285,18 @@ However, much more work is needed to make this work properly. The remaining problem a writer of an extension stub procedure faces that the core protocol does not face is to map from the call to the proper -major and minor opcodes. -While there are a number of strategies, +major and minor opcodes. +While there are a number of strategies, the simplest and fastest is outlined below. Declare an array of pointers, _NFILE long (this is normally found -in +in <stdio.h> and is the number of file descriptors supported on the system) -of type +of type XExtCodes. Make sure these are all initialized to NULL. @@ -3305,17 +3305,17 @@ Make sure these are all initialized to NULL. When your stub is entered, your initialization test is just to use the display pointer passed in to access the file descriptor and an index -into the array. +into the array. If the entry is NULL, then this is the first time you -are entering the procedure for this display. +are entering the procedure for this display. Call your initialization procedure and pass to it the display pointer. -Once in your initialization procedure, call +Once in your initialization procedure, call ; -if it succeeds, store the pointer returned into this array. +if it succeeds, store the pointer returned into this array. Make sure to establish a close display handler to allow you to zero the entry. Do whatever other initialization your extension requires. (For example, install event handlers and so on.) @@ -3327,9 +3327,9 @@ be found in your array of pointers. -After returning from your initialization procedure, -the stub can now continue normally, because it has its major opcode safely -in its hand in the +After returning from your initialization procedure, +the stub can now continue normally, because it has its major opcode safely +in its hand in the XExtCodes structure. diff --git a/specs/libX11/AppD.xml b/specs/libX11/AppD.xml index 823f6d51..a90054f6 100644 --- a/specs/libX11/AppD.xml +++ b/specs/libX11/AppD.xml @@ -4,7 +4,7 @@ Compatibility Functions -The X Version 11 and X Version 10 functions discussed in this appendix +The X Version 11 and X Version 10 functions discussed in this appendix are obsolete, have been superseded by newer X Version 11 functions, and are maintained for compatibility reasons only. @@ -15,19 +15,19 @@ You can use the X Version 11 compatibility functions to: -Set standard properties +Set standard properties -Set and get window sizing hints +Set and get window sizing hints Set and get an XStandardColormap -structure +structure @@ -50,8 +50,8 @@ use . This function has been superseded by -and sets all or portions of the -WM_NAME, WM_ICON_NAME, WM_HINTS, WM_COMMAND, +and sets all or portions of the +WM_NAME, WM_ICON_NAME, WM_HINTS, WM_COMMAND, and WM_NORMAL_HINTS properties. XSetStandardProperties @@ -163,8 +163,8 @@ The function provides a means by which simple applications set the most essential properties with a single call. -should be used to give a window manager some information about -your program's preferences. +should be used to give a window manager some information about +your program's preferences. It should not be used by applications that need to communicate more information than is possible with . @@ -256,20 +256,20 @@ Applications use to inform the window manager of the size or position desirable for that window. -In addition, +In addition, an application that wants to move or resize itself should call and specify its new desired location and size -as well as making direct Xlib calls to move or resize. +as well as making direct Xlib calls to move or resize. This is because window managers may ignore redirected configure requests, but they pay attention to property changes. -To set size hints, +To set size hints, an application not only must assign values to the appropriate members -in the hints structure but also must set the flags member of the structure -to indicate which information is present and where it came from. +in the hints structure but also must set the flags member of the structure +to indicate which information is present and where it came from. A call to is meaningless, unless the flags member is set to indicate which members of @@ -665,7 +665,7 @@ or zero otherwise. can generate BadAtom -and +and BadWindow errors. @@ -673,7 +673,7 @@ errors. Getting and Setting an XStandardColormap Structure -To get the +To get the XStandardColormap structure associated with one of the described atoms, use . @@ -849,7 +849,7 @@ errors. Parsing Window Geometry -To parse window geometry given a user-specified position +To parse window geometry given a user-specified position and a default position, use . This function has been superseded by @@ -1032,9 +1032,9 @@ a window using a geometry specification as specified by and the additional information about the window. Given a fully qualified default geometry specification and -an incomplete geometry specification, +an incomplete geometry specification, -returns a bitmask value as defined above in the +returns a bitmask value as defined above in the call, by using the position argument. @@ -1055,7 +1055,7 @@ geometry specifications. The -function provides a primitive interface to the resource manager facilities +function provides a primitive interface to the resource manager facilities discussed in chapter 15. It is only useful in very simple applications. @@ -1089,7 +1089,7 @@ Specifies the connection to the X server. -Specifies the program name for the Xlib defaults (usually argv[0] +Specifies the program name for the Xlib defaults (usually argv[0] of the main program). @@ -1125,11 +1125,11 @@ are owned by Xlib and should not be modified or freed by the client. -If a database has been set with +If a database has been set with , that database is used for the lookup. Otherwise, a database is created -and is set in the display (as if by calling +and is set in the display (as if by calling ). The database is created in the current locale. To create a database, @@ -1179,11 +1179,11 @@ Associate user data with a value Xlib provides functions that you can use to draw or fill -arbitrary polygons or curves. -These functions are provided mainly for compatibility with X Version 10 -and have no server support. -That is, they call other Xlib functions, not the server directly. -Thus, if you just have straight lines to draw, using +arbitrary polygons or curves. +These functions are provided mainly for compatibility with X Version 10 +and have no server support. +That is, they call other Xlib functions, not the server directly. +Thus, if you just have straight lines to draw, using XDrawLines or @@ -1193,8 +1193,8 @@ is much faster. -The functions discussed here provide all the functionality of the -X Version 10 functions +The functions discussed here provide all the functionality of the +X Version 10 functions , X10 compatibilityXDraw , @@ -1206,35 +1206,35 @@ X Version 10 functions and XDrawTiled. X10 compatibilityXDrawTiled -They are as compatible as possible given X Version 11's new line-drawing -functions. +They are as compatible as possible given X Version 11's new line-drawing +functions. One thing to note, however, is that VertexDrawLastPoint -is no longer supported. -Also, the error status returned is the opposite of what it was under -X Version 10 (this is the X Version 11 standard error status). +is no longer supported. +Also, the error status returned is the opposite of what it was under +X Version 10 (this is the X Version 11 standard error status). XAppendVertex -and +and XClearVertexFlag from X Version 10 also are not supported. Just how the graphics context you use is set up actually -determines whether you get dashes or not, and so on. +determines whether you get dashes or not, and so on. Lines are properly joined if they connect and include -the closing of a closed figure (see +the closing of a closed figure (see ). The functions discussed here fail (return zero) only if they run out of memory -or are passed a +or are passed a Vertex -list that has a +list that has a Vertex -with +with VertexStartClosed -set that is not followed by a +set that is not followed by a Vertex -with +with VertexEndClosed set. @@ -1246,7 +1246,7 @@ To achieve the effects of the X Version 10 X10 compatibilityXDraw XDrawDashed, X10 compatibilityXDrawDashed -and +and XDrawPatterned, X10 compatibilityXDrawPatterned use @@ -1285,7 +1285,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1325,7 +1325,7 @@ Specifies how many vertices are in vlist. The -function draws an arbitrary polygon or curve. +function draws an arbitrary polygon or curve. The figure drawn is defined by the specified list of vertices (vlist). The points are connected by lines as specified in the flags in the vertex structure. @@ -1345,17 +1345,17 @@ typedef struct _Vertex { unsigned short flags; } Vertex; -The x and y members are the coordinates of the vertex -that are relative to either the upper left inside corner of the drawable -(if +The x and y members are the coordinates of the vertex +that are relative to either the upper left inside corner of the drawable +(if VertexRelative -is zero) or the previous vertex (if +is zero) or the previous vertex (if VertexRelative is one). -The flags, as defined in +The flags, as defined in <X11/X10.h>, X11/X10.h Files<X11/X10.h> @@ -1379,10 +1379,10 @@ VertexEndClosed 0x0010 /* else not */ -If +If VertexRelative -is not set, -the coordinates are absolute (that is, relative to the drawable's origin). +is not set, +the coordinates are absolute (that is, relative to the drawable's origin). The first vertex must be an absolute vertex. @@ -1390,50 +1390,50 @@ The first vertex must be an absolute vertex. If VertexDontDraw -is one, -no line or curve is drawn from the previous vertex to this one. -This is analogous to picking up the pen and moving to another place +is one, +no line or curve is drawn from the previous vertex to this one. +This is analogous to picking up the pen and moving to another place before drawing another line. -If +If VertexCurved -is one, +is one, a spline algorithm is used to draw a smooth curve from the previous vertex -through this one to the next vertex. -Otherwise, a straight line is drawn from the previous vertex to this one. -It makes sense to set +through this one to the next vertex. +Otherwise, a straight line is drawn from the previous vertex to this one. +It makes sense to set VertexCurved to one only if a previous and next vertex are both defined -(either explicitly in the array or through the definition of a closed +(either explicitly in the array or through the definition of a closed curve). -It is permissible for +It is permissible for VertexDontDraw -bits and +bits and VertexCurved -bits both to be one. +bits both to be one. This is useful if you want to define the previous point for the smooth curve but do not want an actual curve drawing to start until this point. -If +If VertexStartClosed -is one, -then this point marks the beginning of a closed curve. -This vertex must be followed later in the array by another vertex +is one, +then this point marks the beginning of a closed curve. +This vertex must be followed later in the array by another vertex whose effective coordinates are identical and that has a VertexEndClosed bit of one. -The points in between form a cycle to determine predecessor +The points in between form a cycle to determine predecessor and successor vertices for the spline algorithm. @@ -1445,7 +1445,7 @@ This function uses these GC components: function, plane-mask, line-width, line-style, cap-style, join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -It also uses these GC mode-dependent components: +It also uses these GC mode-dependent components: foreground, background, tile, stipple, tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, and dash-list. @@ -1455,7 +1455,7 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, and dash-list. To achieve the effects of the X Version 10 XDrawTiled X10 compatibilityXDrawTiled -and +and , X10 compatibilityXDrawFilled use @@ -1492,7 +1492,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1541,9 +1541,9 @@ This function uses these GC components: function, plane-mask, line-width, line-style, cap-style, join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -It also uses these GC mode-dependent components: +It also uses these GC mode-dependent components: foreground, background, tile, stipple, -tile-stipple-x-origin, tile-stipple-y-origin, +tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list, fill-style, and fill-rule. @@ -1554,7 +1554,7 @@ dash-offset, dash-list, fill-style, and fill-rule. These functions have been superseded by the context management functions (see section 16.10). It is often necessary to associate arbitrary information with resource IDs. -Xlib provides the +Xlib provides the XAssocTable functions that you can use to make such an association. Hash Lookup @@ -1562,7 +1562,7 @@ functions that you can use to make such an association. Resource IDs Application programs often need to be able to easily refer to their own data structures when an event arrives. -The +The XAssocTable system provides users of the X library with a method for associating their own data structures with X resources @@ -1573,12 +1573,12 @@ and so on). -An +An XAssocTable -can be used to type X resources. +can be used to type X resources. For example, the user may want to have three or four types of windows, -each with different properties. +each with different properties. This can be accomplished by associating each X window ID with a pointer to a window property data structure defined by the user. @@ -1601,7 +1601,7 @@ All XIDs are relative to the specified display. Because of the hashing scheme used by the association mechanism, the following rules for determining the size of a XAssocTable -should be followed. +should be followed. Associations will be made and looked up more efficiently if the table size (number of buckets in the hashing system) is a power of two and if there are not more than 8 XIDs per @@ -1615,7 +1615,7 @@ bucket. To return a pointer to a new XAssocTable, -use +use . XCreateAssocTable @@ -1644,7 +1644,7 @@ Specifies the number of buckets in the hash system of -The size argument specifies the number of buckets in the +The size argument specifies the number of buckets in the hash system of XAssocTable. For reasons of efficiency the number of buckets @@ -1653,15 +1653,15 @@ Some size suggestions might be: use 32 buckets per 100 objects, and a reasonable maximum number of objects per buckets is 8. If an error allocating memory for the XAssocTable -occurs, -a NULL pointer is returned. +occurs, +a NULL pointer is returned. -To create an entry in a given +To create an entry in a given XAssocTable, -use +use . XMakeAssoc @@ -1693,7 +1693,7 @@ Specifies the connection to the X server. -Specifies the assoc table. +Specifies the assoc table. @@ -1723,20 +1723,20 @@ Specifies the data to be associated with the X resource ID. The -function inserts data into an +function inserts data into an XAssocTable keyed on an XID. Data is inserted into the table only once. Redundant inserts are ignored. -The queue in each association bucket is sorted from the lowest XID to +The queue in each association bucket is sorted from the lowest XID to the highest XID. -To obtain data from a given +To obtain data from a given XAssocTable, -use +use . XLookUpAssoc @@ -1767,7 +1767,7 @@ Specifies the connection to the X server. -Specifies the assoc table. +Specifies the assoc table. @@ -1787,9 +1787,9 @@ Specifies the X resource ID. The -function retrieves the data stored in an +function retrieves the data stored in an XAssocTable -by its XID. +by its XID. If an appropriately matching XID can be found in the table, returns the data associated with it. @@ -1799,9 +1799,9 @@ it returns NULL. -To delete an entry from a given +To delete an entry from a given XAssocTable, -use +use . XDeleteAssoc @@ -1832,7 +1832,7 @@ Specifies the connection to the X server. -Specifies the assoc table. +Specifies the assoc table. @@ -1852,7 +1852,7 @@ Specifies the X resource ID. The -function deletes an association in an +function deletes an association in an XAssocTable keyed on its XID. Redundant deletes (and deletes of nonexistent XIDs) are ignored. @@ -1862,9 +1862,9 @@ Deleting associations in no way impairs the performance of an -To free the memory associated with a given +To free the memory associated with a given XAssocTable, -use +use . XDestroyAssocTable @@ -1883,7 +1883,7 @@ use -Specifies the assoc table. +Specifies the assoc table. diff --git a/specs/libX11/CH02.xml b/specs/libX11/CH02.xml index 5dbfa2b1..cdca45cc 100644 --- a/specs/libX11/CH02.xml +++ b/specs/libX11/CH02.xml @@ -81,8 +81,8 @@ To open a connection to the X server that controls a display, use Specifies the hardware display name, which determines the display and communications domain to be used. -On a POSIX-conformant system, if the display_name is NULL, -it defaults to the value of the DISPLAY environment variable. +On a POSIX-conformant system, if the display_name is NULL, +it defaults to the value of the DISPLAY environment variable. EnvironmentDISPLAY @@ -112,9 +112,9 @@ the display name or DISPLAY environment variable can be a string in the format: -Specifies a protocol family or an alias for a protocol family. Supported -protocol families are implementation dependent. The protocol entry is -optional. If protocol is not specified, the / separating protocol and +Specifies a protocol family or an alias for a protocol family. Supported +protocol families are implementation dependent. The protocol entry is +optional. If protocol is not specified, the / separating protocol and hostname must also not be specified. @@ -154,9 +154,9 @@ Multiple displays are usually numbered starting with zero. Specifies the screen to be used on that server. Multiple screens can be controlled by a single X server. The screen_number sets an internal variable that can be accessed by -using the +using the DefaultScreen -macro or the +macro or the function if you are using languages other than C (see section 2.2.1). @@ -167,7 +167,7 @@ function if you are using languages other than C -For example, the following would specify screen 1 of display 0 on the +For example, the following would specify screen 1 of display 0 on the machine named ``dual-headed'': @@ -180,7 +180,7 @@ dual-headed:0.1 The -function returns a +function returns a Display structure that serves as the connection to the X server and that contains all the information @@ -212,24 +212,24 @@ mechanisms. Display -If successful, +If successful, -returns a pointer to a +returns a pointer to a Display structure, -which is defined in +which is defined in <X11/Xlib.h>. X11/Xlib.h Files<X11/Xlib.h> Headers<X11/Xlib.h> -If +If does not succeed, it returns NULL. After a successful call to , all of the screens in the display can be used by the client. -The screen number specified in the display_name argument is returned -by the +The screen number specified in the display_name argument is returned +by the DefaultScreen macro (or the @@ -239,7 +239,7 @@ You can access elements of the and Screen structures only by using the information macros or functions. -For information about using macros and functions to obtain information from +For information about using macros and functions to obtain information from the Display structure, @@ -258,11 +258,11 @@ X servers may implement various types of access control mechanisms -The Xlib library provides a number of useful macros -and corresponding functions that return data from the +The Xlib library provides a number of useful macros +and corresponding functions that return data from the Display structure. -The macros are used for C programming, +The macros are used for C programming, and their corresponding function equivalents are for other language bindings. This section discusses the: @@ -286,11 +286,11 @@ Screen information macros Displaydata structure -All other members of the +All other members of the Display -structure (that is, those for which no macros are defined) are private to Xlib +structure (that is, those for which no macros are defined) are private to Xlib and must not be used. -Applications must never directly modify or inspect these private members of the +Applications must never directly modify or inspect these private members of the Display structure. @@ -303,7 +303,7 @@ The and functions in the next sections are misnamed. -These functions really should be named Screenwhatever +These functions really should be named Screenwhatever and XScreenwhatever, not Displaywhatever or XDisplaywhatever. Our apologies for the resulting confusion. @@ -351,14 +351,14 @@ a procedure. XBlackPixel WhitePixel XWhitePixel -Both +Both BlackPixel -and +and WhitePixel can be used in implementing a monochrome application. These pixel values are for permanently allocated entries in the default colormap. -The actual RGB (red, green, and blue) values are settable on some screens +The actual RGB (red, green, and blue) values are settable on some screens and, in any case, may not actually be black or white. The names are intended to convey the expected relative intensity of the colors. @@ -450,7 +450,7 @@ Specifies the appropriate screen number on the host server. -Both return the white pixel value for the specified screen. +Both return the white pixel value for the specified screen. @@ -648,7 +648,7 @@ Returns the number of depths. The XListDepths -function returns the array of depths +function returns the array of depths that are available on the specified screen. If the specified screen_number is valid and sufficient memory for the array can be allocated, @@ -705,7 +705,7 @@ Specifies the appropriate screen number on the host server. DefaultGC XDefaultGC -Both return the default graphics context for the root window of the +Both return the default graphics context for the root window of the specified screen. This GC is created for the convenience of simple applications and contains the default GC components with the foreground and @@ -873,10 +873,10 @@ Specifies the connection to the X server. DefaultScreen XDefaultScreen -Both return the default screen number referenced by the +Both return the default screen number referenced by the -function. -This macro or function should be used to retrieve the screen number +function. +This macro or function should be used to retrieve the screen number in applications that will use only a single screen. @@ -1065,16 +1065,16 @@ Specifies the connection to the X server. DisplayString XDisplayString -Both return the string that was passed to +Both return the string that was passed to -when the current display was opened. +when the current display was opened. On POSIX-conformant systems, if the passed string was NULL, these return the value of the DISPLAY environment variable when the current display was opened. POSIX System Callfork -These are useful to applications that invoke the +These are useful to applications that invoke the fork -system call and want to open a new connection to the same display from the +system call and want to open a new connection to the same display from the child process as well as for printing error messages. @@ -1174,7 +1174,7 @@ as necessary for the following functions: , , , -and +and . @@ -1291,7 +1291,7 @@ Specifies the connection to the X server. ProtocolVersion XProtocolVersion -Both return the major version number (11) of the X protocol associated with +Both return the major version number (11) of the X protocol associated with the connected display. @@ -1669,12 +1669,12 @@ Specifies the connection to the X server. ImageByteOrder XImageByteOrder -Both specify the required byte order for images for each scanline unit in -XY format (bitmap) or for each pixel value in +Both specify the required byte order for images for each scanline unit in +XY format (bitmap) or for each pixel value in Z format. The macro or function can return either LSBFirst -or +or MSBFirst. @@ -1753,9 +1753,9 @@ Specifies the connection to the X server. Within each bitmap unit, the left-most bit in the bitmap as displayed on the screen is either the least significant or most significant bit in the unit. -This macro or function can return +This macro or function can return LSBFirst -or +or MSBFirst. @@ -2032,7 +2032,7 @@ structure. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2071,7 +2071,7 @@ Both return the black pixel value of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2110,7 +2110,7 @@ Both return the white pixel value of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2122,7 +2122,7 @@ structure. CellsOfScreen XCellsOfScreen -Both return the number of colormap cells in the default colormap +Both return the number of colormap cells in the default colormap of the specified screen. @@ -2150,7 +2150,7 @@ of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2189,7 +2189,7 @@ Both return the default colormap of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2228,7 +2228,7 @@ Both return the depth of the root window. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2269,7 +2269,7 @@ The GC must never be freed. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2310,7 +2310,7 @@ see section 3.1. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2324,7 +2324,7 @@ structure. XDoesBackingStore Both return a value indicating whether the screen supports backing stores. -The value returned can be one of +The value returned can be one of WhenMapped, NotUseful, or @@ -2356,7 +2356,7 @@ or -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2403,7 +2403,7 @@ the screen does not support save unders -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2443,7 +2443,7 @@ Both return the display of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2482,7 +2482,7 @@ function returns the screen index number of the specified screen. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2522,7 +2522,7 @@ at connection setup time. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2561,7 +2561,7 @@ Both return the width of the specified screen in pixels. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2600,7 +2600,7 @@ Both return the height of the specified screen in pixels. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2639,7 +2639,7 @@ Both return the width of the specified screen in millimeters. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2678,7 +2678,7 @@ Both return the height of the specified screen in millimeters. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2690,7 +2690,7 @@ structure. MaxCmapsOfScreen XMaxCmapsOfScreen -Both return the maximum number of installed colormaps supported +Both return the maximum number of installed colormaps supported by the specified screen (see section 9.3). @@ -2719,7 +2719,7 @@ by the specified screen -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2731,7 +2731,7 @@ structure. MinCmapsOfScreen XMinCmapsOfScreen -Both return the minimum number of installed colormaps supported +Both return the minimum number of installed colormaps supported by the specified screen (see section 9.3). @@ -2760,7 +2760,7 @@ by the specified screen -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2799,7 +2799,7 @@ Both return the depth of the root window. -Specifies the appropriate +Specifies the appropriate Screen structure. @@ -2822,7 +2822,7 @@ Both return the root window of the specified screen. -To execute a +To execute a NoOperation protocol request, use . @@ -2849,7 +2849,7 @@ protocol request, use The -function sends a +function sends a NoOperation protocol request to the X server, thereby exercising the connection. @@ -2952,7 +2952,7 @@ or other resources that the client has created on this display, unless the close-down mode of the client has been changed (see ). -Therefore, these windows, resource IDs, and other resources should never be +Therefore, these windows, resource IDs, and other resources should never be referenced again or an error will be generated. Before exiting, you should call XCloseDisplay @@ -3007,7 +3007,7 @@ Specifies the connection to the X server. Specifies the client close-down mode. -You can pass +You can pass DestroyAll, RetainPermanent, or @@ -3057,7 +3057,7 @@ automatic operations: It disowns all selections owned by the client -(see +(see ). @@ -3067,7 +3067,7 @@ It performs an and -if the client has actively grabbed the pointer +if the client has actively grabbed the pointer or the keyboard. @@ -3080,19 +3080,19 @@ if the client has grabbed the server. -It releases all passive grabs made by the client. +It releases all passive grabs made by the client. -It marks all resources (including colormap entries) allocated -by the client either as permanent or temporary, -depending on whether the close-down mode is +It marks all resources (including colormap entries) allocated +by the client either as permanent or temporary, +depending on whether the close-down mode is RetainPermanent or RetainTemporary. However, this does not prevent other client applications from explicitly -destroying the resources (see +destroying the resources (see ). @@ -3122,7 +3122,7 @@ window. It performs a MapWindow request on the save-set window if the save-set window is unmapped. -The X server does this even if the save-set window was not an inferior of +The X server does this even if the save-set window was not an inferior of a window created by the client. @@ -3134,12 +3134,12 @@ It destroys all windows created by the client. It performs the appropriate free request on each nonwindow resource created by -the client in the server (for example, +the client in the server (for example, Font, Pixmap, Cursor, Colormap, -and +and GContext). @@ -3157,15 +3157,15 @@ connections. When the last connection to the X server closes as a result of a connection closing with the close_mode of DestroyAll, -the X server does the following: +the X server does the following: It resets its state as if it had just been -started. +started. The X server begins by destroying all lingering resources from -clients that have terminated in +clients that have terminated in RetainPermanent or RetainTemporary @@ -3185,8 +3185,8 @@ It deletes all properties on all root windows -It resets all device maps and attributes -(for example, key click, bell volume, and acceleration) +It resets all device maps and attributes +(for example, key click, bell volume, and acceleration) as well as the access control list. diff --git a/specs/libX11/CH03.xml b/specs/libX11/CH03.xml index 801febb4..008a39b0 100644 --- a/specs/libX11/CH03.xml +++ b/specs/libX11/CH03.xml @@ -10,7 +10,7 @@ Visual Type -On some display hardware, +On some display hardware, it may be possible to deal with color resources in more than one way. For example, you may be able to deal with a screen of either 12-bit depth with arbitrary mapping of pixel to color (pseudo-color) or 24-bit depth @@ -21,14 +21,14 @@ For each screen of the display, there may be a list of valid visual types supported at different depths of the screen. Because default windows and visual types are defined for each screen, most simple applications need not deal with this complexity. -Xlib provides macros and functions that return the default root window, +Xlib provides macros and functions that return the default root window, the default depth of the default root window, and the default visual type (see sections 2.2.1 and 16.7). -Xlib uses an opaque +Xlib uses an opaque Visual Visual structure that contains information about the possible color mapping. @@ -40,7 +40,7 @@ structure to return this information to an application. The members of this structure pertinent to this discussion are class, red_mask, green_mask, blue_mask, bits_per_rgb, and colormap_size. The class member specifies one of the possible visual classes of the screen -and can be +and can be Visual ClassesStaticGray Visual ClassesStaticColor Visual ClassesTrueColor @@ -58,10 +58,10 @@ or The following concepts may serve to make the explanation of -visual types clearer. +visual types clearer. The screen can be color or grayscale, can have a colormap that is writable or read-only, -and can also have a colormap whose indices are decomposed into separate +and can also have a colormap whose indices are decomposed into separate RGB pieces, provided one is not on a grayscale screen. This leads to the following diagram: @@ -80,12 +80,12 @@ This leads to the following diagram: -Conceptually, +Conceptually, as each pixel is read out of video memory for display on the screen, it goes through a look-up stage by indexing into a colormap. -Colormaps can be manipulated arbitrarily on some hardware, -in limited ways on other hardware, and not at all on other hardware. -The visual types affect the colormap and +Colormaps can be manipulated arbitrarily on some hardware, +in limited ways on other hardware, and not at all on other hardware. +The visual types affect the colormap and the RGB values in the following ways: @@ -94,7 +94,7 @@ the RGB values in the following ways: -For +For PseudoColor, a pixel value indexes a colormap to produce independent RGB values, and the RGB values can be changed dynamically. @@ -103,16 +103,16 @@ independent RGB values, and the RGB values GrayScale -is treated the same way as +is treated the same way as PseudoColor -except that the primary that drives the screen is undefined. +except that the primary that drives the screen is undefined. Thus, the client should always store the -same value for red, green, and blue in the colormaps. +same value for red, green, and blue in the colormaps. -For +For DirectColor, a pixel value is decomposed into separate RGB subfields, and each subfield separately indexes the colormap for the corresponding value. @@ -122,29 +122,29 @@ The RGB values can be changed dynamically. TrueColor -is treated the same way as +is treated the same way as DirectColor except that the colormap has predefined, read-only RGB values. These RGB values are server dependent but provide linear or near-linear -ramps in each primary. +ramps in each primary. StaticColor -is treated the same way as +is treated the same way as PseudoColor -except that the colormap has predefined, +except that the colormap has predefined, read-only, server-dependent RGB values. StaticGray -is treated the same way as +is treated the same way as StaticColor except that the RGB values are equal for any single pixel -value, thus resulting in shades of gray. +value, thus resulting in shades of gray. StaticGray with a two-entry colormap can be thought of as monochrome. @@ -155,7 +155,7 @@ colormap can be thought of as monochrome. The red_mask, green_mask, and blue_mask members are only defined for DirectColor -and +and TrueColor. Each has one contiguous set of bits with no intersections. @@ -163,17 +163,17 @@ The bits_per_rgb member specifies the log base 2 of the number of distinct color values (individually) of red, green, and blue. Actual RGB values are unsigned 16-bit numbers. The colormap_size member defines the number of available colormap entries -in a newly created colormap. -For +in a newly created colormap. +For DirectColor -and +and TrueColor, this is the size of an individual pixel subfield. -To obtain the visual ID from a +To obtain the visual ID from a Visual, use . @@ -216,10 +216,10 @@ function returns the visual ID for the specified visual type. Window Windowattributes -All +All InputOutput -windows have a border width of zero or more pixels, an optional background, -an event suppression mask (which suppresses propagation of events from +windows have a border width of zero or more pixels, an optional background, +an event suppression mask (which suppresses propagation of events from children), and a property list (see section 4.3). The window border and background can be a solid color or a pattern, called @@ -229,8 +229,8 @@ If a window is stacked on top of another window, it obscures that other window for the purpose of input. If a window has a background (almost all do), it obscures the other window for purposes of output. -Attempts to output to the obscured area do nothing, -and no input events (for example, pointer motion) are generated for the +Attempts to output to the obscured area do nothing, +and no input events (for example, pointer motion) are generated for the obscured area. @@ -313,7 +313,7 @@ The background and border pixmaps can be destroyed immediately after creating the window if no further explicit references to them are to be made. Tilemode -The pattern can either be relative to the parent +The pattern can either be relative to the parent or absolute. If ParentRelative, @@ -321,24 +321,24 @@ the parent's background is used. -When windows are first created, +When windows are first created, they are not visible (not mapped) on the screen. -Any output to a window that is not visible on the screen +Any output to a window that is not visible on the screen and that does not have backing store will be discarded. Windowmapping An application may wish to create a window long before it is mapped to the screen. -When a window is eventually mapped to the screen +When a window is eventually mapped to the screen (using ), XMapWindow -the X server generates an +the X server generates an Expose event for the window if backing store has not been maintained. -A window manager can override your choice of size, +A window manager can override your choice of size, border width, and position for a top-level window. Your program must be prepared to use the actual size and position of the top window. @@ -347,7 +347,7 @@ unless in direct response to a human command to do so. Instead, either your program should use the space given to it, or if the space is too small for any useful work, your program might ask the user to resize the window. -The border of your top-level window is considered fair game +The border of your top-level window is considered fair game for window managers. @@ -359,7 +359,7 @@ structure and OR in the corresponding value bitmask in your subsequent calls to and , -or use one of the other convenience functions that set the appropriate +or use one of the other convenience functions that set the appropriate attribute. The symbols for the value mask bits and the XSetWindowAttributes @@ -551,7 +551,7 @@ window by using a pixel or a pixmap. -The background-pixmap attribute of a window specifies the pixmap to be used for +The background-pixmap attribute of a window specifies the pixmap to be used for a window's background. This pixmap can be of any size, although some sizes may be faster than others. The background-pixel attribute of a window specifies a pixel value used to paint @@ -559,15 +559,15 @@ a window's background in a single color. -You can set the background-pixmap to a pixmap, +You can set the background-pixmap to a pixmap, None -(default), or +(default), or ParentRelative. You can set the background-pixel of a window to any pixel value (no default). -If you specify a background-pixel, +If you specify a background-pixel, it overrides either the default background-pixmap or any value you may have set in the background-pixmap. -A pixmap of an undefined size that is filled with the background-pixel is used +A pixmap of an undefined size that is filled with the background-pixel is used for the background. Range checking is not performed on the background pixel; it simply is truncated to the appropriate number of bits. @@ -582,15 +582,15 @@ or a error results. If you set background-pixmap to None, -the window has no defined background. +the window has no defined background. If you set the background-pixmap to ParentRelative: -The parent window's background-pixmap is used. -The child window, however, must have the same depth as +The parent window's background-pixmap is used. +The child window, however, must have the same depth as its parent, or a BadMatch @@ -608,14 +608,14 @@ the window also has a background-pixmap of A copy of the parent window's background-pixmap is not made. -The parent's background-pixmap is examined each time the child window's -background-pixmap is required. +The parent's background-pixmap is examined each time the child window's +background-pixmap is required. The background tile origin always aligns with the parent window's -background tile origin. +background tile origin. If the background-pixmap is not ParentRelative, the background tile origin is the child window's origin. @@ -669,10 +669,10 @@ window by using a pixel or a pixmap. -The border-pixmap attribute of a window specifies the pixmap to be used +The border-pixmap attribute of a window specifies the pixmap to be used for a window's border. -The border-pixel attribute of a window specifies a pixmap of undefined size -filled with that pixel be used for a window's border. +The border-pixel attribute of a window specifies a pixmap of undefined size +filled with that pixel be used for a window's border. Range checking is not performed on the background pixel; it simply is truncated to the appropriate number of bits. The border tile origin is always the same as the background tile origin. @@ -687,16 +687,16 @@ You can set the border-pixel to any pixel value (no default). -If you set a border-pixmap, +If you set a border-pixmap, it overrides the default. The border-pixmap and the window must have the same depth, or a BadMatch error results. -If you set the border-pixmap to +If you set the border-pixmap to CopyFromParent, the parent window's border-pixmap is copied. -Subsequent changes to the parent window's border attribute do not affect +Subsequent changes to the parent window's border attribute do not affect the child window. However, the child window must have the same depth as the parent window, or a @@ -711,7 +711,7 @@ If you later draw into the pixmap used for the border, what happens is undefined because the X implementation is free either to make a copy of the pixmap or to use the same pixmap. -If you specify a border-pixel, +If you specify a border-pixel, it overrides either the default border-pixmap or any value you may have set in the border-pixmap. All pixels in the window's border will be set to the border-pixel. @@ -720,7 +720,7 @@ border-pixmap, overrides any previous border. -Output to a window is always clipped to the inside of the window. +Output to a window is always clipped to the inside of the window. Therefore, graphics operations never affect the window border. @@ -731,24 +731,24 @@ Therefore, graphics operations never affect the window border. -The bit gravity of a window defines which region of the window should be +The bit gravity of a window defines which region of the window should be retained when an InputOutput -window is resized. -The default value for the bit-gravity attribute is +window is resized. +The default value for the bit-gravity attribute is ForgetGravity. -The window gravity of a window allows you to define how the +The window gravity of a window allows you to define how the InputOutput or InputOnly -window should be repositioned if its parent is resized. -The default value for the win-gravity attribute is +window should be repositioned if its parent is resized. +The default value for the win-gravity attribute is NorthWestGravity. -If the inside width or height of a window is not changed -and if the window is moved or its border is changed, +If the inside width or height of a window is not changed +and if the window is moved or its border is changed, then the contents of the window are not lost but move with the window. Changing the inside width or height of the window causes its contents to be moved or lost (depending on the bit-gravity of the window) and causes @@ -812,11 +812,11 @@ change of width and height, the (x, y) pairs are defined: -When a window with one of these bit-gravity values is resized, +When a window with one of these bit-gravity values is resized, the corresponding pair defines the change in position of each pixel in the window. When a window with one of these win-gravities has its parent window resized, -the corresponding pair defines the change in position of the window +the corresponding pair defines the change in position of the window within the parent. When a window is so repositioned, a GravityNotify @@ -827,7 +827,7 @@ event is generated A bit-gravity of StaticGravity -indicates that the contents or origin should not move relative to the +indicates that the contents or origin should not move relative to the origin of the root window. If the change in size of the window is coupled with a change in position (x, y), then for bit-gravity the change in position of each pixel is (−x, −y), and for @@ -835,23 +835,23 @@ win-gravity the change in position of a child when its parent is so resized is (−x, −y). Note that StaticGravity -still only takes effect when the width or height of the window is changed, +still only takes effect when the width or height of the window is changed, not when the window is moved. -A bit-gravity of +A bit-gravity of ForgetGravity -indicates that the window's contents are always discarded after a size change, +indicates that the window's contents are always discarded after a size change, even if a backing store or save under has been requested. The window is tiled with its background -and zero or more +and zero or more Expose -events are generated. +events are generated. If no background is defined, the existing screen contents are not altered. -Some X servers may also ignore the specified bit-gravity and -always generate +Some X servers may also ignore the specified bit-gravity and +always generate Expose events. @@ -865,14 +865,14 @@ instead. -A win-gravity of +A win-gravity of UnmapGravity -is like +is like NorthWestGravity (the window is not moved), except the child is also unmapped when the parent is resized, -and an +and an UnmapNotify event is generated. @@ -885,13 +885,13 @@ generated. -Some implementations of the X server may choose to maintain the contents of +Some implementations of the X server may choose to maintain the contents of InputOutput windows. -If the X server maintains the contents of a window, +If the X server maintains the contents of a window, the off-screen saved pixels are known as backing store. -The backing store advises the X server on what to do +The backing store advises the X server on what to do with the contents of a window. The backing-store attribute can be set to NotUseful @@ -902,34 +902,34 @@ or -A backing-store attribute of +A backing-store attribute of NotUseful -advises the X server that -maintaining contents is unnecessary, +advises the X server that +maintaining contents is unnecessary, although some X implementations may -still choose to maintain contents and, therefore, not generate +still choose to maintain contents and, therefore, not generate Expose events. -A backing-store attribute of +A backing-store attribute of WhenMapped -advises the X server that maintaining contents of +advises the X server that maintaining contents of obscured regions when the window is mapped would be beneficial. In this case, -the server may generate an +the server may generate an Expose event when the window is created. -A backing-store attribute of +A backing-store attribute of Always -advises the X server that maintaining contents even when -the window is unmapped would be beneficial. -Even if the window is larger than its parent, -this is a request to the X server to maintain complete contents, -not just the region within the parent window boundaries. -While the X server maintains the window's contents, +advises the X server that maintaining contents even when +the window is unmapped would be beneficial. +Even if the window is larger than its parent, +this is a request to the X server to maintain complete contents, +not just the region within the parent window boundaries. +While the X server maintains the window's contents, Expose -events normally are not generated, -but the X server may stop maintaining -contents at any time. +events normally are not generated, +but the X server may stop maintaining +contents at any time. @@ -947,15 +947,15 @@ However, regions obscured by inferior windows are not included. Save Unders -Some server implementations may preserve contents of +Some server implementations may preserve contents of InputOutput -windows under other +windows under other InputOutput windows. This is not the same as preserving the contents of a window for you. You may get better visual appeal if transient windows (for example, pop-up menus) request that the system -preserve the screen contents under them, +preserve the screen contents under them, so the temporarily obscured applications do not have to repaint. @@ -965,9 +965,9 @@ You can set the save-under flag to or False (default). -If save-under is +If save-under is True, -the X server is advised that, when this window is mapped, +the X server is advised that, when this window is mapped, saving the contents of windows it obscures would be beneficial. @@ -978,22 +978,22 @@ saving the contents of windows it obscures would be beneficial. -You can set backing planes to indicate (with bits set to 1) +You can set backing planes to indicate (with bits set to 1) which bit planes of an InputOutput -window hold dynamic data that must be preserved in backing store +window hold dynamic data that must be preserved in backing store and during save unders. The default value for the backing-planes attribute is all bits set to 1. -You can set backing pixel to specify what bits to use in planes not +You can set backing pixel to specify what bits to use in planes not covered by backing planes. The default value for the backing-pixel attribute is all bits set to 0. The X server is free to save only the specified bit planes in the backing store -or the save under and is free to regenerate the remaining planes with +or the save under and is free to regenerate the remaining planes with the specified pixel value. -Any extraneous bits in these values (that is, those bits beyond +Any extraneous bits in these values (that is, those bits beyond the specified depth of the window) may be simply ignored. If you request backing store or save unders, -you should use these members to minimize the amount of off-screen memory +you should use these members to minimize the amount of off-screen memory required to store your window. @@ -1004,22 +1004,22 @@ required to store your window. -The event mask defines which events the client is interested in for this +The event mask defines which events the client is interested in for this InputOutput or InputOnly window (or, for some event types, inferiors of this window). -The event mask is the bitwise inclusive OR of zero or more of the +The event mask is the bitwise inclusive OR of zero or more of the valid event mask bits. -You can specify that no maskable events are reported by setting +You can specify that no maskable events are reported by setting NoEventMask (default). The do-not-propagate-mask attribute -defines which events should not be propagated to -ancestor windows when no client has the event type selected in this +defines which events should not be propagated to +ancestor windows when no client has the event type selected in this InputOutput or InputOnly @@ -1038,7 +1038,7 @@ of the following masks: Button5Motion, and ButtonMotion. -You can specify that all events are propagated by setting +You can specify that all events are propagated by setting NoEventMask (default). @@ -1064,8 +1064,8 @@ use the override-redirect flag. -The override-redirect flag specifies whether map and configure requests -on this window should override a +The override-redirect flag specifies whether map and configure requests +on this window should override a SubstructureRedirectMask on the parent. You can set the override-redirect flag to @@ -1085,15 +1085,15 @@ Window managers use this information to avoid tampering with pop-up windows The colormap attribute specifies which colormap best reflects the true -colors of the +colors of the InputOutput -window. +window. The colormap must have the same visual type as the window, -or a +or a BadMatch -error results. -X servers capable of supporting multiple -hardware colormaps can use this information, +error results. +X servers capable of supporting multiple +hardware colormaps can use this information, and window managers can use it for calls to . You can set the colormap attribute to a colormap or to @@ -1105,16 +1105,16 @@ You can set the colormap attribute to a colormap or to If you set the colormap to CopyFromParent, the parent window's colormap is copied and used by its child. -However, the child window must have the same visual type as the parent, -or a -BadMatch -error results. -The parent window must not have a colormap of -None, -or a +However, the child window must have the same visual type as the parent, +or a BadMatch error results. -The colormap is copied by sharing the colormap object between the child +The parent window must not have a colormap of +None, +or a +BadMatch +error results. +The colormap is copied by sharing the colormap object between the child and parent, not by making a complete copy of the colormap contents. Subsequent changes to the parent window's colormap attribute do not affect the child window. @@ -1128,7 +1128,7 @@ not affect the child window. The cursor attribute specifies which cursor is to be used when the pointer is -in the +in the InputOutput or InputOnly @@ -1141,8 +1141,8 @@ You can set the cursor to a cursor or If you set the cursor to None, -the parent's cursor is used when the -pointer is in the +the parent's cursor is used when the +pointer is in the InputOutput or InputOnly @@ -1150,7 +1150,7 @@ window, and any change in the parent's cursor will cause an immediate change in the displayed cursor. By calling , -the cursor can be freed immediately as long as no further explicit reference +the cursor can be freed immediately as long as no further explicit reference to it is made. @@ -1187,8 +1187,8 @@ placement of your top-level window. -You must be able to deal with whatever size window you get, -even if this means that your application just prints a message +You must be able to deal with whatever size window you get, +even if this means that your application just prints a message like ``Please make me bigger'' in its window. @@ -1219,7 +1219,7 @@ the Inter-Client Communica -is the more general function that allows you to set specific window attributes +is the more general function that allows you to set specific window attributes when you create a window. creates a window that inherits its attributes from its parent window. @@ -1227,18 +1227,18 @@ creates a window that inherits its attributes from its parent window. WindowInputOnly -The X server acts as if +The X server acts as if InputOnly windows do not exist for the purposes of graphics requests, exposure processing, and VisibilityNotify events. -An +An InputOnly window cannot be used as a drawable (that is, as a source or destination for graphics requests). InputOnly -and +and InputOutput windows act identically in other respects (properties, grabs, input control, and so on). @@ -1356,7 +1356,7 @@ Specifies the width of the created window's border in pixels. Specifies the window's depth. -A depth of +A depth of CopyFromParent means the depth is taken from the parent. @@ -1372,9 +1372,9 @@ Specifies the created window's class. You can pass InputOutput, InputOnly, -or +or CopyFromParent. -A class of +A class of CopyFromParent means the class is taken from the parent. @@ -1388,9 +1388,9 @@ is taken from the parent. Specifies the visual type. -A visual of +A visual of CopyFromParent -means the visual type is taken from the +means the visual type is taken from the parent. @@ -1428,12 +1428,12 @@ set to indicate which attributes have been set in the structure. The -function creates an unmapped subwindow for a specified parent window, -returns the window ID of the created window, +function creates an unmapped subwindow for a specified parent window, +returns the window ID of the created window, and causes the X server to generate a CreateNotify event. -The created window is placed on top in the stacking order +The created window is placed on top in the stacking order with respect to siblings. @@ -1444,7 +1444,7 @@ Coordinates are integral, in terms of pixels, and coincide with pixel centers. Each window and pixmap has its own coordinate system. -For a window, +For a window, the origin is inside the border at the inside, upper-left corner. @@ -1461,7 +1461,7 @@ or a BadMatch error results. The depth need not be the same as the parent, -but the parent must not be a window of class +but the parent must not be a window of class InputOnly, or a BadMatch @@ -1485,7 +1485,7 @@ The created window is not yet displayed (mapped) on the user's display. To display the window, call . The new window initially uses the same cursor as -its parent. +its parent. A new cursor can be defined for the new window by calling . CursorInitial State @@ -1510,7 +1510,7 @@ errors. -To create an unmapped +To create an unmapped InputOutput subwindow of a given parent window, use . @@ -1645,7 +1645,7 @@ subwindow for a specified parent window, returns the window ID of the created window, and causes the X server to generate a CreateNotify event. -The created window is placed on top in the stacking order with respect to +The created window is placed on top in the stacking order with respect to siblings. Any part of the window that extends outside its parent window is clipped. The border_width for an @@ -1655,7 +1655,7 @@ window must be zero, or a error results. inherits its depth, class, and visual from its parent. -All other window attributes, except background and border, +All other window attributes, except background and border, have their default values. @@ -1739,7 +1739,7 @@ the window itself. The ordering among siblings and across subhierarchies is not otherwise constrained. If the window you specified is a root window, no windows are destroyed. -Destroying a mapped window will generate +Destroying a mapped window will generate Expose events on other windows that were obscured by the window being destroyed. @@ -1753,7 +1753,7 @@ error. -To destroy all subwindows of a specified window, use +To destroy all subwindows of a specified window, use . XDestroySubwindows @@ -1793,7 +1793,7 @@ Specifies the window. The -function destroys all inferior windows of the specified window, +function destroys all inferior windows of the specified window, in bottom-to-top stacking order. It causes the X server to generate a DestroyNotify @@ -1801,13 +1801,13 @@ event for each window. If any mapped subwindows were actually destroyed, -causes the X server to generate +causes the X server to generate Expose events on the specified window. This is much more efficient than deleting many windows one at a time because much of the work need be performed only once for all of the windows, rather than for each window. -The subwindows should never be referenced again. +The subwindows should never be referenced again. @@ -1824,7 +1824,7 @@ error. -A window is considered mapped if an +A window is considered mapped if an call has been made on it. It may not be visible on the screen for one of the following reasons: @@ -1850,7 +1850,7 @@ It is entirely clipped by an ancestor. Expose events are generated for the window when part or all of -it becomes visible on the screen. +it becomes visible on the screen. A client receives the Expose events only if it has asked for them. @@ -1859,12 +1859,12 @@ Windows retain their position in the stacking order when they are unmapped. A window manager may want to control the placement of subwindows. -If +If SubstructureRedirectMask has been selected by a window manager on a parent window (usually a root window), a map request initiated by other clients on a child window is not performed, -and the window manager is sent a +and the window manager is sent a MapRequest event. However, if the override-redirect flag on the child had been set to @@ -1874,30 +1874,30 @@ the map request is performed. -A tiling window manager might decide to reposition and resize other clients' +A tiling window manager might decide to reposition and resize other clients' windows and then decide to map the window to its final location. A window manager that wants to provide decoration might reparent the child into a frame first. For further information, see sections 3.2.8 and 10.10. -Only a single client at a time can select for +Only a single client at a time can select for SubstructureRedirectMask. -Similarly, a single client can select for +Similarly, a single client can select for ResizeRedirectMask on a parent window. Then, any attempt to resize the window by another client is suppressed, and -the client receives a +the client receives a ResizeRequest event. -To map a given window, use +To map a given window, use . XMapWindow @@ -1970,14 +1970,14 @@ If the window becomes viewable and no earlier contents for it are remembered, the X server tiles the window with its background. If the window's background is undefined, the existing screen contents are not -altered, and the X server generates zero or more +altered, and the X server generates zero or more Expose events. -If backing-store was maintained while the window was unmapped, no +If backing-store was maintained while the window was unmapped, no Expose events are generated. -If backing-store will now be maintained, +If backing-store will now be maintained, a full-window exposure is always generated. Otherwise, only visible regions may be reported. Similar tiling and exposure take place for any newly viewable inferiors. @@ -1989,25 +1989,25 @@ If the window is an InputOutput window, -generates +generates Expose -events on each +events on each InputOutput window that it causes to be displayed. -If the client maps and paints the window -and if the client begins processing events, +If the client maps and paints the window +and if the client begins processing events, the window is painted twice. To avoid this, -first ask for +first ask for Expose events and then map the window, so the client processes input events as usual. -The event list will include +The event list will include Expose for each -window that has appeared on the screen. +window that has appeared on the screen. The client's normal response to -an +an Expose event should be to repaint the window. This method usually leads to simpler programs and to proper interaction @@ -2070,7 +2070,7 @@ in that it maps the window and all of its subwindows that have had map requests. However, it also raises the specified window to the top of the stack. For additional information, -see +see . @@ -2083,7 +2083,7 @@ errors. -To map all subwindows for a specified window, use +To map all subwindows for a specified window, use . XMapSubwindows @@ -2124,7 +2124,7 @@ Specifies the window. The XMapSubwindows -function maps all subwindows for a specified window in top-to-bottom stacking +function maps all subwindows for a specified window in top-to-bottom stacking order. The X server generates Expose @@ -2153,7 +2153,7 @@ Xlib provides functions that you can use to unmap a window or all subwindows. -To unmap a window, use +To unmap a window, use . XUnmapWindow @@ -2198,7 +2198,7 @@ function unmaps the specified window and causes the X server to generate an UnmapNotify Event XUnmapWindow event. -If the specified window is already unmapped, +If the specified window is already unmapped, has no effect. Normal exposure processing on formerly obscured windows is performed. @@ -2206,7 +2206,7 @@ Any child window will no longer be visible until another map call is made on the parent. In other words, the subwindows are still mapped but are not visible until the parent is mapped. -Unmapping a window will generate +Unmapping a window will generate Expose events on windows that were formerly obscured by it. @@ -2220,7 +2220,7 @@ error. -To unmap all subwindows for a specified window, use +To unmap all subwindows for a specified window, use . XUnmapSubwindows @@ -2264,7 +2264,7 @@ function unmaps all subwindows for the specified window in bottom-to-top stacking order. It causes the X server to generate an UnmapNotify -event on each subwindow and +event on each subwindow and Expose events on formerly obscured windows. UnmapNotify Event @@ -2351,18 +2351,18 @@ If you attempt to set the border-width attribute of an InputOnly window nonzero, a BadMatch -error results. +error results. The sibling member is used to set the sibling window for stacking operations. -The stack_mode member is used to set how the window is to be restacked +The stack_mode member is used to set how the window is to be restacked and can be set to Above, Below, TopIf, BottomIf, -or +or Opposite. @@ -2374,12 +2374,12 @@ and if some other client has selected on the parent, the X server generates a ConfigureRequest event, and no further processing is performed. -Otherwise, -if some other client has selected +Otherwise, +if some other client has selected ResizeRedirectMask on the window and the inside width or height of the window is being changed, -a +a ResizeRequest event is generated, and the current inside width and height are used instead. @@ -2394,15 +2394,15 @@ on the window. -When the geometry of the window is changed as specified, +When the geometry of the window is changed as specified, the window is restacked among siblings, and a ConfigureNotify event is generated if the state of the window actually changes. GravityNotify -events are generated after +events are generated after ConfigureNotify events. -If the inside width or height of the window has actually changed, +If the inside width or height of the window has actually changed, children of the window are affected as specified. @@ -2416,18 +2416,18 @@ the contents of the window also may be moved If regions of the window were obscured but now are not, -exposure processing is performed on these formerly obscured windows, -including the window itself and its inferiors. +exposure processing is performed on these formerly obscured windows, +including the window itself and its inferiors. As a result of increasing the width or height, -exposure processing is also performed on any new regions of the window +exposure processing is also performed on any new regions of the window and any regions where window contents are lost. -The restack check (specifically, the computation for +The restack check (specifically, the computation for BottomIf, TopIf, -and +and Opposite) is performed with respect to the window's final size and position (as controlled by the other arguments of the request), not its initial position. @@ -2438,7 +2438,7 @@ error results. -If a sibling and a stack_mode are specified, +If a sibling and a stack_mode are specified, the window is restacked as follows: @@ -2583,7 +2583,7 @@ This mask is the bitwise inclusive OR of the valid configure window values bits. -Specifies the +Specifies the XWindowChanges structure. @@ -2606,7 +2606,7 @@ If a sibling is specified without a stack_mode or if the window is not actually a sibling, a BadMatch -error results. +error results. Note that the computations for BottomIf, TopIf, @@ -2618,7 +2618,7 @@ other arguments passed to not its initial geometry. Any backing store contents of the window, its inferiors, and other newly visible windows are either discarded or -changed to reflect the current screen contents +changed to reflect the current screen contents (depending on the implementation). @@ -2634,7 +2634,7 @@ errors. -To move a window without changing its size, use +To move a window without changing its size, use . XMoveWindow @@ -2702,28 +2702,28 @@ The function moves the specified window to the specified x and y coordinates, but it does not change the window's size, raise the window, or change the mapping state of the window. -Moving a mapped window may or may not lose the window's contents -depending on if the window is obscured by nonchildren +Moving a mapped window may or may not lose the window's contents +depending on if the window is obscured by nonchildren and if no backing store exists. -If the contents of the window are lost, +If the contents of the window are lost, the X server generates Expose events. Moving a mapped window generates Expose -events on any formerly obscured windows. +events on any formerly obscured windows. -If the override-redirect flag of the window is +If the override-redirect flag of the window is False and some -other client has selected +other client has selected SubstructureRedirectMask on the parent, the X server generates a ConfigureRequest event, and no further processing is -performed. +performed. Otherwise, the window is moved. @@ -2736,7 +2736,7 @@ error. -To change a window's size without changing the upper-left coordinate, use +To change a window's size without changing the upper-left coordinate, use . XResizeWindow @@ -2807,21 +2807,21 @@ the origin and does not restack the window. Changing the size of a mapped window may lose its contents and generate Expose events. -If a mapped window is made smaller, +If a mapped window is made smaller, changing its size generates Expose events on windows that the mapped window formerly obscured. -If the override-redirect flag of the window is +If the override-redirect flag of the window is False and some -other client has selected +other client has selected SubstructureRedirectMask on the parent, the X server generates a ConfigureRequest -event, and no further processing is performed. +event, and no further processing is performed. If either width or height is zero, a BadValue @@ -2839,7 +2839,7 @@ errors. -To change the size and location of a window, use +To change the size and location of a window, use . XMoveResizeWindow @@ -2926,26 +2926,26 @@ Specify the width and height, which define the interior size of the window. The -function changes the size and location of the specified window +function changes the size and location of the specified window without raising it. Moving and resizing a mapped window may generate an Expose event on the window. Depending on the new size and location parameters, -moving and resizing a window may generate +moving and resizing a window may generate Expose -events on windows that the window formerly obscured. +events on windows that the window formerly obscured. -If the override-redirect flag of the window is +If the override-redirect flag of the window is False and some -other client has selected +other client has selected SubstructureRedirectMask on the parent, the X server generates a ConfigureRequest -event, and no further processing is performed. +event, and no further processing is performed. Otherwise, the window size and location are changed. @@ -3037,7 +3037,7 @@ or restack windows. -To raise a window so that no sibling window obscures it, use +To raise a window so that no sibling window obscures it, use . XRaiseWindow @@ -3080,20 +3080,20 @@ The function raises the specified window to the top of the stack so that no sibling window obscures it. -If the windows are regarded as overlapping sheets of paper stacked +If the windows are regarded as overlapping sheets of paper stacked on a desk, then raising a window is analogous to moving the sheet to the top of the stack but leaving its x and y location on the desk constant. -Raising a mapped window may generate +Raising a mapped window may generate Expose -events for the window and any mapped subwindows that were formerly obscured. +events for the window and any mapped subwindows that were formerly obscured. -If the override-redirect attribute of the window is +If the override-redirect attribute of the window is False and some -other client has selected +other client has selected SubstructureRedirectMask on the parent, the X server generates a ConfigureRequest @@ -3110,7 +3110,7 @@ error. -To lower a window so that it does not obscure any sibling windows, use +To lower a window so that it does not obscure any sibling windows, use . XLowerWindow @@ -3157,20 +3157,20 @@ If the windows are regarded as overlapping sheets of paper stacked on a desk, then lowering a window is analogous to moving the sheet to the bottom of the stack but leaving its x and y location on the desk constant. -Lowering a mapped window will generate +Lowering a mapped window will generate Expose events on any windows it formerly obscured. -If the override-redirect attribute of the window is +If the override-redirect attribute of the window is False and some -other client has selected +other client has selected SubstructureRedirectMask on the parent, the X server generates a ConfigureRequest -event, and no processing is performed. +event, and no processing is performed. Otherwise, the window is lowered to the bottom of the stack. @@ -3226,8 +3226,8 @@ Specifies the window. Specifies the direction (up or down) that you want to circulate -the window. -You can pass +the window. +You can pass RaiseLowest or LowerHighest. @@ -3240,12 +3240,12 @@ or The -function circulates children of the specified window in the specified +function circulates children of the specified window in the specified direction. If you specify RaiseLowest, -raises the lowest mapped child (if any) that is occluded +raises the lowest mapped child (if any) that is occluded by another child to the top of the stack. If you specify LowerHighest, @@ -3253,15 +3253,15 @@ If you specify lowers the highest mapped child (if any) that occludes another child to the bottom of the stack. Exposure processing is then performed on formerly obscured windows. -If some other client has selected +If some other client has selected SubstructureRedirectMask -on the window, the X server generates a +on the window, the X server generates a CirculateRequest event, and no further processing is performed. If a child is actually restacked, the X server generates a CirculateNotify -event. +event. @@ -3337,8 +3337,8 @@ error. -To lower the highest mapped child of a window that partially or -completely occludes another child, use +To lower the highest mapped child of a window that partially or +completely occludes another child, use . XCirculateSubwindowsDown @@ -3397,7 +3397,7 @@ error. -To restack a set of windows from top to bottom, use +To restack a set of windows from top to bottom, use . XRestackWindows @@ -3461,14 +3461,14 @@ error results. -If the override-redirect attribute of a window is +If the override-redirect attribute of a window is False and some -other client has selected +other client has selected SubstructureRedirectMask -on the parent, the X server generates +on the parent, the X server generates ConfigureRequest -events for each window whose override-redirect flag is not set, +events for each window whose override-redirect flag is not set, and no further processing is performed. Otherwise, the windows will be restacked in top-to-bottom order. @@ -3557,7 +3557,7 @@ the same as for - + @@ -3573,7 +3573,7 @@ the same as for Specifies the structure from which the values (as specified by the value mask) are to be taken. The value mask should have the appropriate bits -set to indicate which attributes have been set in the structure +set to indicate which attributes have been set in the structure (see section 3.2). @@ -3590,13 +3590,13 @@ function uses the window attributes in the structure to change the specified window attributes. Changing the background does not cause the window contents to be changed. -To repaint the window and its background, use +To repaint the window and its background, use . Setting the border or changing the background such that the border tile origin changes causes the border to be repainted. -Changing the background of a root window to +Changing the background of a root window to None -or +or ParentRelative restores the default background pixmap. Changing the border of a root window to @@ -3604,21 +3604,21 @@ Changing the border of a root window to restores the default border pixmap. Changing the win-gravity does not affect the current position of the window. -Changing the backing-store of an obscured window to +Changing the backing-store of an obscured window to WhenMapped or Always, or changing the backing-planes, backing-pixel, or save-under of a mapped window may have no immediate effect. Changing the colormap of a window (that is, defining a new map, not -changing the contents of the existing map) generates a +changing the contents of the existing map) generates a ColormapNotify event. Changing the colormap of a visible window may have no immediate effect on the screen because the map may not be installed (see ). -Changing the cursor of a root window to +Changing the cursor of a root window to None restores the default cursor. @@ -3626,21 +3626,21 @@ Whenever possible, you are encouraged to share colormaps. -Multiple clients can select input on the same window. +Multiple clients can select input on the same window. Their event masks are maintained separately. -When an event is generated, -it is reported to all interested clients. -However, only one client at a time can select for +When an event is generated, +it is reported to all interested clients. +However, only one client at a time can select for SubstructureRedirectMask, ResizeRedirectMask, and ButtonPressMask. -If a client attempts to select any of these event masks -and some other client has already selected one, +If a client attempts to select any of these event masks +and some other client has already selected one, a BadAccess error results. -There is only one do-not-propagate-mask for a window, +There is only one do-not-propagate-mask for a window, not one per client. @@ -3660,7 +3660,7 @@ errors. -To set the background of a window to a given pixel, use +To set the background of a window to a given pixel, use . XSetWindowBackground @@ -3715,7 +3715,7 @@ function sets the background of the window to the specified pixel value. Changing the background does not cause the window contents to be changed. uses a pixmap of undefined size filled with the pixel value you passed. -If you try to change the background of an +If you try to change the background of an InputOnly window, a BadMatch @@ -3736,7 +3736,7 @@ errors. -To set the background of a window to a given pixmap, use +To set the background of a window to a given pixmap, use . Windowbackground @@ -3796,12 +3796,12 @@ The function sets the background pixmap of the window to the specified pixmap. The background pixmap can immediately be freed if no further explicit references to it are to be made. -If +If ParentRelative -is specified, +is specified, the background pixmap of the window's parent is used, or on the root window, the default background is restored. -If you try to change the background of an +If you try to change the background of an InputOnly window, a BadMatch @@ -3816,7 +3816,7 @@ the window has no defined background. can generate BadMatch, BadPixmap, -and +and BadWindow errors. @@ -3829,7 +3829,7 @@ do not change the current contents of the window. -To change and repaint a window's border to a given pixel, use +To change and repaint a window's border to a given pixel, use . XSetWindowBorder @@ -3870,7 +3870,7 @@ Specifies the window. -Specifies the entry in the colormap. +Specifies the entry in the colormap. @@ -3899,7 +3899,7 @@ errors. -To change and repaint the border tile of a given window, use +To change and repaint the border tile of a given window, use . XSetWindowBorderPixmap diff --git a/specs/libX11/CH04.xml b/specs/libX11/CH04.xml index ae368920..9d571248 100644 --- a/specs/libX11/CH04.xml +++ b/specs/libX11/CH04.xml @@ -23,8 +23,8 @@ information functions to: -Xlib provides functions that you can use to obtain information about -the window tree, the window's current attributes, +Xlib provides functions that you can use to obtain information about +the window tree, the window's current attributes, the window's current geometry, or the current pointer coordinates. Because they are most frequently used by window managers, these functions all return a status to indicate whether the window still @@ -33,8 +33,8 @@ exists. -To obtain the parent, a list of children, and number of children for -a given window, use +To obtain the parent, a list of children, and number of children for +a given window, use . Child Window @@ -121,15 +121,15 @@ Returns the number of children. The -function returns the root ID, the parent window ID, +function returns the root ID, the parent window ID, a pointer to the list of children windows -(NULL when there are no children), +(NULL when there are no children), and the number of children in the list for the specified window. -The children are listed in current stacking order, from bottom-most +The children are listed in current stacking order, from bottom-most (first) to top-most (last). returns zero if it fails and nonzero if it succeeds. -To free a non-NULL children list when it is no longer needed, use +To free a non-NULL children list when it is no longer needed, use . @@ -142,7 +142,7 @@ error. -To obtain the current attributes of a given window, use +To obtain the current attributes of a given window, use . XGetWindowAttributes @@ -236,10 +236,10 @@ typedef struct { The x and y members are set to the upper-left outer corner relative to the parent window's origin. -The width and height members are set to the inside size of the window, +The width and height members are set to the inside size of the window, not including the border. The border_width member is set to the window's border width in pixels. -The depth member is set to the depth of the window +The depth member is set to the depth of the window (that is, bits per pixel for the object). The visual member is a pointer to the screen's associated Visual @@ -294,29 +294,29 @@ see section 3.2.3. The backing_store member is set to indicate how the X server should maintain -the contents of a window -and can be +the contents of a window +and can be WhenMapped, Always, or NotUseful. -The backing_planes member is set to indicate (with bits set to 1) which bit -planes of the window hold dynamic data that must be preserved in backing_stores +The backing_planes member is set to indicate (with bits set to 1) which bit +planes of the window hold dynamic data that must be preserved in backing_stores and during save_unders. -The backing_pixel member is set to indicate what values to use +The backing_pixel member is set to indicate what values to use for planes not set in backing_planes. -The save_under member is set to +The save_under member is set to True or False. The colormap member is set to the colormap for the specified window and can be -a colormap ID or +a colormap ID or None. -The map_installed member is set to indicate whether the colormap is -currently installed and can be +The map_installed member is set to indicate whether the colormap is +currently installed and can be True or False. @@ -330,17 +330,17 @@ is used if the window is mapped but some ancestor is unmapped. -The all_event_masks member is set to the bitwise inclusive OR of all event +The all_event_masks member is set to the bitwise inclusive OR of all event masks selected on the window by all clients. -The your_event_mask member is set to the bitwise inclusive OR of all event +The your_event_mask member is set to the bitwise inclusive OR of all event masks selected by the querying client. -The do_not_propagate_mask member is set to the bitwise inclusive OR of the +The do_not_propagate_mask member is set to the bitwise inclusive OR of the set of events that should not propagate. The override_redirect member is set to indicate whether this window overrides -structure control facilities and can be +structure control facilities and can be True or False. @@ -349,7 +349,7 @@ Window manager clients should ignore the window if this member is -The screen member is set to a screen pointer that gives you a back pointer +The screen member is set to a screen pointer that gives you a back pointer to the correct screen. This makes it easier to obtain the screen information without having to loop over the root window fields to see which field matches. @@ -366,7 +366,7 @@ errors. -To obtain the current geometry of a given drawable, use +To obtain the current geometry of a given drawable, use . XGetGeometry @@ -435,7 +435,7 @@ Returns the root window. Return the x and y coordinates that define the location of the drawable. -For a window, +For a window, these coordinates specify the upper-left outer corner relative to its parent's origin. For pixmaps, these coordinates are always zero. @@ -460,7 +460,7 @@ For pixmaps, these coordinates are always zero. Return the drawable's dimensions (width and height). -For a window, +For a window, these dimensions specify the inside size, not including the border. @@ -471,7 +471,7 @@ these dimensions specify the inside size, not including the border. -Returns the border width in pixels. +Returns the border width in pixels. If the drawable is a pixmap, it returns zero. @@ -640,12 +640,12 @@ If returns True, it takes the src_x and src_y coordinates relative -to the source window's origin and returns these coordinates to +to the source window's origin and returns these coordinates to dest_x_return and dest_y_return relative to the destination window's origin. If -returns +returns False, src_w and dest_w are on different screens, and dest_x_return and dest_y_return are zero. @@ -665,7 +665,7 @@ error. To obtain the screen coordinates of the pointer -or to determine the pointer coordinates relative to a specified window, use +or to determine the pointer coordinates relative to a specified window, use . XQueryPointer @@ -788,20 +788,20 @@ function returns the root window the pointer is logically on and the pointer coordinates relative to the root window's origin. If -returns +returns False, the pointer is not on the same screen as the specified window, and -returns +returns None to child_return and zero to win_x_return and win_y_return. -If +If -returns +returns True, the pointer coordinates returned to win_x_return and win_y_return are relative to the origin of the specified window. -In this case, +In this case, returns the child that contains the pointer, if any, or else @@ -811,10 +811,10 @@ to child_return. -returns the current logical state of the keyboard buttons +returns the current logical state of the keyboard buttons and the modifier keys in mask_return. It sets mask_return to the bitwise inclusive OR of one or more -of the button or modifier key bitmasks to match +of the button or modifier key bitmasks to match the current state of the mouse buttons and the modifier keys. @@ -846,7 +846,7 @@ define any other arbitrary information and associate it with windows. Each property has a name, which is an ISO Latin-1 string. For each named property, -a unique identifier (atom) is associated with it. +a unique identifier (atom) is associated with it. A property also has a type, for example, string or integer. These types are also indicated using atoms, so arbitrary new types can be defined. @@ -867,7 +867,7 @@ quantities, or 32-bit quantities. This permits the X server to present the data in the byte order that the client expects. -If you define further properties of complex type, +If you define further properties of complex type, you must encode and decode them yourself. These functions must be carefully written if they are to be portable. For further information about how to write a library extension, @@ -881,12 +881,12 @@ arbitrary extension in this type scheme. Certain property names are predefined in the server for commonly used functions. -The atoms for these properties are defined in +The atoms for these properties are defined in <X11/Xatom.h>. X11/Xatom.h Files<X11/Xatom.h> Headers<X11/Xatom.h> -To avoid name clashes with user symbols, the +To avoid name clashes with user symbols, the #define name for each atom has the XA_ prefix. For an explanation of the functions that let you get and set @@ -904,14 +904,14 @@ and the X Logical Font Descr You can use properties to communicate other information between applications. -The functions described in this section let you define new properties +The functions described in this section let you define new properties and get the unique atom IDs in your applications. -Although any particular atom can have some client interpretation -within each of the name spaces, -atoms occur in five distinct name spaces within the protocol: +Although any particular atom can have some client interpretation +within each of the name spaces, +atoms occur in five distinct name spaces within the protocol: @@ -931,12 +931,12 @@ Property types -Font properties +Font properties -Type of a +Type of a ClientMessage event (none are built into the X server) @@ -955,7 +955,7 @@ The built-in selection property names are: -The built-in property names are: +The built-in property names are: CUT_BUFFER0 CUT_BUFFER1 @@ -989,7 +989,7 @@ The built-in property names are: -The built-in property types are: +The built-in property types are: ARC ATOM @@ -1012,7 +1012,7 @@ The built-in property types are: -The built-in font property names are: +The built-in font property names are: MIN_SPACE NORM_SPACE @@ -1049,7 +1049,7 @@ see section 8.5. -To return an atom for a given name, use +To return an atom for a given name, use . Atominterning @@ -1103,18 +1103,18 @@ The function returns the atom identifier associated with the specified atom_name string. -If only_if_exists is +If only_if_exists is False, the atom is created if it does not exist. Therefore, can return None. -If the atom name is not in the Host Portable Character Encoding, +If the atom name is not in the Host Portable Character Encoding, the result is implementation-dependent. Uppercase and lowercase matter; -the strings ``thing'', ``Thing'', and ``thinG'' -all designate different atoms. +the strings ``thing'', ``Thing'', and ``thinG'' +all designate different atoms. The atom will remain defined even after the client's connection closes. It will become undefined only when the last connection to the X server closes. @@ -1131,7 +1131,7 @@ errors. -To return atoms for an array of names, use +To return atoms for an array of names, use . Atominterning @@ -1231,7 +1231,7 @@ errors. -To return a name for a given atom identifier, use +To return a name for a given atom identifier, use . Atomgetting name @@ -1290,7 +1290,7 @@ error. -To return the names for an array of atom identifiers, use +To return the names for an array of atom identifiers, use . Atomgetting name @@ -1396,7 +1396,7 @@ is used to represent 32-bit quantities. -Xlib provides functions that you can use to obtain, +Xlib provides functions that you can use to obtain, change, update, or interchange window properties. In addition, Xlib provides other utility functions for inter-client communication @@ -1405,7 +1405,7 @@ communication -To obtain the type, format, and value of a property of a given window, use +To obtain the type, format, and value of a property of a given window, use . Propertygetting @@ -1467,7 +1467,7 @@ Specifies the property name. -Specifies the offset in the specified property (in 32-bit quantities) +Specifies the offset in the specified property (in 32-bit quantities) where the data is to be retrieved. @@ -1529,7 +1529,7 @@ Returns the actual format of the property. -Returns the actual number of 8-bit, 16-bit, or 32-bit items +Returns the actual number of 8-bit, 16-bit, or 32-bit items stored in the prop_return data. @@ -1540,7 +1540,7 @@ stored in the prop_return data. -Returns the number of bytes remaining to be read in the property if +Returns the number of bytes remaining to be read in the property if a partial read was performed. @@ -1572,9 +1572,9 @@ sets the return arguments as follows: If the specified property does not exist for the specified window, -returns +returns None -to actual_type_return and the value zero to +to actual_type_return and the value zero to actual_format_return and bytes_after_return. The nitems_return argument is empty. In this case, the delete argument is ignored. @@ -1582,13 +1582,13 @@ In this case, the delete argument is ignored. -If the specified property exists +If the specified property exists but its type does not match the specified type, -returns the actual property type to actual_type_return, -the actual property format (never zero) to actual_format_return, +returns the actual property type to actual_type_return, +the actual property format (never zero) to actual_format_return, and the property length in bytes -(even if the actual_format_return is 16 or 32) +(even if the actual_format_return is 16 or 32) to bytes_after_return. It also ignores the delete argument. The nitems_return argument is empty. @@ -1596,13 +1596,13 @@ The nitems_return argument is empty. -If the specified property exists and either you assign +If the specified property exists and either you assign AnyPropertyType to the req_type argument or the specified type matches the actual property type, returns the actual property type to actual_type_return and the actual -property format (never zero) to actual_format_return. -It also returns a value to bytes_after_return and nitems_return, by +property format (never zero) to actual_format_return. +It also returns a value to bytes_after_return and nitems_return, by defining the following values: @@ -1626,8 +1626,8 @@ from zero), and its length in bytes is L. If the value for long_offset causes L to be negative, a BadValue -error results. -The value of bytes_after_return is A, +error results. +The value of bytes_after_return is A, giving the number of trailing unread bytes in the stored property. @@ -1647,19 +1647,19 @@ array and should be cast to that type to obtain the elements. -always allocates one extra byte in prop_return -(even if the property is zero length) +always allocates one extra byte in prop_return +(even if the property is zero length) and sets it to zero so that simple properties consisting of characters do not have to be copied into yet another string before use. -If delete is +If delete is True -and bytes_after_return is zero, +and bytes_after_return is zero, -deletes the property -from the window and generates a +deletes the property +from the window and generates a PropertyNotify event on the window. @@ -1685,7 +1685,7 @@ errors. -To obtain a given window's property list, use +To obtain a given window's property list, use . Propertylisting @@ -1737,7 +1737,7 @@ Returns the length of the properties array. The -function returns a pointer to an array of atom properties that are defined for +function returns a pointer to an array of atom properties that are defined for the specified window or returns NULL if no properties were found. To free the memory allocated by this function, use . @@ -1816,7 +1816,7 @@ Specifies the property name. Specifies the type of the property. The X server does not interpret the type but simply -passes it back to an application that later calls +passes it back to an application that later calls . @@ -1834,7 +1834,7 @@ This information allows the X server to correctly perform byte-swap operations as necessary. If the format is 16-bit or 32-bit, you must explicitly cast your data pointer to an (unsigned char *) in the call -to +to . @@ -1910,7 +1910,7 @@ The type and format must match the existing property value, or a BadMatch error results. -If the property is undefined, +If the property is undefined, it is treated as defined with the correct type and format with zero-length data. @@ -2034,25 +2034,25 @@ function allows you to rotate properties on a window and causes the X server to generate PropertyNotify events. -If the property names in the properties array are viewed as being numbered +If the property names in the properties array are viewed as being numbered starting from zero and if there are num_prop property names in the list, -then the value associated with property name I becomes the value associated +then the value associated with property name I becomes the value associated with property name (I + npositions) mod N for all I from zero to N − 1. The effect is to rotate the states by npositions places around the virtual ring -of property names (right for positive npositions, +of property names (right for positive npositions, left for negative npositions). If npositions mod N is nonzero, the X server generates a PropertyNotify event for each property in the order that they are listed in the array. -If an atom occurs more than once in the list or no property with that +If an atom occurs more than once in the list or no property with that name is defined for the window, -a +a BadMatch error results. -If a +If a BadAtom -or +or BadMatch error results, no properties are changed. @@ -2070,7 +2070,7 @@ errors. -To delete a property on a given window, use +To delete a property on a given window, use . Propertydeleting @@ -2153,8 +2153,8 @@ the type of the data. A selection can be thought of as an indirect property with a dynamic type. That is, rather than having the property stored in the X server, the property is maintained by some client (the owner). -A selection is global in nature (considered to belong to the user -but be maintained by clients) rather than being private to a particular +A selection is global in nature (considered to belong to the user +but be maintained by clients) rather than being private to a particular window subhierarchy or a particular set of clients. @@ -2162,7 +2162,7 @@ window subhierarchy or a particular set of clients. Xlib provides functions that you can use to set, get, or request conversion of selections. This allows applications to implement the notion of current selection, -which requires that notification be sent to applications when they no +which requires that notification be sent to applications when they no longer own the selection. Applications that support selection often highlight the current selection and so must be informed when another application has @@ -2181,7 +2181,7 @@ whether the contents of the image should be sent in XY format or Z format. The target type can also be used to control the class of -contents transmitted, for example, +contents transmitted, for example, asking for the ``looks'' (fonts, line spacing, indentation, and so forth) of a paragraph selection, not the text of the paragraph. @@ -2192,7 +2192,7 @@ The protocol does not constrain the semantics. -To set the selection owner, use +To set the selection owner, use . Selectionsetting the owner @@ -2261,7 +2261,7 @@ The function changes the owner and last-change time for the specified selection and has no effect if the specified time is earlier than the current -last-change time of the specified selection +last-change time of the specified selection or is later than the current X server time. Otherwise, the last-change time is set to the specified time, with @@ -2269,7 +2269,7 @@ with replaced by the current server time. If the owner window is specified as None, -then the owner of the selection becomes +then the owner of the selection becomes None (that is, no owner). Otherwise, the owner of the selection becomes the client executing @@ -2283,7 +2283,7 @@ is not the same as the current owner of the selection and the current owner is not None, -the current owner is sent a +the current owner is sent a SelectionClear event. If the client that is the owner of a selection is later @@ -2296,7 +2296,7 @@ reverts to but the last-change time is not affected. The selection atom is uninterpreted by the X server. -returns the owner window, which is reported in +returns the owner window, which is reported in SelectionRequest and SelectionClear @@ -2315,7 +2315,7 @@ errors. -To return the selection owner, use +To return the selection owner, use . Selectiongetting the owner @@ -2376,7 +2376,7 @@ error. -To request conversion of a selection, use +To request conversion of a selection, use . Selectionconverting @@ -2432,7 +2432,7 @@ Specifies the target atom. Specifies the property name. -You also can pass +You also can pass None. diff --git a/specs/libX11/CH05.xml b/specs/libX11/CH05.xml index e22d26d6..032e113d 100644 --- a/specs/libX11/CH05.xml +++ b/specs/libX11/CH05.xml @@ -12,7 +12,7 @@ Pixmaps can only be used on the screen on which they were created. Pixmaps are off-screen resources that are used for various operations, -such as defining cursors as tiling patterns +such as defining cursors as tiling patterns or as the source for certain raster operations. Most graphics requests can operate either on a window or on a pixmap. A bitmap is a single bit-plane pixmap. @@ -53,7 +53,7 @@ Specifies the connection to the X server. -Specifies which screen the pixmap is created on. +Specifies which screen the pixmap is created on. @@ -96,11 +96,11 @@ The function creates a pixmap of the width, height, and depth you specified and returns a pixmap ID that identifies it. -It is valid to pass an +It is valid to pass an InputOnly window to the drawable argument. The width and height arguments must be nonzero, -or a +or a BadValue error results. The depth argument must be one of the depths supported by the screen @@ -192,15 +192,15 @@ error. Each window can have a different cursor defined for it. -Whenever the pointer is in a visible window, +Whenever the pointer is in a visible window, it is set to the cursor defined for that window. -If no cursor was defined for that window, +If no cursor was defined for that window, the cursor is the one defined for the parent window. -From X's perspective, -a cursor consists of a cursor source, mask, colors, and a hotspot. +From X's perspective, +a cursor consists of a cursor source, mask, colors, and a hotspot. The mask pixmap determines the shape of the cursor and must be a depth of one. The source pixmap must have a depth of one, @@ -208,7 +208,7 @@ and the colors determine the colors of the source. The hotspot defines the point on the cursor that is reported when a pointer event occurs. There may be limitations imposed by the hardware on -cursors as to size and whether a mask is implemented. +cursors as to size and whether a mask is implemented. XQueryBestCursor can be used to find out what sizes are possible. @@ -357,7 +357,7 @@ Specifies the character glyph for the source. -Specifies the glyph character for the mask. +Specifies the glyph character for the mask. @@ -367,7 +367,7 @@ Specifies the glyph character for the mask. -Specifies the RGB values for the foreground of the source. +Specifies the RGB values for the foreground of the source. @@ -389,33 +389,33 @@ The function is similar to -except that the source and mask bitmaps are obtained from the specified +except that the source and mask bitmaps are obtained from the specified font glyphs. -The source_char must be a defined glyph in source_font, +The source_char must be a defined glyph in source_font, or a BadValue error results. -If mask_font is given, +If mask_font is given, mask_char must be a defined glyph in mask_font, or a BadValue error results. The mask_font and character are optional. The origins of the source_char and mask_char (if defined) glyphs are -positioned coincidently and define the hotspot. -The source_char and mask_char need not have the same bounding box metrics, +positioned coincidently and define the hotspot. +The source_char and mask_char need not have the same bounding box metrics, and there is no restriction on the placement of the hotspot relative to the bounding -boxes. +boxes. If no mask_char is given, all pixels of the source are displayed. You can free the fonts immediately by calling -if no further explicit references to them are to be made. +if no further explicit references to them are to be made. -For 2-byte matrix fonts, +For 2-byte matrix fonts, the 16-bit value should be formed with the byte1 -member in the most significant byte and the byte2 member in the +member in the most significant byte and the byte2 member in the least significant byte. @@ -489,7 +489,7 @@ Specifies the cursor's source bits to be displayed or -Specifies the RGB values for the foreground of the source. +Specifies the RGB values for the foreground of the source. @@ -541,15 +541,15 @@ or screen. The foreground color is used for the pixels set to 1 in the source, and the background color is used for the pixels set to 0. -Both source and mask, if specified, must have depth one (or a +Both source and mask, if specified, must have depth one (or a BadMatch error results) but can have any root. The mask argument defines the shape of the cursor. The pixels set to 1 in the mask define which source pixels are displayed, and the pixels set to 0 define which pixels are ignored. -If no mask is given, +If no mask is given, all pixels of the source are displayed. -The mask, if present, must be the same size as the pixmap defined by the +The mask, if present, must be the same size as the pixmap defined by the source argument, or a BadMatch error results. @@ -657,7 +657,7 @@ information for. -Return the best width and height that is closest to the specified width +Return the best width and height that is closest to the specified width and height. @@ -718,7 +718,7 @@ Specifies the connection to the X server. -Specifies the cursor. +Specifies the cursor. @@ -728,7 +728,7 @@ Specifies the cursor. -Specifies the RGB values for the foreground of the source. +Specifies the RGB values for the foreground of the source. @@ -795,7 +795,7 @@ Specifies the connection to the X server. -Specifies the cursor. +Specifies the cursor. @@ -805,7 +805,7 @@ Specifies the cursor. The -function deletes the association between the cursor resource ID +function deletes the association between the cursor resource ID and the specified cursor. The cursor storage is freed when no other resource references it. The specified cursor ID should not be referred to again. diff --git a/specs/libX11/CH06.xml b/specs/libX11/CH06.xml index 66f6e303..7c1c17fa 100644 --- a/specs/libX11/CH06.xml +++ b/specs/libX11/CH06.xml @@ -96,8 +96,8 @@ Functions in this chapter manipulate the representation of color on the screen. For each possible value that a pixel can take in a window, there is a color cell in the colormap. -For example, -if a window is 4 bits deep, pixel values 0 through 15 are defined. +For example, +if a window is 4 bits deep, pixel values 0 through 15 are defined. A colormap is a collection of color cells. A color cell consists of a triple of red, green, and blue (RGB) values. The hardware imposes limits on the number of significant @@ -105,7 +105,7 @@ bits in these values. As each pixel is read out of display memory, the pixel is looked up in a colormap. The RGB value of the cell determines what color is displayed on the screen. -On a grayscale display with a black-and-white monitor, +On a grayscale display with a black-and-white monitor, the values are combined to determine the brightness on the screen. @@ -113,8 +113,8 @@ the values are combined to determine the brightness on the screen. Typically, an application allocates color cells or sets of color cells to obtain the desired colors. The client can allocate read-only cells. -In which case, -the pixel values for these colors can be shared among multiple applications, +In which case, +the pixel values for these colors can be shared among multiple applications, and the RGB value of the cell cannot be changed. If the client allocates read/write cells, they are exclusively owned by the client, @@ -147,7 +147,7 @@ and Colormaps are local to a particular screen. Screens always have a default colormap, and programs typically allocate cells out of this colormap. -Generally, you should not write applications that monopolize +Generally, you should not write applications that monopolize color resources. Although some hardware supports multiple colormaps installed at one time, many of the hardware displays @@ -156,21 +156,21 @@ are written to encourage sharing of colormap entries between applications. -The +The DefaultColormap macro returns the default colormap. -The +The DefaultVisual macro returns the default visual type for the specified screen. Color map -Possible visual types are +Possible visual types are StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, -or +or DirectColor (see section 3.1). @@ -195,7 +195,7 @@ structure, which contains: typedef struct { unsigned long pixel; /* pixel value */ unsigned short red, green, blue; /* rgb values */ - char flags; /* DoRed, DoGreen, DoBlue */ + char flags; /* DoRed, DoGreen, DoBlue */ char pad; } XColor; @@ -207,15 +207,15 @@ The red, green, and blue values are always in the range 0 to 65535 inclusive, independent of the number of bits actually used in the display hardware. The server scales these values down to the range used by the hardware. -Black is represented by (0,0,0), +Black is represented by (0,0,0), and white is represented by (65535,65535,65535). Color In some functions, -the flags member controls which of the red, green, and blue members is used +the flags member controls which of the red, green, and blue members is used and can be the inclusive OR of zero or more of DoRed, DoGreen, -and +and DoBlue. @@ -231,7 +231,7 @@ Like the structure, the XcmsColor structure contains pixel -and color specification information (the spec member in the +and color specification information (the spec member in the XcmsColor structure). XcmsColor @@ -264,7 +264,7 @@ typedef struct { -Because the color specification can be encoded for the various color spaces, +Because the color specification can be encoded for the various color spaces, encoding for the spec member is identified by the format member, which is of type XcmsColorFormat. @@ -300,7 +300,7 @@ time the program is executed. If references to such a color space must be made outside the client (for example, storing a color specification in a file), then reference should be made by color space string prefix -(see +(see and ). @@ -462,9 +462,9 @@ Red, green, and blue values appropriate for the specified output device. XcmsRGB values are of type unsigned short, scaled from 0 to 65535 inclusive, -and are interchangeable with the red, green, and blue values in an +and are interchangeable with the red, green, and blue values in an XColor -structure. +structure. @@ -473,7 +473,7 @@ structure. It is important to note that RGB Intensity values are not gamma corrected values. In contrast, -RGB Device values generated as a result of converting color specifications +RGB Device values generated as a result of converting color specifications are always gamma corrected, and RGB Device values acquired as a result of querying a colormap or passed in by the client are assumed by Xlib to be gamma corrected. @@ -592,7 +592,7 @@ rgb:<red>/<green>/<blue> -Note that h indicates the value scaled in 4 bits, +Note that h indicates the value scaled in 4 bits, hh the value scaled in 8 bits, hhh the value scaled in 12 bits, and hhhh the value scaled in 16 bits, respectively. @@ -600,7 +600,7 @@ and hhhh the value scaled in 16 bits, respectivel Typical examples are the strings ``rgb:ea/75/52'' and ``rgb:ccc/320/320'', -but mixed numbers of hexadecimal digit strings +but mixed numbers of hexadecimal digit strings (``rgb:ff/a5/0'' and ``rgb:ccc/32/0'') are also allowed. @@ -627,7 +627,7 @@ a numeric specification, in one of the following formats: The R, G, and B represent single hexadecimal digits. -When fewer than 16 bits each are specified, +When fewer than 16 bits each are specified, they represent the most significant bits of the value (unlike the ``rgb:'' syntax, in which values are scaled). For example, the string ``#3a7'' is the same as ``#3000a0007000''. @@ -657,7 +657,7 @@ Note that red, green, and blue are floating-point values between 0.0 and 1.0, inclusive. The input format for these values is an optional sign, a string of numbers possibly containing a decimal point, -and an optional exponent field containing an E or e +and an optional exponent field containing an E or e followed by a possibly signed integer string. @@ -748,7 +748,7 @@ associated with color specifications (that is, the Client White Point). The client can specify the gamut handling callbacks and client data as well as the Client White Point. Xlib does not preclude the X client from performing other -forms of gamut handling (for example, gamut expansion); +forms of gamut handling (for example, gamut expansion); however, Xlib does not provide direct support for gamut handling other than white adjustment and gamut compression. @@ -772,7 +772,7 @@ so the default CCC attributes can be modified to affect new CCCs. Xcms functions in which gamut mapping can occur return Status -and have specific status values defined for them, +and have specific status values defined for them, as follows: @@ -852,7 +852,7 @@ Specifies the window on whose screen you want to create a colormap. Specifies a visual type supported on the screen. -If the visual type is not one supported by the screen, +If the visual type is not one supported by the screen, a BadMatch error results. @@ -866,9 +866,9 @@ error results. Specifies the colormap entries to be allocated. -You can pass +You can pass AllocNone -or +or AllocAll. @@ -880,14 +880,14 @@ or The -function creates a colormap of the specified visual type for the screen -on which the specified window resides and returns the colormap ID +function creates a colormap of the specified visual type for the screen +on which the specified window resides and returns the colormap ID associated with it. Note that the specified window is only used to determine the screen. -The initial values of the colormap entries are undefined for the +The initial values of the colormap entries are undefined for the visual classes GrayScale, PseudoColor, @@ -936,7 +936,7 @@ For DirectColor, the effect is as if an -call returned a pixel value of zero and red_mask, green_mask, +call returned a pixel value of zero and red_mask, green_mask, and blue_mask values containing the same bits as the corresponding masks in the specified visual. However, in all cases, @@ -1001,13 +1001,13 @@ The function creates a colormap of the same visual type and for the same screen as the specified colormap and returns the new colormap ID. It also moves all of the client's existing allocation from the specified -colormap to the new colormap with their color values intact -and their read-only or writable characteristics intact and frees those entries +colormap to the new colormap with their color values intact +and their read-only or writable characteristics intact and frees those entries in the specified colormap. Color values in other entries in the new colormap are undefined. If the specified colormap was created by the client with alloc set to AllocAll, -the new colormap is also created with +the new colormap is also created with AllocAll, all color values for all entries are copied from the specified colormap, and then all entries in the specified colormap are freed. @@ -1034,7 +1034,7 @@ errors. -To destroy a colormap, use +To destroy a colormap, use . XFreeColormap @@ -1075,7 +1075,7 @@ Specifies the colormap that you want to destroy. The -function deletes the association between the colormap resource ID +function deletes the association between the colormap resource ID and the colormap and frees the colormap storage. However, this function has no effect on the default colormap for a screen. If the specified colormap is an installed map for a screen, @@ -1155,7 +1155,7 @@ Specifies the colormap. -Specifies the color name string (for example, red) whose color +Specifies the color name string (for example, red) whose color definition structure you want returned. @@ -1190,9 +1190,9 @@ The function looks up the string name of a color with respect to the screen associated with the specified colormap. It returns both the exact color values and -the closest values provided by the screen +the closest values provided by the screen with respect to the visual type of the specified colormap. -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. @@ -1282,7 +1282,7 @@ The function looks up the string name of a color with respect to the screen associated with the specified colormap. It returns the exact color value. -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. @@ -1387,7 +1387,7 @@ color specification. If the format is XcmsUndefinedFormat and the color string contains a color name, -the specification is returned in the format used +the specification is returned in the format used to store the color in the database. @@ -1402,10 +1402,10 @@ The function looks up the string name of a color with respect to the screen associated with the specified colormap. It returns both the exact color values and -the closest values provided by the screen +the closest values provided by the screen with respect to the visual type of the specified colormap. The values are returned in the format specified by result_format. -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. @@ -1417,7 +1417,7 @@ if the name is resolved; otherwise, it returns XcmsFailure. If XcmsSuccessWithCompression -is returned, the color specification returned in +is returned, the color specification returned in color_screen_return is the result of gamut compression. @@ -1429,7 +1429,7 @@ color_screen_return is the result of gamut compression. -There are two ways of allocating color cells: +There are two ways of allocating color cells: explicitly as read-only entries, one pixel value at a time, or read/write, where you can allocate a number of color cells and planes simultaneously. @@ -1589,7 +1589,7 @@ Specifies the colormap. -Specifies the color to allocate and returns the pixel and color +Specifies the color to allocate and returns the pixel and color that is actually used in the colormap. @@ -1615,7 +1615,7 @@ function is similar to except the color can be specified in any format. The -function ultimately calls +function ultimately calls to allocate a read-only color cell (colormap entry) with the specified color. @@ -1626,14 +1626,14 @@ to an RGB value and then passes this to returns the pixel value of the color cell and the color specification actually allocated. This returned color specification is the result of converting the RGB value -returned by +returned by into the format specified with the result_format argument. -If there is no interest in a returned color specification, +If there is no interest in a returned color specification, unnecessary computation can be bypassed if result_format is set to XcmsRGBFormat. The corresponding colormap cell is read-only. -If this routine returns +If this routine returns XcmsFailure, the color_in_out color specification is left unchanged. @@ -1695,7 +1695,7 @@ Specifies the colormap. -Specifies the color name string (for example, red) whose color +Specifies the color name string (for example, red) whose color definition structure you want returned. @@ -1733,7 +1733,7 @@ It returns both the exact database definition and the closest color supported by the screen. The allocated color cell is read-only. The pixel value is returned in screen_def_return. -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. If screen_def_return and exact_def_return @@ -1748,7 +1748,7 @@ otherwise, it returns zero. can generate a BadColor -error. +error. @@ -1813,7 +1813,7 @@ returned. -Returns the pixel value of the color cell and color specification +Returns the pixel value of the color cell and color specification that actually is stored for that cell. @@ -1846,7 +1846,7 @@ color specification. If the format is XcmsUndefinedFormat and the color string contains a color name, -the specification is returned in the format used +the specification is returned in the format used to store the color in the database. @@ -1872,7 +1872,7 @@ structure (see converted to an RGB value, and finally passed to . -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. @@ -1973,8 +1973,8 @@ Returns an array of plane masks. -Specifies the number of plane masks that are to be returned in the plane masks -array. +Specifies the number of plane masks that are to be returned in the plane masks +array. @@ -1984,7 +1984,7 @@ array. -Returns an array of pixel values. +Returns an array of pixel values. @@ -1994,8 +1994,8 @@ Returns an array of pixel values. -Specifies the number of pixel values that are to be returned in the -pixels_return array. +Specifies the number of pixel values that are to be returned in the +pixels_return array. @@ -2011,7 +2011,7 @@ The number of colors must be positive and the number of planes nonnegative, or a BadValue error results. -If ncolors and nplanes are requested, +If ncolors and nplanes are requested, then ncolors pixels and nplane plane masks are returned. No mask will have any bits set to 1 in common with @@ -2021,23 +2021,23 @@ ncolors × 2nplanes distinct pixels can be produced. All of these are allocated writable by the request. -For +For GrayScale -or +or PseudoColor, -each mask has exactly one bit set to 1. -For +each mask has exactly one bit set to 1. +For DirectColor, each has exactly three bits set to 1. -If contig is +If contig is True and if all masks are ORed -together, a single contiguous set of bits set to 1 will be formed for +together, a single contiguous set of bits set to 1 will be formed for GrayScale -or +or PseudoColor and three contiguous sets of bits set to 1 (one within each -pixel subfield) for +pixel subfield) for DirectColor. The RGB values of the allocated entries are undefined. @@ -2120,7 +2120,7 @@ Specifies a Boolean value that indicates whether the planes must be contiguous. -Returns an array of pixel values. +Returns an array of pixel values. returns the pixel values in this array. @@ -2132,8 +2132,8 @@ returns the pixel values in this array. -Specifies the number of pixel values that are to be returned in the -pixels_return array. +Specifies the number of pixel values that are to be returned in the +pixels_return array. @@ -2168,7 +2168,7 @@ pixels_return array. Specify the number of red, green, and blue planes. -The value you pass must be nonnegative. +The value you pass must be nonnegative. @@ -2209,26 +2209,26 @@ Return bit masks for the red, green, and blue planes. -The specified ncolors must be positive; +The specified ncolors must be positive; and nreds, ngreens, and nblues must be nonnegative, or a BadValue error results. -If ncolors colors, nreds reds, ngreens greens, and nblues blues are requested, -ncolors pixels are returned; and the masks have nreds, ngreens, and +If ncolors colors, nreds reds, ngreens greens, and nblues blues are requested, +ncolors pixels are returned; and the masks have nreds, ngreens, and nblues bits set to 1, respectively. -If contig is +If contig is True, each mask will have a contiguous set of bits set to 1. No mask will have any bits set to 1 in common with any other mask or with any of the pixels. -For +For DirectColor, each mask will lie within the corresponding pixel subfield. By ORing together -subsets of masks with each pixel value, +subsets of masks with each pixel value, ncolors × 2(nreds+ngreens+nblues) distinct pixel values can be produced. All of these are allocated by the request. @@ -2240,15 +2240,15 @@ ncolors × 2ngreens independent green entries, and ncolors × 2nblues independent blue entries. -This is true even for +This is true even for PseudoColor. When the colormap entry of a pixel -value is changed (using +value is changed (using , , -or +or ), -the pixel is decomposed according to the masks, +the pixel is decomposed according to the masks, and the corresponding independent entries are updated. returns nonzero if it succeeded or zero if it failed. @@ -2321,7 +2321,7 @@ colormap. -Specifies the number of pixels. +Specifies the number of pixels. @@ -2345,11 +2345,11 @@ The function frees the cells represented by pixels whose values are in the pixels array. The planes argument should not have any bits set to 1 in common with any of the -pixels. +pixels. The set of all pixels is produced by ORing together subsets of the planes argument with the pixels. The request frees all of these pixels that -were allocated by the client (using +were allocated by the client (using XAllocColor XAllocNamedColor XAllocColorCells @@ -2357,10 +2357,10 @@ were allocated by the client (using , , , -and +and ). Note that freeing an -individual pixel obtained from +individual pixel obtained from may not actually allow it to be reused until all of its related pixels are also freed. @@ -2372,8 +2372,8 @@ it must free the entry that many times before the entry is actually freed. All specified pixels that are allocated by the client in the colormap are -freed, even if one or more pixels produce an error. -If a specified pixel is not a valid index into the colormap, a +freed, even if one or more pixels produce an error. +If a specified pixel is not a valid index into the colormap, a BadValue error results. If a specified pixel is not allocated by the @@ -2384,8 +2384,8 @@ to ), a BadAccess -error results. -If more than one pixel is in error, +error results. +If more than one pixel is in error, the one that gets reported is arbitrary. @@ -2483,7 +2483,7 @@ and/or in the flags member of the XColor structure. -If the colormap is an installed map for its screen, +If the colormap is an installed map for its screen, the changes are visible immediately. @@ -2553,7 +2553,7 @@ Specifies an array of color definition structures to be stored. -Specifies the number of +Specifies the number of XColor structures in the color definition array. @@ -2570,7 +2570,7 @@ function changes the colormap entries of the pixel values specified in the pixel members of the XColor structures. -You specify which color components are to be changed by setting +You specify which color components are to be changed by setting DoRed, DoGreen, and/or @@ -2581,7 +2581,7 @@ structures. If the colormap is an installed map for its screen, the changes are visible immediately. -changes the specified pixels if they are allocated writable in the colormap +changes the specified pixels if they are allocated writable in the colormap by any client, even if one or more pixels generates an error. If a specified pixel is not a valid index into the colormap, a BadValue @@ -2589,7 +2589,7 @@ error results. If a specified pixel either is unallocated or is allocated read-only, a BadAccess error results. -If more than one pixel is in error, +If more than one pixel is in error, the one that gets reported is arbitrary. @@ -2666,7 +2666,7 @@ function converts the color specified in the structure into RGB values. It then uses this RGB specification in an XColor -structure, whose three flags +structure, whose three flags (DoRed, DoGreen, and @@ -2684,16 +2684,16 @@ error results. If the color cell is unallocated or is allocated read-only, a BadAccess error results. -If the colormap is an installed map for its screen, +If the colormap is an installed map for its screen, the changes are visible immediately. -Note that +Note that has no return value; therefore, an XcmsSuccess -return value from this function indicates that the conversion +return value from this function indicates that the conversion to RGB succeeded and the call to was made. @@ -2774,7 +2774,7 @@ Values specified in the array remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -2808,7 +2808,7 @@ function converts the colors specified in the array of XcmsColor structures into RGB values and then uses these RGB specifications in XColor -structures, whose three flags +structures, whose three flags (DoRed, DoGreen, and @@ -2828,16 +2828,16 @@ If a color cell is unallocated or is allocated read-only, a error results. If more than one pixel is in error, the one that gets reported is arbitrary. -If the colormap is an installed map for its screen, +If the colormap is an installed map for its screen, the changes are visible immediately. -Note that +Note that has no return value; therefore, an XcmsSuccess -return value from this function indicates that conversions +return value from this function indicates that conversions to RGB succeeded and the call to was made. @@ -2905,7 +2905,7 @@ Specifies the colormap. -Specifies the color name string (for example, red). +Specifies the color name string (for example, red). @@ -2915,7 +2915,7 @@ Specifies the color name string (for example, red). -Specifies the entry in the colormap. +Specifies the entry in the colormap. @@ -2939,15 +2939,15 @@ The function looks up the named color with respect to the screen associated with the colormap and stores the result in the specified colormap. The pixel argument determines the entry in the colormap. -The flags argument determines which of the red, green, and blue components -are set. +The flags argument determines which of the red, green, and blue components +are set. You can set this member to the -bitwise inclusive OR of the bits +bitwise inclusive OR of the bits DoRed, DoGreen, -and +and DoBlue. -If the color name is not in the Host Portable Character Encoding, +If the color name is not in the Host Portable Character Encoding, the result is implementation-dependent. Use of uppercase or lowercase does not matter. If the specified pixel is not a valid index into the colormap, a @@ -2964,7 +2964,7 @@ can generate BadAccess, BadColor, BadName, -and +and BadValue errors. @@ -3120,7 +3120,7 @@ specified in the structure. -Specifies the number of +Specifies the number of XColor structures in the color definition array. @@ -3301,7 +3301,7 @@ The color specifications for the color cells are returned in these structures. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -3446,11 +3446,11 @@ Specifies the colormap. The function returns the CCC associated with the specified colormap. -Once obtained, +Once obtained, the CCC attributes can be queried or modified. Unless the CCC associated with the specified colormap is changed with , -this CCC is used when the specified colormap is used as an argument +this CCC is used when the specified colormap is used as an argument to color functions. @@ -3837,7 +3837,7 @@ Specifies the new Client White Point. The function changes the Client White Point in the specified CCC. -Note that the pixel member is ignored +Note that the pixel member is ignored and that the color specification is left unchanged upon return. The format for the new white point must be XcmsCIEXYZFormat, @@ -3896,11 +3896,11 @@ Specifies the CCC. -Specifies the gamut compression procedure that is to be applied +Specifies the gamut compression procedure that is to be applied when a color lies outside the screen's color gamut. If NULL is specified and a function using this CCC must convert a color specification to a device-dependent format and encounters a color -that lies outside the screen's color gamut, +that lies outside the screen's color gamut, that function will return XcmsFailure. @@ -3923,7 +3923,7 @@ Specifies client data for gamut compression procedure or NULL. The -function first sets the gamut compression procedure and client data +function first sets the gamut compression procedure and client data in the specified CCC with the newly specified procedure and client data and then returns the old procedure. @@ -3985,7 +3985,7 @@ Specifies client data for white point adjustment procedure or NULL. The -function first sets the white point adjustment procedure and client data +function first sets the white point adjustment procedure and client data in the specified CCC with the newly specified procedure and client data and then returns the old procedure. @@ -4066,7 +4066,7 @@ Specifies the visual type. Specifies the Client White Point. -If NULL is specified, +If NULL is specified, the Client White Point is to be assumed to be the same as the Screen White Point. Note that the pixel member is ignored. @@ -4079,11 +4079,11 @@ Note that the pixel member is ignored. -Specifies the gamut compression procedure that is to be applied +Specifies the gamut compression procedure that is to be applied when a color lies outside the screen's color gamut. If NULL is specified and a function using this CCC must convert a color specification to a device-dependent format and encounters a color -that lies outside the screen's color gamut, +that lies outside the screen's color gamut, that function will return XcmsFailure. @@ -4230,7 +4230,7 @@ Pixel members are ignored and remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -4371,7 +4371,7 @@ Pixel members should be ignored and must remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -4385,7 +4385,7 @@ structures in the color-specification array. Specifies the index into the array of XcmsColor -structures for the encountered color specification that lies outside the +structures for the encountered color specification that lies outside the screen's color gamut. Valid values are 0 (for the first element) to ncolors - 1. @@ -4435,7 +4435,7 @@ they must be in their initial device-dependent format upon return. When called, the element in the color specification array specified -by the index argument contains the color specification outside the +by the index argument contains the color specification outside the screen's color gamut encountered by the calling routine. In addition, this color specification can be assumed to be in XcmsCIEXYZ. @@ -4445,12 +4445,12 @@ Upon return, this color specification must be in -When called, elements from index to ncolors - 1 +When called, elements from index to ncolors - 1 in the color specification array may or may not fall within the screen's color gamut. In addition, these color specifications can be assumed to be in XcmsCIEXYZ. -If any modifications are made to these color specifications, +If any modifications are made to these color specifications, they must be in XcmsCIEXYZ upon return. @@ -4467,7 +4467,7 @@ is the Screen White Point. If the gamut compression procedure uses a device-independent color space not -initially accessible for use in the color management system, use +initially accessible for use in the color management system, use to ensure that it is added. @@ -4511,10 +4511,10 @@ The gamut compression callback procedures provided by Xlib are as follows: -This brings the encountered out-of-gamut color specification into the -screen's color gamut by reducing or increasing CIE metric lightness (L*) +This brings the encountered out-of-gamut color specification into the +screen's color gamut by reducing or increasing CIE metric lightness (L*) in the CIE L*a*b* color space until the color is within the gamut. -If the Psychometric Chroma of the color specification +If the Psychometric Chroma of the color specification is beyond maximum for the Psychometric Hue Angle, then while maintaining the same Psychometric Hue Angle, the color will be clipped to the CIE L*a*b* coordinates of maximum @@ -4531,7 +4531,7 @@ No client data is necessary. -This brings the encountered out-of-gamut color specification into the +This brings the encountered out-of-gamut color specification into the screen's color gamut by reducing Psychometric Chroma, while maintaining Psychometric Hue Angle, until the color is within the gamut. @@ -4560,7 +4560,7 @@ No client data is necessary. -This brings the encountered out-of-gamut color specification into the +This brings the encountered out-of-gamut color specification into the screen's color gamut by reducing or increasing CIE metric lightness (L*) in the CIE L*u*v* color space until the color is within the gamut. If the Psychometric Chroma of the color specification @@ -4730,7 +4730,7 @@ Pixel members should be ignored and must remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -4778,7 +4778,7 @@ White point adjustment procedures provided by Xlib are as follows: This uses the CIE L*a*b* color space for adjusting the chromatic character of colors to compensate for the chromatic differences between the source and destination white points. -This procedure simply converts the color specifications to +This procedure simply converts the color specifications to XcmsCIELab using the source white point and then converts to the target specification format using the destination's white point. @@ -4795,7 +4795,7 @@ No client data is necessary. This uses the CIE L*u*v* color space for adjusting the chromatic character of colors to compensate for the chromatic differences between the source and destination white points. -This procedure simply converts the color specifications to +This procedure simply converts the color specifications to XcmsCIELuv using the source white point and then converts to the target specification format using the destination's white point. @@ -4826,13 +4826,13 @@ No client data is necessary. From an implementation point of view, these white point adjustment procedures convert the color specifications -to a device-independent but white-point-dependent color space +to a device-independent but white-point-dependent color space (for example, CIE L*u*v*, CIE L*a*b*, TekHVC) using one white point -and then converting those specifications to the target color space +and then converting those specifications to the target color space using another white point. In other words, -the specification goes in the color space with one white point -but comes out with another white point, +the specification goes in the color space with one white point +but comes out with another white point, resulting in a chromatic shift based on the chromatic displacement between the initial white point and target white point. The CIE color spaces that are assumed to be white-point-independent @@ -4845,12 +4845,12 @@ to ensure that it is added. -As an example, +As an example, if the CCC specifies a white point adjustment procedure and if the Client White Point and Screen White Point differ, the function will use the white point adjustment -procedure twice: +procedure twice: @@ -4874,7 +4874,7 @@ and the adjustment procedure is XcmsCIELuvWhiteShiftColors. During conversion to XcmsRGB, -the call to +the call to results in the following series of color specification conversions: @@ -4882,7 +4882,7 @@ results in the following series of color specification conversions: -From +From XcmsCIEuvY to XcmsCIELuv @@ -4891,7 +4891,7 @@ using the Client White Point -From +From XcmsCIELuv to XcmsCIEuvY @@ -4909,15 +4909,15 @@ to -From +From XcmsCIEXYZ -to +to XcmsRGBi -From +From XcmsRGBi to XcmsRGB @@ -4931,7 +4931,7 @@ The resulting RGB specification is passed to and the RGB specification returned by -is converted back to +is converted back to XcmsCIEuvY by reversing the color conversion sequence. @@ -4945,11 +4945,11 @@ by reversing the color conversion sequence. This section describes the gamut querying functions that Xlib provides. -These functions allow the client to query the boundary -of the screen's color gamut in terms of the CIE L*a*b*, CIE L*u*v*, +These functions allow the client to query the boundary +of the screen's color gamut in terms of the CIE L*a*b*, CIE L*u*v*, and TekHVC color spaces. Gamut querying -Functions are also provided that allow you to query +Functions are also provided that allow you to query the color specification of: @@ -4981,7 +4981,7 @@ Black (zero-intensity red, green, and blue) -The white point associated with color specifications passed to +The white point associated with color specifications passed to and returned from these gamut querying functions is assumed to be the Screen White Point. Screen White Point @@ -5002,10 +5002,10 @@ Xcms<color_space>QueryMin is given a fixed Hue and Value for which maximum Chroma is found. @@ -5016,7 +5016,7 @@ is given a fixed Hue and Value for which maximum Chroma is found. -To obtain the color specification for black +To obtain the color specification for black (zero-intensity red, green, and blue), use . @@ -5081,7 +5081,7 @@ for zero-intensity red, green, and blue. -To obtain the color specification for blue +To obtain the color specification for blue (full-intensity blue while red and green are zero), use . @@ -5514,10 +5514,10 @@ The value returned in the pixel member is undefined. The function, given a hue angle and chroma, -finds the point in CIE L*a*b* color space of maximum +finds the point in CIE L*a*b* color space of maximum lightness (L*) displayable by the screen. It returns this point in CIE L*a*b* coordinates. -An +An XcmsFailure return value usually indicates that the given chroma is beyond maximum for the given hue angle. @@ -5672,7 +5672,7 @@ The function, given a hue angle and chroma, finds the point of minimum lightness (L*) displayable by the screen. It returns this point in CIE L*a*b* coordinates. -An +An XcmsFailure return value usually indicates that the given chroma is beyond maximum for the given hue angle. @@ -5856,10 +5856,10 @@ The value returned in the pixel member is undefined. The function, given a hue angle and chroma, -finds the point in CIE L*u*v* color space of maximum +finds the point in CIE L*u*v* color space of maximum lightness (L*) displayable by the screen. It returns this point in CIE L*u*v* coordinates. -An +An XcmsFailure return value usually indicates that the given chroma is beyond maximum for the given hue angle. @@ -6014,7 +6014,7 @@ The function, given a hue angle and chroma, finds the point of minimum lightness (L*) displayable by the screen. It returns this point in CIE L*u*v* coordinates. -An +An XcmsFailure return value usually indicates that the given chroma is beyond maximum for the given hue angle. @@ -6476,13 +6476,13 @@ function. The CIE XYZ color space serves as the hub for all conversions between device-independent and device-dependent color spaces. -Therefore, the knowledge to convert an +Therefore, the knowledge to convert an XcmsColor structure to and from CIE XYZ format is associated with each color space. For example, conversion from CIE L*u*v* to RGB requires the knowledge to convert from CIE L*u*v* to CIE XYZ and from CIE XYZ to RGB. This knowledge is stored as an array of functions that, -when applied in series, will convert the +when applied in series, will convert the XcmsColor structure to or from CIE XYZ format. This color specification conversion mechanism facilitates @@ -6493,8 +6493,8 @@ the addition of color spaces. Of course, when converting between only device-independent color spaces or only device-dependent color spaces, shortcuts are taken whenever possible. -For example, conversion from TekHVC to CIE L*u*v* is performed -by intermediate conversion to CIE u*v*Y and then to CIE L*u*v*, +For example, conversion from TekHVC to CIE L*u*v* is performed +by intermediate conversion to CIE u*v*Y and then to CIE L*u*v*, thus bypassing conversion between CIE u*v*Y and CIE XYZ. @@ -6541,8 +6541,8 @@ structure) accessible by the color management system. Because format values for unregistered color spaces are assigned at run time, they should be treated as private to the client. If references to an unregistered color space must be made -outside the client (for example, storing color specifications -in a file using the unregistered color space), +outside the client (for example, storing color specifications +in a file using the unregistered color space), then reference should be made by color space prefix (see @@ -6551,16 +6551,16 @@ and -If the +If the XcmsColorSpace -structure is already accessible in the color management system, +structure is already accessible in the color management system, -returns +returns XcmsSuccess. -Note that added +Note that added XcmsColorSpaces must be retained for reference by Xlib. @@ -6608,7 +6608,7 @@ function returns the format for the specified color space prefix The prefix is case-insensitive. If the color space is not accessible in the color management system, -returns +returns XcmsUndefinedFormat. @@ -6658,7 +6658,7 @@ The returned string must be treated as read-only. -Color space specific information necessary +Color space specific information necessary for color space conversion and color string parsing is stored in an XcmsColorSpace structure. @@ -6672,7 +6672,7 @@ function. -If a new +If a new XcmsColorSpace structure specifies a color space not registered with the X Consortium, they should be treated as private to the client @@ -6708,15 +6708,15 @@ typedef struct _XcmsColorSpace { -The prefix member specifies the prefix that indicates a color string +The prefix member specifies the prefix that indicates a color string is in this color space's string format. For example, the strings ``ciexyz'' or ``CIEXYZ'' for CIE XYZ, and ``rgb'' or ``RGB'' for RGB. The prefix is case insensitive. The format member specifies the color specification format. Formats for unregistered color spaces are assigned at run time. -The parseString member contains a pointer to the function -that can parse a color string into an +The parseString member contains a pointer to the function +that can parse a color string into an XcmsColor structure. This function returns an integer (int): nonzero if it succeeded @@ -6724,14 +6724,14 @@ and zero otherwise. The to_CIEXYZ and from_CIEXYZ members contain pointers, each to a NULL terminated list of function pointers. When the list of functions is executed in series, -it will convert the color specified in an +it will convert the color specified in an XcmsColor structure from/to the current color space format to/from the CIE XYZ format. Each function returns an integer (int): nonzero if it succeeded and zero otherwise. The white point to be associated with the colors is specified explicitly, even though white points can be found in the CCC. -The inverse_flag member, if nonzero, specifies that for each function listed +The inverse_flag member, if nonzero, specifies that for each function listed in to_CIEXYZ, its inverse function can be found in from_CIEXYZ such that: @@ -6864,7 +6864,7 @@ Pixel members should be ignored and must remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -6921,7 +6921,7 @@ Pixel members should be ignored and must remain unchanged upon return. -Specifies the number of +Specifies the number of XcmsColor structures in the color-specification array. @@ -7055,7 +7055,7 @@ and CIE XYZ may differ for different classes of output device Therefore, the notion of a Color Characterization Function Set has been developed. A function set consists of device-dependent color spaces -and the functions that convert color specifications +and the functions that convert color specifications between these device-dependent color spaces and the CIE XYZ color space appropriate for a particular class of output devices. The function set also contains a function that reads @@ -7072,7 +7072,7 @@ The LINEAR_RGB function set is provided by Xlib and will support most color monitors. Function sets may require data that differs from those needed for the LINEAR_RGB function set. -In that case, +In that case, its corresponding data may be stored on different root window properties. @@ -7114,7 +7114,7 @@ Specifies the function set to add. The function adds a function set to the color management system. -If the function set uses device-dependent +If the function set uses device-dependent XcmsColorSpace structures not accessible in the color management system, @@ -7129,7 +7129,7 @@ If references to an unregistered color space must be made outside the client (for example, storing color specifications in a file using the unregistered color space), then reference should be made by color space prefix -(see +(see and ). @@ -7138,9 +7138,9 @@ and Additional function sets should be added before any calls to other Xlib routines are made. -If not, the +If not, the XcmsPerScrnInfo -member of a previously created +member of a previously created XcmsCCC does not have the opportunity to initialize with the added function set. @@ -7154,11 +7154,11 @@ with the added function set. The creation of additional function sets should be -required only when an output device does not conform to existing +required only when an output device does not conform to existing function sets or when additional device-dependent color spaces are necessary. A function set consists primarily of a collection of device-dependent XcmsColorSpace -structures and a means to read and store a +structures and a means to read and store a screen's color characterization data. This data is stored in an XcmsFunctionSet @@ -7169,18 +7169,18 @@ is usually made accessible to the client program for use with -If a function set uses new device-dependent +If a function set uses new device-dependent XcmsColorSpace structures, they will be transparently processed into the color management system. -Function sets can share an +Function sets can share an XcmsColorSpace structure for a device-dependent color space. -In addition, multiple +In addition, multiple XcmsColorSpace structures are allowed for a device-dependent color space; however, a function set can reference only one of them. -These +These XcmsColorSpace structures will differ in the functions to convert to and from CIE XYZ, thus tailored for the specific function set. @@ -7202,12 +7202,12 @@ typedef struct _XcmsFunctionSet { The DDColorSpaces member is a pointer to a NULL terminated list -of pointers to +of pointers to XcmsColorSpace structures for the device-dependent color spaces that are supported by the function set. The screenInitProc member is set to the callback procedure (see the following -interface specification) that initializes the +interface specification) that initializes the XcmsPerScrnInfo structure for a particular screen. @@ -7255,7 +7255,7 @@ Specifies the appropriate screen number on the host server. -Specifies the +Specifies the XcmsPerScrnInfo structure, which contains the per screen information. @@ -7270,22 +7270,22 @@ The screen initialization callback in the XcmsFunctionSet structure fetches the color characterization data (device profile) for the specified screen, -typically off properties on the +typically off properties on the screen's root window. It then initializes the specified XcmsPerScrnInfo structure. Device profile Color Characterization Data -If successful, the procedure fills in the +If successful, the procedure fills in the XcmsPerScrnInfo structure as follows: -It sets the screenData member to the address -of the created device profile data structure +It sets the screenData member to the address +of the created device profile data structure (contents known only by the function set). @@ -7303,7 +7303,7 @@ structure. -It then sets the state member to +It then sets the state member to XcmsInitSuccess and finally returns XcmsSuccess. @@ -7312,7 +7312,7 @@ and finally returns -If unsuccessful, the procedure sets the state member to +If unsuccessful, the procedure sets the state member to XcmsInitFailure and returns XcmsFailure. diff --git a/specs/libX11/CH07.xml b/specs/libX11/CH07.xml index 38408e44..14bba251 100644 --- a/specs/libX11/CH07.xml +++ b/specs/libX11/CH07.xml @@ -43,7 +43,7 @@ The contents of a GC are private to Xlib. Xlib implements a write-back cache for all elements of a GC that are not -resource IDs to allow Xlib to implement the transparent coalescing of changes +resource IDs to allow Xlib to implement the transparent coalescing of changes to GCs. For example, a call to @@ -51,11 +51,11 @@ a call to of a GC followed by a call to results in only a single-change GC protocol request to the server. -GCs are neither expected nor encouraged to be shared between client +GCs are neither expected nor encouraged to be shared between client applications, so this write-back caching should present no problems. Applications cannot share GCs without external synchronization. Therefore, -sharing GCs between applications is highly discouraged. +sharing GCs between applications is highly discouraged. @@ -260,14 +260,14 @@ to be useful in a window. Source Destination The function attributes of a GC are used when you update a section of -a drawable (the destination) with bits from somewhere else (the source). +a drawable (the destination) with bits from somewhere else (the source). The function in a GC defines how the new destination bits are to be computed from the source bits and the old destination bits. GXcopy is typically the most useful because it will work on a color display, but special applications may use other functions, particularly in concert with particular planes of a color display. -The 16 GC functions, defined in +The 16 GC functions, defined in <X11/X.h>, X11/X.h Files<X11/X.h> @@ -391,9 +391,9 @@ significant bits in the plane mask. -In graphics operations, given a source and destination pixel, +In graphics operations, given a source and destination pixel, the result is computed bitwise on corresponding bits of the pixels. -That is, a Boolean operation is performed in each bit plane. +That is, a Boolean operation is performed in each bit plane. The plane_mask restricts the operation to a subset of planes. A macro constant AllPlanes @@ -442,7 +442,7 @@ If the center of the pixel is exactly on the bounding box, it is part of the line if and only if the interior is immediately to its right (x increasing direction). Pixels with centers on a horizontal edge are a special case and are part of -the line if and only if the interior or the boundary is immediately below +the line if and only if the interior or the boundary is immediately below (y increasing direction) and the interior or the boundary is immediately to the right (x increasing direction). @@ -450,21 +450,21 @@ to the right (x increasing direction). Thin lines (zero line-width) are one-pixel-wide lines drawn using an unspecified, device-dependent algorithm. -There are only two constraints on this algorithm. +There are only two constraints on this algorithm. If a line is drawn unclipped from [x1,y1] to [x2,y2] and if another line is drawn unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy], -a point [x,y] is touched by drawing the first line +a point [x,y] is touched by drawing the first line if and only if the point [x+dx,y+dy] is touched by drawing the second line. The effective set of points comprising a line cannot be affected by clipping. -That is, a point is touched in a clipped line if and only if the point +That is, a point is touched in a clipped line if and only if the point lies inside the clipping region and the point would be touched by the line when drawn unclipped. @@ -472,10 +472,10 @@ by the line when drawn unclipped. -A wide line drawn from [x1,y1] to [x2,y2] always draws the same pixels -as a wide line drawn from [x2,y2] to [x1,y1], not counting cap-style +A wide line drawn from [x1,y1] to [x2,y2] always draws the same pixels +as a wide line drawn from [x2,y2] to [x1,y1], not counting cap-style and join-style. -It is recommended that this property be true for thin lines, +It is recommended that this property be true for thin lines, but this is not required. A line-width of zero may differ from a line-width of one in which pixels are drawn. @@ -485,7 +485,7 @@ wide lines. -In general, +In general, drawing a thin line will be faster than drawing a wide line of width one. However, because of their different drawing algorithms, thin lines may not mix well aesthetically with wide lines. @@ -521,7 +521,7 @@ style used where even and odd dashes meet. Only the even dashes are drawn, -and cap-style applies to +and cap-style applies to all internal ends of the individual dashes, except CapNotLast @@ -562,7 +562,7 @@ with no projection beyond. The line has a circular arc with the diameter equal to the line-width, centered on the endpoint. -(This is equivalent to +(This is equivalent to CapButt for line-width of zero). @@ -623,8 +623,8 @@ endpoint styles with the triangular notch filled. -For a line with coincident endpoints (x1=x2, y1=y2), -when the cap-style is applied to both endpoints, +For a line with coincident endpoints (x1=x2, y1=y2), +when the cap-style is applied to both endpoints, the semantics depends on the line-width and the cap-style: @@ -682,8 +682,8 @@ the semantics depends on the line-width and the cap-style: -For a line with coincident endpoints (x1=x2, y1=y2), -when the join-style is applied at one or both endpoints, +For a line with coincident endpoints (x1=x2, y1=y2), +when the join-style is applied at one or both endpoints, the effect is as if the line was removed from the overall path. However, if the total path consists of or is reduced to a single point joined with itself, the effect is the same as when the cap-style is applied at both @@ -705,12 +705,12 @@ or a BadMatch error results. The stipple pixmap must have depth one and must have the same root as the -GC, or a +GC, or a BadMatch -error results. +error results. For stipple operations where the fill-style is FillStippled -but not +but not FillOpaqueStippled, the stipple pattern is tiled in a single plane and acts as an additional clip mask to be ANDed with the clip-mask. @@ -721,7 +721,7 @@ any size pixmap can be used for tiling or stippling. The fill-style defines the contents of the source for line, text, and -fill requests. +fill requests. For all text and fill requests (for example, , , @@ -729,17 +729,17 @@ For all text and fill requests (for example, , and ); -for line requests -with line-style +for line requests +with line-style LineSolid (for example, , , , ); -and for the even dashes for line requests with line-style +and for the even dashes for line requests with line-style LineOnOffDash -or +or LineDoubleDash, the following apply: @@ -818,7 +818,7 @@ the results are undefined. For optimum performance, -you should draw as much as possible with the same GC +you should draw as much as possible with the same GC (without changing its components). The costs of changing GC components relative to using different GCs depend on the display hardware and the server implementation. @@ -829,10 +829,10 @@ of GCs. The dashes value is actually a simplified form of the -more general patterns that can be set with +more general patterns that can be set with . Specifying a -value of N is equivalent to specifying the two-element list [N, N] in +value of N is equivalent to specifying the two-element list [N, N] in . The value must be nonzero, or a @@ -841,7 +841,7 @@ error results. -The clip-mask restricts writes to the destination drawable. +The clip-mask restricts writes to the destination drawable. If the clip-mask is set to a pixmap, it must have depth one and have the same root as the GC, or a @@ -855,8 +855,8 @@ The clip-mask also can be set by calling the or functions. -Only pixels where the clip-mask has a bit set to 1 are drawn. -Pixels are not drawn outside the area covered by the clip-mask +Only pixels where the clip-mask has a bit set to 1 are drawn. +Pixels are not drawn outside the area covered by the clip-mask or where the clip-mask has a bit set to 0. The clip-mask affects all graphics requests. The clip-mask does not clip sources. @@ -869,18 +869,18 @@ You can set the subwindow-mode to ClipByChildren or IncludeInferiors. -For +For ClipByChildren, both source and destination windows are -additionally clipped by all viewable +additionally clipped by all viewable InputOutput -children. -For +children. +For IncludeInferiors, -neither source nor destination window is clipped by inferiors. +neither source nor destination window is clipped by inferiors. This will result in including subwindow contents in the source and drawing through subwindow boundaries of the destination. -The use of +The use of IncludeInferiors on a window of one depth with mapped inferiors of differing depth is not illegal, but the semantics are @@ -889,9 +889,9 @@ undefined by the core protocol. The fill-rule defines what pixels are inside (drawn) for -paths given in +paths given in -requests and can be set to +requests and can be set to EvenOddRule or WindingRule. @@ -899,8 +899,8 @@ For EvenOddRule, a point is inside if an infinite ray with the point as origin crosses the path an odd number -of times. -For +of times. +For WindingRule, a point is inside if an infinite ray with the point as origin crosses an unequal number of clockwise and @@ -915,24 +915,24 @@ coincident with a segment. -For both +For both EvenOddRule and WindingRule, -a point is infinitely small, -and the path is an infinitely thin line. +a point is infinitely small, +and the path is an infinitely thin line. A pixel is inside if the center point of the pixel is inside -and the center point is not on the boundary. +and the center point is not on the boundary. If the center point is on the boundary, the pixel is inside if and only if the polygon interior is immediately to -its right (x increasing direction). -Pixels with centers on a horizontal edge are a special case -and are inside if and only if the polygon interior is immediately below +its right (x increasing direction). +Pixels with centers on a horizontal edge are a special case +and are inside if and only if the polygon interior is immediately below (y increasing direction). -The arc-mode controls filling in the +The arc-mode controls filling in the function and can be set to ArcPieSlice @@ -947,19 +947,19 @@ the arcs are chord filled. -The graphics-exposure flag controls +The graphics-exposure flag controls GraphicsExpose event generation -for +for -and +and requests (and any similar requests defined by extensions). -To create a new GC that is usable on a given screen with a +To create a new GC that is usable on a given screen with a depth of drawable, use . @@ -993,7 +993,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1204,13 +1204,13 @@ The function changes the components specified by valuemask for the specified GC. The values argument contains the values to be set. -The values and restrictions are the same as for +The values and restrictions are the same as for . -Changing the clip-mask overrides any previous +Changing the clip-mask overrides any previous -request on the context. +request on the context. Changing the dash-offset or dash-list -overrides any previous +overrides any previous request on the context. The order in which components are verified and altered is server dependent. @@ -1329,7 +1329,7 @@ sets the requested components in values_return and returns a nonzero status. Otherwise, it returns a zero status. Note that the clip-mask and dash-list (represented by the GCClipMask -and +and GCDashList bits, respectively, in the valuemask) cannot be requested. @@ -1396,9 +1396,9 @@ error. -To obtain the +To obtain the GContext -resource ID for a given GC, use +resource ID for a given GC, use . XGContextFromGC @@ -2017,7 +2017,7 @@ Specifies the GC. Specifies the phase of the pattern for the dashed line-style you want to set -for the specified GC. +for the specified GC. @@ -2028,7 +2028,7 @@ for the specified GC. Specifies the dash-list for the dashed line-style -you want to set for the specified GC. +you want to set for the specified GC. @@ -2038,7 +2038,7 @@ you want to set for the specified GC. -Specifies the number of elements in dash_list. +Specifies the number of elements in dash_list. @@ -2053,8 +2053,8 @@ in the specified GC. There must be at least one element in the specified dash_list, or a BadValue -error results. -The initial and alternating elements (second, fourth, and so on) +error results. +The initial and alternating elements (second, fourth, and so on) of the dash_list are the even dashes, and the others are the odd dashes. Each element specifies a dash length in pixels. @@ -2210,7 +2210,7 @@ Specifies the GC. Specifies the fill-rule you want to set for the specified GC. -You can pass +You can pass EvenOddRule or WindingRule. @@ -2241,7 +2241,7 @@ Some displays have hardware support for tiling or stippling with patterns of specific sizes. Tiling and stippling operations that restrict themselves to those specific sizes run much faster than such operations with arbitrary size patterns. -Xlib provides functions that you can use to determine the best size, +Xlib provides functions that you can use to determine the best size, tile, or stipple for the display as well as to set the tile or stipple shape and the tile or stipple origin. @@ -2284,10 +2284,10 @@ Specifies the connection to the X server. Specifies the class that you are interested in. -You can pass +You can pass TileShape, CursorShape, -or +or StippleShape. @@ -2340,7 +2340,7 @@ Specify the width and height. -Return the width and height of the object best supported +Return the width and height of the object best supported by the display hardware. @@ -2352,29 +2352,29 @@ by the display hardware. The function returns the best or closest size to the specified size. -For +For CursorShape, this is the largest size that can be fully displayed on the screen specified by which_screen. -For +For TileShape, this is the size that can be tiled fastest. -For +For StippleShape, this is the size that can be stippled fastest. -For +For CursorShape, the drawable indicates the desired screen. -For +For TileShape -and +and StippleShape, the drawable indicates the screen and possibly the window class and depth. -An +An InputOnly -window cannot be used as the drawable for +window cannot be used as the drawable for TileShape -or +or StippleShape, or a BadMatch @@ -2386,7 +2386,7 @@ error results. can generate BadDrawable, BadMatch, -and +and BadValue errors. @@ -2469,7 +2469,7 @@ Specify the width and height. -Return the width and height of the object best supported +Return the width and height of the object best supported by the display hardware. @@ -2483,9 +2483,9 @@ The function returns the best or closest size, that is, the size that can be tiled fastest on the screen specified by which_screen. The drawable indicates the screen and possibly the window class and depth. -If an +If an InputOnly -window is used as the drawable, a +window is used as the drawable, a BadMatch error results. @@ -2577,7 +2577,7 @@ Specify the width and height. -Return the width and height of the object best supported +Return the width and height of the object best supported by the display hardware. @@ -2650,7 +2650,7 @@ Specifies the GC. -Specifies the fill tile you want to set for the specified GC. +Specifies the fill tile you want to set for the specified GC. @@ -2807,7 +2807,7 @@ Specify the x and y coordinates of the tile and stipple origin. When graphics requests call for tiling or stippling, -the parent's origin will be interpreted relative to whatever destination +the parent's origin will be interpreted relative to whatever destination drawable is specified in the graphics request. @@ -2880,7 +2880,7 @@ Specifies the font. can generate BadAlloc, BadFont, -and +and BadGC errors. @@ -2892,7 +2892,7 @@ errors. -Xlib provides functions that you can use to set the clip-origin +Xlib provides functions that you can use to set the clip-origin and the clip-mask or set the clip-mask to a list of rectangles. @@ -2959,7 +2959,7 @@ Specify the x and y coordinates of the clip-mask origin. -The clip-mask origin is interpreted relative to the origin of whatever +The clip-mask origin is interpreted relative to the origin of whatever destination drawable is specified in the graphics request. @@ -3118,7 +3118,7 @@ Specifies an array of rectangles that define the clip-mask. -Specifies the number of rectangles. +Specifies the number of rectangles. @@ -3144,16 +3144,16 @@ or The -function changes the clip-mask in the specified GC +function changes the clip-mask in the specified GC to the specified list of rectangles and sets the clip origin. The output is clipped to remain contained within the rectangles. The clip-origin is interpreted relative to the origin of -whatever destination drawable is specified in a graphics request. -The rectangle coordinates are interpreted relative to the clip-origin. +whatever destination drawable is specified in a graphics request. +The rectangle coordinates are interpreted relative to the clip-origin. The rectangles should be nonintersecting, or the graphics results will be undefined. -Note that the list of rectangles can be empty, +Note that the list of rectangles can be empty, which effectively disables output. This is the opposite of passing None @@ -3166,9 +3166,9 @@ and If known by the client, ordering relations on the rectangles can be -specified with the ordering argument. +specified with the ordering argument. This may provide faster operation -by the server. +by the server. If an incorrect ordering is specified, the X server may generate a BadMatch error, but it is not required to do so. @@ -3179,13 +3179,13 @@ means the rectangles are in arbitrary order. YSorted means that the rectangles are nondecreasing in their Y origin. YXSorted -additionally constrains +additionally constrains YSorted order in that all rectangles with an equal Y origin are nondecreasing in their X -origin. +origin. YXBanded -additionally constrains +additionally constrains YXSorted by requiring that, for every possible Y scanline, all rectangles that include that diff --git a/specs/libX11/CH08.xml b/specs/libX11/CH08.xml index 18eac11d..8e2f020d 100644 --- a/specs/libX11/CH08.xml +++ b/specs/libX11/CH08.xml @@ -27,10 +27,10 @@ Note that this reduces the total number of requests sent to the server. Xlib provides functions that you can use to clear an area or the entire window. -Because pixmaps do not have defined backgrounds, +Because pixmaps do not have defined backgrounds, they cannot be filled by using the functions described in this section. Instead, to accomplish an analogous operation on a pixmap, -you should use +you should use , which sets the pixmap to a known value. @@ -147,16 +147,16 @@ If width is zero, it is replaced with the current width of the window minus x. If height is zero, it is replaced with the current height of the window minus y. -If the window has a defined background tile, +If the window has a defined background tile, the rectangle clipped by any children is filled with this tile. If the window has -background +background None, -the contents of the window are not changed. +the contents of the window are not changed. In either -case, if exposures is +case, if exposures is True, -one or more +one or more Expose events are generated for regions of the rectangle that are either visible or are being retained in a backing store. @@ -224,21 +224,21 @@ The function clears the entire area in the specified window and is equivalent to -(display, w, 0, 0, 0, 0, +(display, w, 0, 0, 0, 0, False). If the window has a defined background tile, the rectangle is tiled with a -plane-mask of all ones and +plane-mask of all ones and GXcopy function. If the window has -background +background None, -the contents of the window are not changed. +the contents of the window are not changed. If you specify a window whose class is InputOnly, a BadMatch -error results. +error results. @@ -314,7 +314,7 @@ Specifies the connection to the X server. -Specify the source and destination rectangles to be combined. +Specify the source and destination rectangles to be combined. @@ -345,7 +345,7 @@ Specifies the GC. -Specify the x and y coordinates, +Specify the x and y coordinates, which are relative to the origin of the source rectangle and specify its upper-left corner. @@ -401,7 +401,7 @@ destination rectangle and specify its upper-left corner. The -function combines the specified rectangle of src with the specified rectangle +function combines the specified rectangle of src with the specified rectangle of dest. The drawables must have the same root and depth, or a @@ -411,13 +411,13 @@ error results. If regions of the source rectangle are obscured and have not been -retained in backing store -or if regions outside the boundaries of the source drawable are specified, -those regions are not copied. -Instead, the +retained in backing store +or if regions outside the boundaries of the source drawable are specified, +those regions are not copied. +Instead, the following occurs on all corresponding destination regions that are either -visible or are retained in backing store. -If the destination is a window with a background other than +visible or are retained in backing store. +If the destination is a window with a background other than None, corresponding regions of the destination are tiled with that background @@ -425,12 +425,12 @@ of the destination are tiled with that background GXcopy function). Regardless of tiling or whether the destination is a window or a pixmap, -if graphics-exposures is +if graphics-exposures is True, then GraphicsExpose events for all corresponding destination regions are generated. -If graphics-exposures is +If graphics-exposures is True but no GraphicsExpose @@ -443,7 +443,7 @@ in new GCs. -This function uses these GC components: function, plane-mask, +This function uses these GC components: function, plane-mask, subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin, and clip-mask. @@ -512,7 +512,7 @@ Specifies the connection to the X server. -Specify the source and destination rectangles to be combined. +Specify the source and destination rectangles to be combined. @@ -543,7 +543,7 @@ Specifies the GC. -Specify the x and y coordinates, +Specify the x and y coordinates, which are relative to the origin of the source rectangle and specify its upper-left corner. @@ -623,17 +623,17 @@ error results. -Effectively, +Effectively, forms a pixmap of the same depth as the rectangle of dest and with a -size specified by the source region. +size specified by the source region. It uses the foreground/background pixels in the GC (foreground everywhere the bit plane in src contains a bit set to 1, background everywhere the bit plane in src contains a bit set to 0) -and the equivalent of a +and the equivalent of a CopyArea protocol request is performed with all the same exposure semantics. -This can also be thought of as using the specified region of the source +This can also be thought of as using the specified region of the source bit plane as a stipple with a fill-style of FillOpaqueStippled for filling a rectangular area of the destination. @@ -651,7 +651,7 @@ can generate BadDrawable, BadGC, BadMatch, -and +and BadValue errors. @@ -802,7 +802,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -876,7 +876,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -916,7 +916,7 @@ Specifies the number of points in the array. -Specifies the coordinate mode. +Specifies the coordinate mode. You can pass CoordModeOrigin or @@ -931,7 +931,7 @@ or The function uses the foreground pixel and function components of the -GC to draw a single point into the specified drawable; +GC to draw a single point into the specified drawable; draws multiple points this way. CoordModeOrigin @@ -953,7 +953,7 @@ foreground, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. can generate BadDrawable, BadGC, -and +and BadMatch errors. @@ -1018,7 +1018,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1114,7 +1114,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1154,7 +1154,7 @@ Specifies the number of points in the array. -Specifies the coordinate mode. +Specifies the coordinate mode. You can pass CoordModeOrigin or @@ -1201,7 +1201,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1244,30 +1244,30 @@ The function uses the components of the specified GC to draw a line between the specified set of points (x1, y1) and (x2, y2). It does not perform joining at coincident endpoints. -For any given line, +For any given line, does not draw a pixel more than once. -If lines intersect, the intersecting pixels are drawn multiple times. +If lines intersect, the intersecting pixels are drawn multiple times. The -function uses the components of the specified GC to draw -npoints-1 lines between each pair of points (point[i], point[i+1]) +function uses the components of the specified GC to draw +npoints-1 lines between each pair of points (point[i], point[i+1]) in the array of XPoint structures. It draws the lines in the order listed in the array. The lines join correctly at all intermediate points, and if the first and last points coincide, the first and last lines also join correctly. -For any given line, +For any given line, does not draw a pixel more than once. -If thin (zero line-width) lines intersect, +If thin (zero line-width) lines intersect, the intersecting pixels are drawn multiple times. If wide lines intersect, the intersecting pixels are drawn only once, as though -the entire +the entire PolyLine protocol request were a single, filled shape. CoordModeOrigin @@ -1280,18 +1280,18 @@ treats all coordinates after the first as relative to the previous point. The -function draws multiple, unconnected lines. -For each segment, +function draws multiple, unconnected lines. +For each segment, draws a line between (x1, y1) and (x2, y2). It draws the lines in the order listed in the array of XSegment structures and does not perform joining at coincident endpoints. -For any given line, +For any given line, -does not draw a pixel more than once. -If lines intersect, the intersecting pixels are drawn multiple times. +does not draw a pixel more than once. +If lines intersect, the intersecting pixels are drawn multiple times. @@ -1303,7 +1303,7 @@ The function also uses the join-style GC component. All three functions also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +foreground, background, tile, stipple, tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, and dash-list. @@ -1373,7 +1373,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1470,7 +1470,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1513,7 +1513,7 @@ The and functions draw the outlines of the specified rectangle or rectangles as -if a five-point +if a five-point PolyLine protocol request were specified for each rectangle: @@ -1526,7 +1526,7 @@ protocol request were specified for each rectangle: -For the specified rectangle or rectangles, +For the specified rectangle or rectangles, these functions do not draw a pixel more than once. draws the rectangles in the order listed in the array. @@ -1535,12 +1535,12 @@ the intersecting pixels are drawn multiple times. -Both functions use these GC components: +Both functions use these GC components: function, plane-mask, line-width, -line-style, cap-style, join-style, fill-style, +line-style, cap-style, join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, and dash-list. @@ -1608,7 +1608,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1726,7 +1726,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -1768,35 +1768,35 @@ Specifies the number of arcs in the array. delim %% -draws a single circular or elliptical arc, and +draws a single circular or elliptical arc, and draws multiple circular or elliptical arcs. -Each arc is specified by a rectangle and two angles. +Each arc is specified by a rectangle and two angles. The center of the circle or ellipse is the center of the rectangle, and the major and minor axes are specified by the width and height. -Positive angles indicate counterclockwise motion, -and negative angles indicate clockwise motion. -If the magnitude of angle2 is greater than 360 degrees, +Positive angles indicate counterclockwise motion, +and negative angles indicate clockwise motion. +If the magnitude of angle2 is greater than 360 degrees, -or +or truncates it to 360 degrees. -For an arc specified as %[ ~x, ~y, ~width , ~height, ~angle1, ~angle2 ]%, -the origin of the major and minor axes is at -% [ x +^ {width over 2} , ~y +^ {height over 2} ]%, -and the infinitely thin path describing the entire circle or ellipse -intersects the horizontal axis at % [ x, ~y +^ {height over 2} ]% and +For an arc specified as %[ ~x, ~y, ~width , ~height, ~angle1, ~angle2 ]%, +the origin of the major and minor axes is at +% [ x +^ {width over 2} , ~y +^ {height over 2} ]%, +and the infinitely thin path describing the entire circle or ellipse +intersects the horizontal axis at % [ x, ~y +^ {height over 2} ]% and % [ x +^ width , ~y +^ { height over 2 }] % -and intersects the vertical axis at % [ x +^ { width over 2 } , ~y ]% and +and intersects the vertical axis at % [ x +^ { width over 2 } , ~y ]% and % [ x +^ { width over 2 }, ~y +^ height ]%. These coordinates can be fractional and so are not truncated to discrete coordinates. -The path should be defined by the ideal mathematical path. -For a wide line with line-width lw, -the bounding outlines for filling are given +The path should be defined by the ideal mathematical path. +For a wide line with line-width lw, +the bounding outlines for filling are given by the two infinitely thin paths consisting of all points whose perpendicular distance from the path of the circle/ellipse is equal to lw/2 (which may be a fractional value). @@ -1839,18 +1839,18 @@ and adjust is: -For any given arc, - -and - -do not draw a pixel more than once. -If two arcs join correctly and if the line-width is greater than zero -and the arcs intersect, +For any given arc, and do not draw a pixel more than once. -Otherwise, +If two arcs join correctly and if the line-width is greater than zero +and the arcs intersect, + +and + +do not draw a pixel more than once. +Otherwise, the intersecting pixels of intersecting arcs are drawn multiple times. Specifying an arc with one endpoint and a clockwise extent draws the same pixels as specifying the other endpoint and an equivalent counterclockwise extent, @@ -1858,9 +1858,9 @@ except as it affects joins. -If the last point in one arc coincides with the first point in the following -arc, the two arcs will join correctly. -If the first point in the first arc coincides with the last point in the last +If the last point in one arc coincides with the first point in the following +arc, the two arcs will join correctly. +If the first point in the first arc coincides with the last point in the last arc, the two arcs will join correctly. By specifying one axis to be zero, a horizontal or vertical line can be drawn. @@ -1869,11 +1869,11 @@ aspect ratio. -Both functions use these GC components: -function, plane-mask, line-width, line-style, cap-style, join-style, +Both functions use these GC components: +function, plane-mask, line-width, line-style, cap-style, join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, and dash-list. @@ -1966,7 +1966,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -2062,7 +2062,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -2105,7 +2105,7 @@ The and functions fill the specified rectangle or rectangles -as if a four-point +as if a four-point FillPolygon protocol request were specified for each rectangle: @@ -2123,22 +2123,22 @@ width and height dimensions, and GC you specify. -fills the rectangles in the order listed in the array. +fills the rectangles in the order listed in the array. For any given rectangle, and -do not draw a pixel more than once. +do not draw a pixel more than once. If rectangles intersect, the intersecting pixels are drawn multiple times. -Both functions use these GC components: -function, plane-mask, fill-style, subwindow-mode, +Both functions use these GC components: +function, plane-mask, fill-style, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, and tile-stipple-y-origin. @@ -2199,7 +2199,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -2240,10 +2240,10 @@ Specifies the number of points in the array. Specifies a shape that helps the server to improve performance. -You can pass +You can pass Complex, Convex, -or +or Nonconvex. @@ -2254,7 +2254,7 @@ or -Specifies the coordinate mode. +Specifies the coordinate mode. You can pass CoordModeOrigin or @@ -2281,15 +2281,15 @@ treats all coordinates after the first as relative to the previous point. -Depending on the specified shape, the following occurs: +Depending on the specified shape, the following occurs: If shape is Complex, -the path may self-intersect. -Note that contiguous coincident points in the path are not treated +the path may self-intersect. +Note that contiguous coincident points in the path are not treated as self-intersection. @@ -2300,12 +2300,12 @@ If shape is for every pair of points inside the polygon, the line segment connecting them does not intersect the path. If known by the client, -specifying +specifying Convex -can improve performance. +can improve performance. If you specify Convex -for a path that is not convex, +for a path that is not convex, the graphics results are undefined. @@ -2314,13 +2314,13 @@ the graphics results are undefined. If shape is Nonconvex, the path does not self-intersect, but the shape is not -wholly convex. -If known by the client, -specifying +wholly convex. +If known by the client, +specifying Nonconvex instead of Complex -may improve performance. +may improve performance. If you specify Nonconvex for a self-intersecting path, the graphics results are undefined. @@ -2329,16 +2329,16 @@ for a self-intersecting path, the graphics results are undefined. -The fill-rule of the GC controls the filling behavior of +The fill-rule of the GC controls the filling behavior of self-intersecting polygons. -This function uses these GC components: -function, plane-mask, fill-style, fill-rule, subwindow-mode, clip-x-origin, +This function uses these GC components: +function, plane-mask, fill-style, fill-rule, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -It also uses these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +It also uses these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, and tile-stipple-y-origin. @@ -2400,7 +2400,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -2518,7 +2518,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -2556,37 +2556,37 @@ Specifies the number of arcs in the array. -For each arc, +For each arc, or fills the region closed by the infinitely thin path -described by the specified arc and, depending on the -arc-mode specified in the GC, one or two line segments. -For +described by the specified arc and, depending on the +arc-mode specified in the GC, one or two line segments. +For ArcChord, -the single line segment joining the endpoints of the arc is used. -For +the single line segment joining the endpoints of the arc is used. +For ArcPieSlice, the two line segments joining the endpoints of the arc with the center -point are used. +point are used. -fills the arcs in the order listed in the array. -For any given arc, +fills the arcs in the order listed in the array. +For any given arc, and -do not draw a pixel more than once. -If regions intersect, +do not draw a pixel more than once. +If regions intersect, the intersecting pixels are drawn multiple times. -Both functions use these GC components: -function, plane-mask, fill-style, arc-mode, subwindow-mode, clip-x-origin, +Both functions use these GC components: +function, plane-mask, fill-style, arc-mode, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, and tile-stipple-y-origin. @@ -2611,8 +2611,8 @@ errors. Font -A font is a graphical description of a set of characters that are used to -increase efficiency whenever a set of small, similar sized patterns are +A font is a graphical description of a set of characters that are used to +increase efficiency whenever a set of small, similar sized patterns are repeatedly used. @@ -2652,7 +2652,7 @@ The X server loads fonts whenever a program requests a new font. The server can cache fonts for quick lookup. Fonts are global across all screens in a server. Several levels are possible when dealing with fonts. -Most applications simply use +Most applications simply use to load a font and query the font metrics. @@ -2764,7 +2764,7 @@ specified in the structure defines a range of characters. -The bounding box of a character is defined by the +The bounding box of a character is defined by the XCharStruct of that character. When characters are absent from a font, @@ -2776,25 +2776,25 @@ min and max bounds are used. -The members of the +The members of the XFontStruct have the following semantics: -The direction member can be either +The direction member can be either FontLeftToRight -or +or FontRightToLeft. -It is just a hint as to whether most +It is just a hint as to whether most XCharStruct -elements -have a positive +elements +have a positive (FontLeftToRight) -or a negative +or a negative (FontRightToLeft) -character width +character width metric. The core protocol defines no support for vertical text. @@ -2810,7 +2810,7 @@ index of the last element. If either min_byte1 or max_byte1 are nonzero, both -min_char_or_byte2 and max_char_or_byte2 are less than 256, +min_char_or_byte2 and max_char_or_byte2 are less than 256, and the 2-byte character index values corresponding to the per_char array element N (counting from 0) are: @@ -2840,7 +2840,7 @@ where: -If the per_char pointer is NULL, +If the per_char pointer is NULL, all glyphs between the first and last character indexes inclusive have the same information, as given by both min_bounds and max_bounds. @@ -2848,7 +2848,7 @@ as given by both min_bounds and max_bounds. -If all_chars_exist is +If all_chars_exist is True, all characters in the per_char array have nonzero bounding boxes. @@ -2856,19 +2856,19 @@ all characters in the per_char array have nonzero bounding boxes. The default_char member specifies the character that will be used when an -undefined or nonexistent character is printed. +undefined or nonexistent character is printed. The default_char is a 16-bit character (not a 2-byte character). -For a font using 2-byte matrix format, +For a font using 2-byte matrix format, the default_char has byte1 in the most-significant byte and byte2 in the least significant byte. -If the default_char itself specifies an undefined or nonexistent character, +If the default_char itself specifies an undefined or nonexistent character, no printing is performed for an undefined or nonexistent character. The min_bounds and max_bounds members contain the most extreme values of -each individual +each individual XCharStruct component over all elements of this array (and ignore nonexistent characters). @@ -2914,7 +2914,7 @@ Specific characters may extend beyond this. If the baseline is at Y-coordinate y, -the logical extent of the font is inclusive between the Y-coordinate +the logical extent of the font is inclusive between the Y-coordinate values (y - font.ascent) and (y + font.descent - 1). Typically, the minimum interline spacing between rows of text is given @@ -2925,9 +2925,9 @@ by ascent + descent. For a character origin at [x,y], -the bounding box of a character (that is, +the bounding box of a character (that is, the smallest rectangle that encloses the character's shape) -described in terms of +described in terms of XCharStruct components is a rectangle with its upper-left corner at: @@ -2981,12 +2981,12 @@ The width member defines the logical width of the character. -Note that the baseline (the y position of the character origin) -is logically viewed as being the scanline just below nondescending characters. +Note that the baseline (the y position of the character origin) +is logically viewed as being the scanline just below nondescending characters. When descent is zero, only pixels with Y-coordinates less than y are drawn, and the origin is logically viewed as being coincident with the left edge of -a nonkerned character. +a nonkerned character. When lbearing is zero, no pixels with X-coordinate less than x are drawn. Any of the @@ -2997,7 +2997,7 @@ the next character will be placed to the left of the current origin. -The X protocol does not define the interpretation of the attributes member +The X protocol does not define the interpretation of the attributes member in the XCharStruct structure. @@ -3009,7 +3009,7 @@ set to zero. A font is not guaranteed to have any properties. The interpretation of the property value (for example, long or unsigned long) -must be derived from a priori knowledge of the property. +must be derived from a priori knowledge of the property. A basic set of font properties is specified in the X Consortium standard X Logical Font Description Conventions. @@ -3025,7 +3025,7 @@ unload fonts, and free font information. Fontsgetting information Fontsunloading Fontsfreeing font information -A few font functions use a +A few font functions use a GContext resource ID or a font ID interchangeably. @@ -3079,21 +3079,21 @@ the result is implementation-dependent. Use of uppercase or lowercase does not matter. When the characters ``?'' and ``*'' are used in a font name, a pattern match is performed and any matching font is used. -In the pattern, -the ``?'' character will match any single character, +In the pattern, +the ``?'' character will match any single character, and the ``*'' character will match any number of characters. -A structured format for font names is specified in the X Consortium standard +A structured format for font names is specified in the X Consortium standard X Logical Font Description Conventions. -If +If -was unsuccessful at loading the specified font, -a +was unsuccessful at loading the specified font, +a BadName error results. -Fonts are not associated with a particular screen +Fonts are not associated with a particular screen and can be stored as a component of any GC. -When the font is no longer needed, call +When the font is no longer needed, call . @@ -3138,7 +3138,7 @@ Specifies the connection to the X server. -Specifies the font ID or the +Specifies the font ID or the GContext ID. @@ -3154,9 +3154,9 @@ function returns a pointer to the XFontStruct structure, which contains information associated with the font. You can query a font or the font stored in a GC. -The font ID stored in the +The font ID stored in the XFontStruct -structure will be the +structure will be the GContext ID, and you need to be careful when using this ID in other functions (see @@ -3282,7 +3282,7 @@ Specifies the storage associated with the font. The -function deletes the association between the font resource ID and the specified +function deletes the association between the font resource ID and the specified font and frees the XFontStruct structure. @@ -3351,11 +3351,11 @@ Returns the value of the font property. Given the atom for that property, the -function returns the value of the specified font property. +function returns the value of the specified font property. -also returns +also returns False -if the property was not defined or +if the property was not defined or True if it was defined. A set of predefined atoms exists for font properties, @@ -3471,7 +3471,7 @@ Specifies the connection to the X server. -Specifies the null-terminated pattern string that can contain wildcard +Specifies the null-terminated pattern string that can contain wildcard characters. @@ -3502,7 +3502,7 @@ Returns the actual number of font names. The -function returns an array of available font names +function returns an array of available font names (as controlled by the font search path; see ) that match the string you passed to the pattern argument. @@ -3596,7 +3596,7 @@ Specifies the connection to the X server. -Specifies the null-terminated pattern string that can contain wildcard +Specifies the null-terminated pattern string that can contain wildcard characters. @@ -3743,7 +3743,7 @@ to close the font. Xlib provides functions that you can use to compute the width, -the logical extents, +the logical extents, and the server information about 8-bit and 2-byte text strings. XTextWidth XTextWidth16 @@ -3887,7 +3887,7 @@ To compute the bounding box of an 8-bit character string in a given font, use -Specifies the +Specifies the XFontStruct structure. @@ -3988,7 +3988,7 @@ To compute the bounding box of a 2-byte character string in a given font, use -Specifies the +Specifies the XFontStruct structure. @@ -4067,7 +4067,7 @@ The and -functions +functions perform the size computation locally and, thereby, avoid the round-trip overhead of @@ -4085,7 +4085,7 @@ The descent member is set to the maximum of the descent metrics. The width member is set to the sum of the character-width metrics of all characters in the string. For each character in the string, -let W be the sum of the character-width metrics of all characters preceding +let W be the sum of the character-width metrics of all characters preceding it in the string. Let L be the left-side-bearing metric of the character plus W. Let R be the right-side-bearing metric of the character plus W. @@ -4095,9 +4095,9 @@ The rbearing member is set to the maximum R. For fonts defined with linear indexing rather than 2-byte matrix indexing, -each +each XChar2b -structure is interpreted as a 16-bit number with byte1 as the +structure is interpreted as a 16-bit number with byte1 as the most significant byte. If the font has no defined default character, undefined characters in the string are taken to have all zero metrics. @@ -4110,8 +4110,8 @@ undefined characters in the string are taken to have all zero metrics. -To query the server for the bounding box of an 8-bit character string in a -given font, use +To query the server for the bounding box of an 8-bit character string in a +given font, use . XQueryTextExtents @@ -4147,7 +4147,7 @@ Specifies the connection to the X server. -Specifies either the font ID or the +Specifies either the font ID or the GContext ID that contains the font. @@ -4260,7 +4260,7 @@ Specifies the connection to the X server. -Specifies either the font ID or the +Specifies either the font ID or the GContext ID that contains the font. @@ -4345,7 +4345,7 @@ specified GC. These functions query the X server and, therefore, suffer the round-trip overhead that is avoided by -and +and . Both functions return a XCharStruct @@ -4353,10 +4353,10 @@ structure, whose members are set to the values as follows. -The ascent member is set to the maximum of the ascent metrics +The ascent member is set to the maximum of the ascent metrics of all characters in the string. The descent member is set to the maximum of the descent metrics. -The width member is set to the sum of the character-width metrics +The width member is set to the sum of the character-width metrics of all characters in the string. For each character in the string, let W be the sum of the character-width metrics of all characters preceding @@ -4369,9 +4369,9 @@ The rbearing member is set to the maximum R. For fonts defined with linear indexing rather than 2-byte matrix indexing, -each +each XChar2b -structure is interpreted as a 16-bit number with byte1 as the +structure is interpreted as a 16-bit number with byte1 as the most significant byte. If the font has no defined default character, undefined characters in the string are taken to have all zero metrics. @@ -4407,7 +4407,7 @@ This section discusses how to draw: -Complex text +Complex text @@ -4533,7 +4533,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -4629,7 +4629,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -4699,12 +4699,12 @@ Both functions allow complex spacing and font shifts between counted strings. Each text item is processed in turn. -A font member other than +A font member other than None in an item causes the font to be stored in the GC -and used for subsequent text. +and used for subsequent text. A text element delta specifies an additional change -in the position along the x axis before the string is drawn. +in the position along the x axis before the string is drawn. The delta is always added to the character origin and is not dependent on any characteristics of the font. Each character image, as defined by the font in the GC, is treated as an @@ -4717,18 +4717,18 @@ error, the previous text items may have been drawn. For fonts defined with linear indexing rather than 2-byte matrix indexing, -each +each XChar2b -structure is interpreted as a 16-bit number with byte1 as the +structure is interpreted as a 16-bit number with byte1 as the most significant byte. Both functions use these GC components: -function, plane-mask, fill-style, font, subwindow-mode, +function, plane-mask, fill-style, font, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, and tile-stipple-y-origin. @@ -4789,7 +4789,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -4885,7 +4885,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -4955,11 +4955,11 @@ each byte is used as a byte2 with a byte1 of zero. -Both functions use these GC components: -function, plane-mask, fill-style, font, subwindow-mode, clip-x-origin, +Both functions use these GC components: +function, plane-mask, fill-style, font, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. -They also use these GC mode-dependent components: -foreground, background, tile, stipple, tile-stipple-x-origin, +They also use these GC mode-dependent components: +foreground, background, tile, stipple, tile-stipple-x-origin, and tile-stipple-y-origin. @@ -5029,7 +5029,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -5125,7 +5125,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -5190,7 +5190,7 @@ The function is similar to except that it uses 2-byte or 16-bit characters. -Both functions also use both the foreground and background pixels +Both functions also use both the foreground and background pixels of the GC in the destination. @@ -5229,11 +5229,11 @@ font-ascent + font-descent The overall-width, font-ascent, and font-descent -are as would be returned by +are as would be returned by using gc and string. -The function and fill-style defined in the GC are ignored for these functions. -The effective function is +The function and fill-style defined in the GC are ignored for these functions. +The effective function is GXcopy, and the effective fill-style is FillSolid. @@ -5247,8 +5247,8 @@ each byte is used as a byte2 with a byte1 of zero. -Both functions use these GC components: -plane-mask, foreground, background, font, subwindow-mode, clip-x-origin, +Both functions use these GC components: +plane-mask, foreground, background, font, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. @@ -5275,14 +5275,14 @@ errors. -Xlib provides functions that you can use to transfer images between a client +Xlib provides functions that you can use to transfer images between a client and the server. -Because the server may require diverse data formats, -Xlib provides an image object that fully describes the data in memory -and that provides for basic operations on that data. -You should reference the data +Because the server may require diverse data formats, +Xlib provides an image object that fully describes the data in memory +and that provides for basic operations on that data. +You should reference the data through the image object rather than referencing the data directly. -However, some implementations of the Xlib library may efficiently deal with +However, some implementations of the Xlib library may efficiently deal with frequently used data formats by replacing functions in the procedure vector with special case functions. Supported operations include destroying the image, getting a pixel, @@ -5291,8 +5291,8 @@ to an image (see section 16.8). -All the image manipulation functions discussed in this section make use of -the +All the image manipulation functions discussed in this section make use of +the XImage structure, which describes an image as it exists in the client's memory. @@ -5431,7 +5431,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -5451,7 +5451,7 @@ Specifies the GC. -Specifies the image you want combined with the rectangle. +Specifies the image you want combined with the rectangle. @@ -5462,7 +5462,7 @@ Specifies the image you want combined with the rectangle. Specifies the offset in X from the left edge of the image defined -by the +by the XImage structure. @@ -5475,7 +5475,7 @@ structure. Specifies the offset in Y from the top edge of the image defined -by the +by the XImage structure. @@ -5533,9 +5533,9 @@ The function combines an image with a rectangle of the specified drawable. -The section of the image defined by the src_x, src_y, width, and height +The section of the image defined by the src_x, src_y, width, and height arguments is drawn on the specified part of the drawable. -If +If XYBitmap format is used, the depth of the image must be one, or a @@ -5543,9 +5543,9 @@ or a error results. The foreground pixel in the GC defines the source for the one bits in the image, and the background pixel defines the source for the zero bits. -For +For XYPixmap -and +and ZPixmap, the depth of the image must match the depth of the drawable, or a @@ -5562,8 +5562,8 @@ conversions. -This function uses these GC components: -function, plane-mask, subwindow-mode, clip-x-origin, clip-y-origin, +This function uses these GC components: +function, plane-mask, subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask. It also uses these GC mode-dependent components: foreground and background. @@ -5620,7 +5620,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -5688,7 +5688,7 @@ Specifies the plane mask. Specifies the format for the image. You can pass XYPixmap -or +or ZPixmap. @@ -5704,16 +5704,16 @@ function returns a pointer to an structure. This structure provides you with the contents of the specified rectangle of the drawable in the format you specify. -If the format argument is +If the format argument is XYPixmap, the image contains only the bit planes you passed to the plane_mask argument. If the plane_mask argument only requests a subset of the planes of the display, the depth of the returned image will be the number of planes requested. -If the format argument is +If the format argument is ZPixmap, -returns as zero the bits in all planes not +returns as zero the bits in all planes not specified in the plane_mask argument. The function performs no range checking on the values in plane_mask and ignores extraneous bits. @@ -5725,19 +5725,19 @@ returns the depth of the image to the depth member of the XImage structure. The depth of the image is as specified when the drawable was created, -except when getting a subset of the planes in +except when getting a subset of the planes in XYPixmap format, when the depth is given by the number of bits set to 1 in plane_mask. -If the drawable is a pixmap, -the given rectangle must be wholly contained within the pixmap, +If the drawable is a pixmap, +the given rectangle must be wholly contained within the pixmap, or a BadMatch error results. -If the drawable is a window, -the window must be viewable, +If the drawable is a window, +the window must be viewable, and it must be the case that if there were no inferiors or overlapping windows, the specified rectangle of the window would be fully visible on the screen and wholly contained within the outside edges of the window, @@ -5748,7 +5748,7 @@ Note that the borders of the window can be included and read with this request. If the window has backing-store, the backing-store contents are returned for regions of the window that are obscured by noninferior -windows. +windows. If the window does not have backing-store, the returned contents of such obscured regions are undefined. The returned contents of visible regions of inferiors @@ -5811,7 +5811,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -5879,7 +5879,7 @@ Specifies the plane mask. Specifies the format for the image. You can pass XYPixmap -or +or ZPixmap. @@ -5921,17 +5921,17 @@ the subimage is placed in the destination image. -The +The -function updates dest_image with the specified subimage in the same manner as +function updates dest_image with the specified subimage in the same manner as . -If the format argument is +If the format argument is XYPixmap, the image contains only the bit planes you passed to the plane_mask argument. -If the format argument is +If the format argument is ZPixmap, -returns as zero the bits in all planes not +returns as zero the bits in all planes not specified in the plane_mask argument. The function performs no range checking on the values in plane_mask and ignores extraneous bits. @@ -5953,18 +5953,18 @@ the given rectangle must be wholly contained within the pixmap, or a BadMatch error results. -If the drawable is a window, -the window must be viewable, +If the drawable is a window, +the window must be viewable, and it must be the case that if there were no inferiors or overlapping windows, the specified rectangle of the window would be fully visible on the screen and wholly contained within the outside edges of the window, or a BadMatch error results. -If the window has backing-store, -then the backing-store contents are returned for regions of the window -that are obscured by noninferior windows. -If the window does not have backing-store, +If the window has backing-store, +then the backing-store contents are returned for regions of the window +that are obscured by noninferior windows. +If the window does not have backing-store, the returned contents of such obscured regions are undefined. The returned contents of visible regions of inferiors of a different depth than the specified window's depth are also undefined. diff --git a/specs/libX11/CH09.xml b/specs/libX11/CH09.xml index 8b5e7605..a18e4e04 100644 --- a/specs/libX11/CH09.xml +++ b/specs/libX11/CH09.xml @@ -133,7 +133,7 @@ request on it. The X server performs normal exposure processing on formerly obscured windows. -The X server might not generate +The X server might not generate Expose events for regions from the initial UnmapWindow @@ -197,14 +197,14 @@ For further information about close-connection processing, see section 2.6. To allow an application's window to survive when a window manager that has reparented a window fails, -Xlib provides the save-set functions that you can +Xlib provides the save-set functions that you can use to control the longevity of subwindows that are normally destroyed when the parent is destroyed. For example, a window manager that wants to add decoration to a window by adding a frame might reparent an application's -window. +window. When the frame is destroyed, -the application's window should not be destroyed +the application's window should not be destroyed but be returned to its previous place in the window hierarchy. @@ -271,7 +271,7 @@ or Depending on the specified mode, -either inserts or deletes the specified window from the client's save-set. +either inserts or deletes the specified window from the client's save-set. The specified window must have been created by some other client, or a BadMatch @@ -415,7 +415,7 @@ The X server maintains a list of installed colormaps. Windows using these colormaps are guaranteed to display with correct colors; windows using other colormaps may or may not display with correct colors. -Xlib provides functions that you can use to install a colormap, +Xlib provides functions that you can use to install a colormap, uninstall a colormap, and obtain a list of installed colormaps. @@ -430,7 +430,7 @@ The required list is maintained as follows. When a colormap is specified to , it is added to the head of the list; -the list is truncated at the tail, if necessary, to keep its length to +the list is truncated at the tail, if necessary, to keep its length to at most M. When a colormap is specified to @@ -496,11 +496,11 @@ or -If the specified colormap is not already an installed colormap, +If the specified colormap is not already an installed colormap, the X server generates a ColormapNotify event on each window that has that colormap. -In addition, for every other colormap that is installed as +In addition, for every other colormap that is installed as a result of a call to , the X server generates a @@ -560,19 +560,19 @@ The function removes the specified colormap from the required list for its screen. As a result, -the specified colormap might be uninstalled, +the specified colormap might be uninstalled, and the X server might implicitly install or uninstall additional colormaps. Which colormaps get installed or uninstalled is server dependent except that the required list must remain installed. -If the specified colormap becomes uninstalled, +If the specified colormap becomes uninstalled, the X server generates a ColormapNotify event on each window that has that colormap. -In addition, for every other colormap that is installed or uninstalled as a -result of a call to +In addition, for every other colormap that is installed or uninstalled as a +result of a call to , the X server generates a ColormapNotify @@ -639,7 +639,7 @@ Returns the number of currently installed colormaps. The -function returns a list of the currently installed colormaps for the screen +function returns a list of the currently installed colormaps for the screen of the specified window. The order of the colormaps in the list is not significant and is no explicit indication of the required list. @@ -725,7 +725,7 @@ The function defines the directory search path for font lookup. There is only one search path per X server, not one per client. The encoding and interpretation of the strings are implementation-dependent, -but typically they specify directories or font servers to be searched +but typically they specify directories or font servers to be searched in the order listed. An X server is permitted to cache font information internally; for example, it might cache an entire font from a file and not @@ -733,7 +733,7 @@ check on subsequent opens of that font to see if the underlying font file has changed. However, when the font path is changed, -the X server is guaranteed to flush all cached information about fonts +the X server is guaranteed to flush all cached information about fonts for which there currently are no explicit resource IDs allocated. The meaning of an error from this request is implementation-dependent. @@ -884,7 +884,7 @@ Specifies the connection to the X server. The -function disables processing of requests and close downs on all other +function disables processing of requests and close downs on all other connections than the one this request arrived on. You should not grab the X server any more than is absolutely necessary. @@ -979,13 +979,13 @@ forces a close down of the client that created the resource if a valid resource is specified. If the client has already terminated in -either +either RetainPermanent -or +or RetainTemporary mode, all of the client's resources are destroyed. -If +If AllTemporary is specified, the resources of all clients that have terminated in RetainTemporary @@ -994,8 +994,8 @@ This permits implementation of window manager facilities that aid debugging. A client can set its close-down mode to RetainTemporary. If the client then crashes, -its windows would not be destroyed. -The programmer can then inspect the application's window tree +its windows would not be destroyed. +The programmer can then inspect the application's window tree and use the window manager to destroy the zombie windows. @@ -1013,7 +1013,7 @@ error. -Xlib provides functions that you can use to set or reset the mode +Xlib provides functions that you can use to set or reset the mode of the screen saver, to force or activate the screen saver, or to obtain the current screen saver values. @@ -1101,33 +1101,33 @@ or -Timeout and interval are specified in seconds. -A timeout of 0 disables the screen saver +Timeout and interval are specified in seconds. +A timeout of 0 disables the screen saver (but an activated screen saver is not deactivated), and a timeout of −1 restores the default. Other negative values generate a BadValue error. -If the timeout value is nonzero, +If the timeout value is nonzero, enables the screen saver. An interval of 0 disables the random-pattern motion. -If no input from devices (keyboard, mouse, and so on) is generated +If no input from devices (keyboard, mouse, and so on) is generated for the specified number of timeout seconds once the screen saver is enabled, the screen saver is activated. -For each screen, -if blanking is preferred and the hardware supports video blanking, -the screen simply goes blank. -Otherwise, if either exposures are allowed or the screen can be regenerated -without sending +For each screen, +if blanking is preferred and the hardware supports video blanking, +the screen simply goes blank. +Otherwise, if either exposures are allowed or the screen can be regenerated +without sending Expose -events to clients, -the screen is tiled with the root window background tile randomly +events to clients, +the screen is tiled with the root window background tile randomly re-origined each interval seconds. -Otherwise, the screens' state do not change, +Otherwise, the screens' state do not change, and the screen saver is not activated. The screen saver is deactivated, and all screen states are restored at the next @@ -1198,18 +1198,18 @@ or -If the specified mode is +If the specified mode is ScreenSaverActive and the screen saver currently is deactivated, activates the screen saver even if the screen saver had been disabled with a timeout of zero. -If the specified mode is +If the specified mode is ScreenSaverReset and the screen saver currently is enabled, deactivates the screen saver if it was activated, -and the activation timer is reset to its initial state +and the activation timer is reset to its initial state (as if device input had been received). @@ -1420,7 +1420,7 @@ DECnet nodes must terminate in :: to distinguish them from Internet hosts. -If a host is not in the access control list when the access control +If a host is not in the access control list when the access control mechanism is enabled and if the host attempts to establish a connection, the server refuses the connection. To change the access list, @@ -1445,7 +1445,7 @@ see Xlib provides functions that you can use to add, get, or remove hosts from the access control list. -All the host access control functions use the +All the host access control functions use the XHostAddress structure, which contains: @@ -1466,7 +1466,7 @@ typedef struct { -The family member specifies which protocol address family to use +The family member specifies which protocol address family to use (for example, TCP/IP or DECnet) and can be FamilyInternet, FamilyInternet6, @@ -1486,7 +1486,7 @@ family should be FamilyInternet6 and the length should be 16 bytes. -For the DECnet family, +For the DECnet family, the server performs no automatic swapping on the address bytes. A Phase IV address is 2 bytes long. The first byte contains the least significant 8 bits of the node number. @@ -1496,8 +1496,8 @@ and the area in the most significant 6 bits of the byte. -For the ServerInterpreted family, the length is ignored and the address -member is a pointer to a +For the ServerInterpreted family, the length is ignored and the address +member is a pointer to a XServerInterpretedAddress structure, which contains: @@ -1703,12 +1703,12 @@ Returns the state of the access control. The -function returns the current access control list as well as whether the use +function returns the current access control list as well as whether the use of the list at connection setup was enabled or disabled. allows a program to find out what machines can make connections. It also returns a pointer to a list of host structures that -were allocated by the function. +were allocated by the function. When no longer needed, this memory should be freed by calling . @@ -1756,7 +1756,7 @@ Specifies the host that is to be removed. The -function removes the specified host from the access control list +function removes the specified host from the access control list for that display. The server must be on the same host as the client process, or a BadAccess @@ -1828,12 +1828,12 @@ Specifies the number of hosts. The -function removes each specified host from the access control list for that -display. +function removes each specified host from the access control list for that +display. The X server must be on the same host as the client process, or a BadAccess error results. -If you remove your machine from the access list, +If you remove your machine from the access list, you can no longer connect to that server, and this operation cannot be reversed unless you reset the server. @@ -1854,7 +1854,7 @@ errors. -Xlib provides functions that you can use to enable, disable, +Xlib provides functions that you can use to enable, disable, or change access control. @@ -1911,7 +1911,7 @@ or The -function either enables or disables the use of the access control list +function either enables or disables the use of the access control list at each connection setup. diff --git a/specs/libX11/CH10.xml b/specs/libX11/CH10.xml index 9c12ef71..d1de898d 100644 --- a/specs/libX11/CH10.xml +++ b/specs/libX11/CH10.xml @@ -36,14 +36,14 @@ Functions for handling events are dealt with in Eventtypes -An event is data generated asynchronously by the X server as a result of some +An event is data generated asynchronously by the X server as a result of some device activity or as side effects of a request sent by an Xlib function. Event Device-related events propagate from the source window to ancestor windows -until some client application has selected that event type +until some client application has selected that event type or until the event is explicitly discarded. The X server generally sends an event to a client application -only if the client has specifically asked to be informed of that event type, +only if the client has specifically asked to be informed of that event type, typically by setting the event-mask attribute of the window. The mask can also be set when you create a window or by changing the window's @@ -60,7 +60,7 @@ events are always sent to all clients. An event type describes a specific event generated by the X server. -For each event type, +For each event type, a corresponding constant name is defined in <X11/X.h>, X11/X.h @@ -68,8 +68,8 @@ a corresponding constant name is defined in Headers<X11/X.h> which is used when referring to an event type. Eventcategories -The following table lists the event category -and its associated event type or types. +The following table lists the event category +and its associated event type or types. The processing associated with these events is discussed in section 10.5. @@ -225,8 +225,8 @@ dispatchers. -The X server can send events at any time in the input stream. -Xlib stores any events received while waiting for a reply in an event queue +The X server can send events at any time in the input stream. +Xlib stores any events received while waiting for a reply in an event queue for later use. Xlib also provides functions that allow you to check events in the event queue (see section 11.3). @@ -237,7 +237,7 @@ In addition to the individual structures declared for each event type, the XEvent structure is a union of the individual structures declared for each event type. Depending on the type, -you should access members of each event by using the +you should access members of each event by using the XEvent union. @@ -335,11 +335,11 @@ return to a client application. Unless the client has specifically asked for them, -most events are not reported to clients when they are generated. +most events are not reported to clients when they are generated. Unless the client suppresses them by setting graphics-exposures in the GC to False, GraphicsExpose -and +and NoExpose are reported by default as a result of @@ -361,7 +361,7 @@ is always sent to clients. -The following table +The following table lists the event mask constants you can pass to the event_mask argument and the circumstances in which you would want to specify the @@ -502,7 +502,7 @@ event mask: The event reported to a client application during event processing -depends on which event masks you provide as the event-mask attribute +depends on which event masks you provide as the event-mask attribute for a window. For some event masks, there is a one-to-one correspondence between the event mask constant and the event type constant. @@ -534,9 +534,9 @@ events. -In another case, +In another case, two event masks can map to one event type. -For example, +For example, if you pass either PointerMotionMask or @@ -548,9 +548,9 @@ event. -The following table -lists the event mask, -its associated event type or types, +The following table +lists the event mask, +its associated event type or types, and the structure name associated with the event type. Some of these structures actually are typedefs to a generic structure that is shared between two event types. @@ -796,7 +796,7 @@ Note that N.A. appears in columns for which the information is not applicable. -The sections that follow describe the processing that occurs +The sections that follow describe the processing that occurs when you select the different event masks. The sections are organized according to these processing categories: @@ -878,8 +878,8 @@ Keyboard and pointer events -The following describes the event processing that occurs when a pointer button -press is processed with the pointer in some window w and +The following describes the event processing that occurs when a pointer button +press is processed with the pointer in some window w and when no active pointer grab is in progress. @@ -944,7 +944,7 @@ with these client passed arguments: -The active grab is automatically terminated when +The active grab is automatically terminated when the logical state of the pointer has all buttons released. Clients can modify the active grab by calling @@ -968,7 +968,7 @@ and This section discusses the processing that occurs for the keyboard events KeyPress -and +and KeyRelease and the pointer events ButtonPress, @@ -987,7 +987,7 @@ The X server reports or KeyRelease events to clients wanting information about keys that logically change state. -Note that these events are generated for all keys, +Note that these events are generated for all keys, even those mapped to modifier bits. ButtonPress ButtonRelease @@ -1003,17 +1003,17 @@ events to clients wanting information about buttons that logically change state. The X server reports MotionNotify events to clients wanting information about when the pointer logically moves. -The X server generates this event whenever the pointer is moved +The X server generates this event whenever the pointer is moved and the pointer motion begins and ends in the window. The granularity of MotionNotify -events is not guaranteed, +events is not guaranteed, but a client that selects this event type is guaranteed to receive at least one event when the pointer moves and then rests. -The generation of the logical changes lags the physical changes +The generation of the logical changes lags the physical changes if device event processing is frozen. @@ -1024,7 +1024,7 @@ To receive ButtonPress, and ButtonRelease -events, set +events, set KeyPressMask, KeyReleaseMask, ButtonPressMask, @@ -1034,9 +1034,9 @@ bits in the event-mask attribute of the window. -To receive +To receive MotionNotify -events, set one or more of the following event +events, set one or more of the following event masks bits in the event-mask attribute of the window. @@ -1071,7 +1071,7 @@ events only when at least one button is pressed. -The client application receives +The client application receives MotionNotify events independent of the state of the pointer buttons. @@ -1086,14 +1086,14 @@ the pointer buttons. If PointerMotionHintMask -is selected in combination with one or more of the above masks, +is selected in combination with one or more of the above masks, the X server is free to send only one MotionNotify event (with the is_hint member of the XPointerMovedEvent structure set to NotifyHint) -to the client for the event window, +to the client for the event window, until either the key or button state changes, the pointer leaves the event window, or the client calls @@ -1109,11 +1109,11 @@ events without is_hint set to The source of the event is the viewable window that the pointer is in. -The window used by the X server to report these events depends on -the window's position in the window hierarchy +The window used by the X server to report these events depends on +the window's position in the window hierarchy and whether any intervening window prohibits the generation of these events. -Starting with the source window, -the X server searches up the window hierarchy until it locates the first +Starting with the source window, +the X server searches up the window hierarchy until it locates the first window specified by a client as having an interest in these events. If one of the intervening windows has its do-not-propagate-mask set to prohibit generation of the event type, @@ -1188,7 +1188,7 @@ typedef XMotionEvent XPointerMovedEvent; These structures have the following common members: window, root, subwindow, time, x, y, x_root, y_root, state, and same_screen. The window member is set to the window on which the -event was generated and is referred to as the event window. +event was generated and is referred to as the event window. As long as the conditions previously discussed are met, this is the window used by the X server to report the event. The root member is set to the source window's root window. @@ -1198,7 +1198,7 @@ relative to the root window's origin at the time of the event. -The same_screen member is set to indicate whether the event +The same_screen member is set to indicate whether the event window is on the same screen as the root window and can be either True @@ -1213,25 +1213,25 @@ the event and root windows are not on the same screen. -If the source window is an inferior of the event window, +If the source window is an inferior of the event window, the subwindow member of the structure is set to the child of the event window that is the source window or the child of the event window that is an ancestor of the source window. Otherwise, the X server sets the subwindow member to None. -The time member is set to the time when the event was generated +The time member is set to the time when the event was generated and is expressed in milliseconds. -If the event window is on the same screen as the root window, +If the event window is on the same screen as the root window, the x and y members are set to the coordinates relative to the event window's origin. Otherwise, these members are set to zero. -The state member is set to indicate the logical state of the pointer buttons +The state member is set to indicate the logical state of the pointer buttons and modifier keys just prior to the event, which is the bitwise inclusive OR of one or more of the button or modifier key masks: @@ -1281,7 +1281,7 @@ value. For the XPointerMovedEvent structure, this member is called is_hint. -It can be set to +It can be set to NotifyNormal or NotifyHint. @@ -1410,7 +1410,7 @@ follows: EventsEnterNotify EventsLeaveNotify -This section describes the processing that +This section describes the processing that occurs for the window crossing events EnterNotify and @@ -1423,9 +1423,9 @@ pointer to be in a different window than before, the X server reports or LeaveNotify events to clients who have selected for these events. -All +All EnterNotify -and +and LeaveNotify events caused by a hierarchy change are generated after any hierarchy event @@ -1435,14 +1435,14 @@ generated after any hierarchy event GravityNotify, CirculateNotify) caused by that change; -however, the X protocol does not constrain the ordering of +however, the X protocol does not constrain the ordering of EnterNotify -and +and LeaveNotify events with respect to FocusOut, VisibilityNotify, -and +and Expose events. @@ -1499,7 +1499,7 @@ typedef struct { int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ int detail; /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyAncestor, NotifyVirtual, NotifyInferior, * NotifyNonlinear,NotifyNonlinearVirtual */ Bool same_screen; /* same screen flag */ @@ -1517,10 +1517,10 @@ The window member is set to the window on which the EnterNotify or LeaveNotify -event was generated and is referred to as the event window. -This is the window used by the X server to report the event, +event was generated and is referred to as the event window. +This is the window used by the X server to report the event, and is relative to the root -window on which the event occurred. +window on which the event occurred. The root member is set to the root window of the screen on which the event occurred. @@ -1535,7 +1535,7 @@ Otherwise, the X server sets the subwindow member to None. For an EnterNotify -event, if a child of the event window contains the final pointer position, +event, if a child of the event window contains the final pointer position, the subwindow component is set to that child or None. @@ -1543,13 +1543,13 @@ the subwindow component is set to that child or The time member is set to the time when the event was generated and is expressed in milliseconds. -The x and y members are set to the coordinates of the pointer position in +The x and y members are set to the coordinates of the pointer position in the event window. This position is always the pointer's final position, not its initial position. If the event window is on the same screen as the root window, x and y are the pointer coordinates -relative to the event window's origin. +relative to the event window's origin. Otherwise, x and y are set to zero. The x_root and y_root members are set to the pointer's coordinates relative to the root window's origin at the time of the event. @@ -1588,7 +1588,7 @@ the event window is not the focus window or an inferior of the focus window. The state member is set to indicate the state of the pointer buttons and modifier keys just prior to the event. -The X server can set this member to the bitwise inclusive OR of one +The X server can set this member to the bitwise inclusive OR of one or more of the button or modifier key masks: Button1Mask, Button2Mask, @@ -1606,10 +1606,10 @@ or more of the button or modifier key masks: -The mode member is set to indicate whether the events are normal events, +The mode member is set to indicate whether the events are normal events, pseudo-motion events when a grab activates, or pseudo-motion events when a grab deactivates. -The X server can set this member to +The X server can set this member to NotifyNormal, NotifyGrab, or @@ -1647,7 +1647,7 @@ structures whose mode member is set to -When the pointer moves from window A to window B and A is an inferior of B, +When the pointer moves from window A to window B and A is an inferior of B, the X server does the following: @@ -1677,7 +1677,7 @@ structure set to It generates an EnterNotify -event on window B, with the detail member of the +event on window B, with the detail member of the XEnterWindowEvent structure set to NotifyInferior. @@ -1706,8 +1706,8 @@ structure set to It generates an EnterNotify -event on each window between window A and window B, exclusive, with the -detail member of each +event on each window between window A and window B, exclusive, with the +detail member of each XEnterWindowEvent structure set to NotifyVirtual. @@ -1717,7 +1717,7 @@ structure set to It generates an EnterNotify -event on window B, with the detail member of the +event on window B, with the detail member of the XEnterWindowEvent structure set to NotifyAncestor. @@ -1726,8 +1726,8 @@ structure set to -When the pointer moves from window A to window B -and window C is their least common ancestor, +When the pointer moves from window A to window B +and window C is their least common ancestor, the X server does the following: @@ -1739,7 +1739,7 @@ It generates a event on window A, with the detail member of the XLeaveWindowEvent -structure set to +structure set to NotifyNonlinear. @@ -1758,7 +1758,7 @@ structure set to It generates an EnterNotify -event on each window between window C and window B, exclusive, +event on each window between window C and window B, exclusive, with the detail member of each XEnterWindowEvent structure set to @@ -1769,16 +1769,16 @@ structure set to It generates an EnterNotify -event on window B, with the detail member of the +event on window B, with the detail member of the XEnterWindowEvent -structure set to +structure set to NotifyNonlinear. -When the pointer moves from window A to window B on different screens, +When the pointer moves from window A to window B on different screens, the X server does the following: @@ -1790,7 +1790,7 @@ It generates a event on window A, with the detail member of the XLeaveWindowEvent -structure set to +structure set to NotifyNonlinear. @@ -1802,7 +1802,7 @@ it generates a event on each window above window A up to and including its root, with the detail member of each XLeaveWindowEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -1814,7 +1814,7 @@ it generates an event on each window from window B's root down to but not including window B, with the detail member of each XEnterWindowEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -1824,7 +1824,7 @@ It generates an EnterNotify event on window B, with the detail member of the XEnterWindowEvent -structure set to +structure set to NotifyNonlinear. @@ -1849,14 +1849,14 @@ are identified by XEnterWindowEvent or XLeaveWindowEvent -structures whose mode member is set to +structures whose mode member is set to NotifyGrab. Events in which the pointer grab deactivates are identified by XEnterWindowEvent or XLeaveWindowEvent -structures whose mode member is set to +structures whose mode member is set to NotifyUngrab (see ). @@ -1867,41 +1867,9 @@ structures whose mode member is set to When a pointer grab activates after any initial warp into a confine_to window and before generating any actual ButtonPress -event that activates the grab, -G is the grab_window for the grab, -and P is the window the pointer is in, -the X server does the following: - - - - - -It generates -EnterNotify -and -LeaveNotify -events (see section 10.6.1) -with the mode members of the -XEnterWindowEvent -and -XLeaveWindowEvent -structures set to -NotifyGrab. -These events are generated -as if the pointer were to suddenly warp from -its current position in P to some position in G. -However, the pointer does not warp, and the X server uses the pointer position -as both the initial and final positions for the events. - - - - - -When a pointer grab deactivates after generating any actual -ButtonRelease -event that deactivates the grab, +event that activates the grab, G is the grab_window for the grab, -and P is the window the pointer is in, +and P is the window the pointer is in, the X server does the following: @@ -1917,7 +1885,39 @@ with the mode members of the XEnterWindowEvent and XLeaveWindowEvent -structures set to +structures set to +NotifyGrab. +These events are generated +as if the pointer were to suddenly warp from +its current position in P to some position in G. +However, the pointer does not warp, and the X server uses the pointer position +as both the initial and final positions for the events. + + + + + +When a pointer grab deactivates after generating any actual +ButtonRelease +event that deactivates the grab, +G is the grab_window for the grab, +and P is the window the pointer is in, +the X server does the following: + + + + + +It generates +EnterNotify +and +LeaveNotify +events (see section 10.6.1) +with the mode members of the +XEnterWindowEvent +and +XLeaveWindowEvent +structures set to NotifyUngrab. These events are generated as if the pointer were to suddenly warp from some position in G to its current position in P. @@ -1950,8 +1950,8 @@ The X server can report or FocusOut events to clients wanting information about when the input focus changes. -The keyboard is always attached to some window -(typically, the root window or a top-level window), +The keyboard is always attached to some window +(typically, the root window or a top-level window), which is called the focus window. The focus window and the position of the pointer determine the window that receives keyboard input. @@ -1966,7 +1966,7 @@ or FocusOut events, set the FocusChangeMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. @@ -1989,9 +1989,9 @@ typedef struct { int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ int detail; /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyAncestor, NotifyVirtual, NotifyInferior, * NotifyNonlinear,NotifyNonlinearVirtual, NotifyPointer, - * NotifyPointerRoot, NotifyDetailNone + * NotifyPointerRoot, NotifyDetailNone */ } XFocusChangeEvent; typedef XFocusChangeEvent XFocusInEvent; @@ -2005,13 +2005,13 @@ The window member is set to the window on which the or FocusOut event was generated. -This is the window used by the X server to report the event. -The mode member is set to indicate whether the focus events -are normal focus events, +This is the window used by the X server to report the event. +The mode member is set to indicate whether the focus events +are normal focus events, focus events while grabbed, focus events when a grab activates, or focus events when a grab deactivates. -The X server can set the mode member to +The X server can set the mode member to NotifyNormal, NotifyWhileGrabbed, NotifyGrab, @@ -2020,14 +2020,14 @@ or -All +All FocusOut events caused by a window unmap are generated after any UnmapNotify -event; however, the X protocol does not constrain the ordering of +event; however, the X protocol does not constrain the ordering of FocusOut events with respect to -generated +generated EnterNotify, LeaveNotify, VisibilityNotify, @@ -2060,22 +2060,22 @@ Normal focus events are identified by XFocusInEvent or XFocusOutEvent -structures whose mode member is set to +structures whose mode member is set to NotifyNormal. Focus events while grabbed are identified by XFocusInEvent or XFocusOutEvent -structures whose mode member is set to +structures whose mode member is set to NotifyWhileGrabbed. -The X server processes normal focus and focus events while grabbed according to +The X server processes normal focus and focus events while grabbed according to the following: -When the focus moves from window A to window B, A is an inferior of B, -and the pointer is in window P, +When the focus moves from window A to window B, A is an inferior of B, +and the pointer is in window P, the X server does the following: @@ -2086,7 +2086,7 @@ It generates a FocusOut event on window A, with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyAncestor. @@ -2097,7 +2097,7 @@ It generates a event on each window between window A and window B, exclusive, with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyVirtual. @@ -2105,9 +2105,9 @@ structure set to It generates a FocusIn -event on window B, with the detail member of the +event on window B, with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyInferior. @@ -2117,18 +2117,18 @@ If window P is an inferior of window B but window P is not window A or an inferior or ancestor of window A, it generates a FocusIn -event on each window below window B, down to and including window P, -with the detail member of each +event on each window below window B, down to and including window P, +with the detail member of each XFocusInEvent -structure set to +structure set to NotifyPointer. -When the focus moves from window A to window B, B is an inferior of A, -and the pointer is in window P, +When the focus moves from window A to window B, B is an inferior of A, +and the pointer is in window P, the X server does the following: @@ -2140,9 +2140,9 @@ but P is not an inferior of window B or an ancestor of B, it generates a FocusOut event on each window from window P up to but not including window A, -with the detail member of each +with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyPointer. @@ -2153,7 +2153,7 @@ It generates a event on window A, with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyInferior. @@ -2161,10 +2161,10 @@ structure set to It generates a FocusIn -event on each window between window A and window B, exclusive, with the -detail member of each +event on each window between window A and window B, exclusive, with the +detail member of each XFocusInEvent -structure set to +structure set to NotifyVirtual. @@ -2172,18 +2172,18 @@ structure set to It generates a FocusIn -event on window B, with the detail member of the +event on window B, with the detail member of the XFocusInEvent -structure set to +structure set to NotifyAncestor. -When the focus moves from window A to window B, -window C is their least common ancestor, -and the pointer is in window P, +When the focus moves from window A to window B, +window C is their least common ancestor, +and the pointer is in window P, the X server does the following: @@ -2193,10 +2193,10 @@ the X server does the following: If window P is an inferior of window A, it generates a FocusOut -event on each window from window P up to but not including window A, -with the detail member of the +event on each window from window P up to but not including window A, +with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyPointer. @@ -2207,7 +2207,7 @@ It generates a event on window A, with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyNonlinear. @@ -2218,7 +2218,7 @@ It generates a event on each window between window A and window C, exclusive, with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -2229,7 +2229,7 @@ It generates a event on each window between C and B, exclusive, with the detail member of each XFocusInEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -2237,9 +2237,9 @@ structure set to It generates a FocusIn -event on window B, with the detail member of the +event on window B, with the detail member of the XFocusInEvent -structure set to +structure set to NotifyNonlinear. @@ -2247,18 +2247,18 @@ structure set to If window P is an inferior of window B, it generates a FocusIn -event on each window below window B down to and including window P, -with the detail member of the +event on each window below window B down to and including window P, +with the detail member of the XFocusInEvent -structure set to +structure set to NotifyPointer. -When the focus moves from window A to window B on different screens -and the pointer is in window P, +When the focus moves from window A to window B on different screens +and the pointer is in window P, the X server does the following: @@ -2267,10 +2267,10 @@ the X server does the following: If window P is an inferior of window A, it generates a FocusOut -event on each window from window P up to but not including window A, -with the detail member of each +event on each window from window P up to but not including window A, +with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyPointer. @@ -2281,7 +2281,7 @@ It generates a event on window A, with the detail member of the XFocusOutEvent -structure set to +structure set to NotifyNonlinear. @@ -2290,10 +2290,10 @@ structure set to If window A is not a root window, it generates a FocusOut -event on each window above window A up to and including its root, +event on each window above window A up to and including its root, with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -2305,7 +2305,7 @@ it generates a event on each window from window B's root down to but not including window B, with the detail member of each XFocusInEvent -structure set to +structure set to NotifyNonlinearVirtual. @@ -2313,9 +2313,9 @@ structure set to It generates a FocusIn -event on window B, with the detail member of each +event on window B, with the detail member of each XFocusInEvent -structure set to +structure set to NotifyNonlinear. @@ -2323,17 +2323,17 @@ structure set to If window P is an inferior of window B, it generates a FocusIn -event on each window below window B down to and including window P, -with the detail member of each +event on each window below window B down to and including window P, +with the detail member of each XFocusInEvent -structure set to +structure set to NotifyPointer. -When the focus moves from window A to +When the focus moves from window A to PointerRoot (events sent to the window under the pointer) or @@ -2347,10 +2347,10 @@ the X server does the following: If window P is an inferior of window A, it generates a FocusOut -event on each window from window P up to but not including window A, -with the detail member of each +event on each window from window P up to but not including window A, +with the detail member of each XFocusOutEvent -structure set to +structure set to NotifyPointer. @@ -2369,7 +2369,7 @@ structure set to If window A is not a root window, it generates a FocusOut -event on each window above window A up to and including its root, +event on each window above window A up to and including its root, with the detail member of each XFocusOutEvent structure set to @@ -2394,7 +2394,7 @@ If the new focus is PointerRoot, it generates a FocusIn -event on each window from window P's root down to and including window P, +event on each window from window P's root down to and including window P, with the detail member of each XFocusInEvent structure set to @@ -2404,13 +2404,13 @@ structure set to -When the focus moves from +When the focus moves from PointerRoot (events sent to the window under the pointer) or None -to window A, and the pointer is in window P, -the X server does the following: +to window A, and the pointer is in window P, +the X server does the following: @@ -2420,7 +2420,7 @@ If the old focus is PointerRoot, it generates a FocusOut -event on each window from window P up to and including window P's root, +event on each window from window P up to and including window P's root, with the detail member of each XFocusOutEvent structure set to @@ -2457,9 +2457,9 @@ structure set to It generates a FocusIn event on window A, -with the detail member of the +with the detail member of the XFocusInEvent -structure set to +structure set to NotifyNonlinear. @@ -2467,22 +2467,22 @@ structure set to If window P is an inferior of window A, it generates a FocusIn -event on each window below window A down to and including window P, -with the detail member of each +event on each window below window A down to and including window P, +with the detail member of each XFocusInEvent -structure set to +structure set to NotifyPointer. -When the focus moves from +When the focus moves from PointerRoot (events sent to the window under the pointer) to None -(or vice versa), and the pointer is in window P, +(or vice versa), and the pointer is in window P, the X server does the following: @@ -2493,7 +2493,7 @@ If the old focus is PointerRoot, it generates a FocusOut -event on each window from window P up to and including window P's root, +event on each window from window P up to and including window P's root, with the detail member of each XFocusOutEvent structure set to @@ -2505,7 +2505,7 @@ structure set to It generates a FocusOut event on all root windows, -with the detail member of each +with the detail member of each XFocusOutEvent structure set to either NotifyPointerRoot @@ -2532,7 +2532,7 @@ If the new focus is PointerRoot, it generates a FocusIn -event on each window from window P's root down to and including window P, +event on each window from window P's root down to and including window P, with the detail member of each XFocusInEvent structure set to @@ -2555,40 +2555,40 @@ are identified by XFocusInEvent or XFocusOutEvent -structures whose mode member is set to +structures whose mode member is set to NotifyGrab. Focus events in which the keyboard grab deactivates are identified by XFocusInEvent or XFocusOutEvent -structures whose mode member is set to +structures whose mode member is set to NotifyUngrab -(see +(see ). -When a keyboard grab activates before generating any actual +When a keyboard grab activates before generating any actual KeyPress event that activates the grab, -G is the grab_window, and F is the current focus, +G is the grab_window, and F is the current focus, the X server does the following: -It generates +It generates FocusIn and FocusOut -events, with the mode members of the +events, with the mode members of the XFocusInEvent and XFocusOutEvent -structures set to +structures set to NotifyGrab. These events are generated as if the focus were to change from @@ -2608,11 +2608,11 @@ the X server does the following: -It generates +It generates FocusIn and FocusOut -events, with the mode members of the +events, with the mode members of the XFocusInEvent and XFocusOutEvent @@ -2646,7 +2646,7 @@ To receive KeymapNotify events, set the KeymapStateMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. The X server generates this event immediately after every EnterNotify and @@ -2672,7 +2672,7 @@ typedef struct { Display *display; /* Display the event was read from */ Window window; char key_vector[32]; -} XKeymapEvent; +} XKeymapEvent; @@ -2680,10 +2680,10 @@ typedef struct { The window member is not used but is present to aid some toolkits. The key_vector member is set to the bit vector of the keyboard. -Each bit set to 1 indicates that the corresponding key +Each bit set to 1 indicates that the corresponding key is currently pressed. The vector is represented as 32 bytes. -Byte N (from 0) contains the bits for keys 8N to 8N + 7 +Byte N (from 0) contains the bits for keys 8N to 8N + 7 with the least significant bit in the byte representing key 8N. @@ -2694,20 +2694,20 @@ with the least significant bit in the byte representing key 8N. -The X protocol does not guarantee to preserve the contents of window +The X protocol does not guarantee to preserve the contents of window regions when the windows are obscured or reconfigured. Some implementations may preserve the contents of windows. Other implementations are free to destroy the contents of windows when exposed. X expects client applications to assume the responsibility for -restoring the contents of an exposed window region. -(An exposed window region describes a formerly obscured window whose -region becomes visible.) -Therefore, the X server sends +restoring the contents of an exposed window region. +(An exposed window region describes a formerly obscured window whose +region becomes visible.) +Therefore, the X server sends Expose events describing the window and the region of the window that has been exposed. -A naive client application usually redraws the entire window. +A naive client application usually redraws the entire window. A more sophisticated client application redraws only the exposed region. @@ -2733,8 +2733,8 @@ events on windows whose class you specified as The X server can generate Expose events when no valid contents are available for regions of a window -and either the regions are visible, -the regions are viewable and the server is (perhaps newly) maintaining +and either the regions are visible, +the regions are viewable and the server is (perhaps newly) maintaining backing store on the window, or the window is not viewable but the server is (perhaps newly) honoring the window's backing-store attribute of @@ -2746,8 +2746,8 @@ and an Expose event is generated for each rectangle. For any given window, -the X server guarantees to report contiguously -all of the regions exposed by some action that causes +the X server guarantees to report contiguously +all of the regions exposed by some action that causes Expose events, such as raising a window. @@ -2757,7 +2757,7 @@ To receive Expose events, set the ExposureMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. @@ -2795,7 +2795,7 @@ events that are to follow. If count is zero, no more Expose events follow for this window. -However, if count is nonzero, at least that number of +However, if count is nonzero, at least that number of Expose events (and possibly more) follow for this window. Simple applications that do not want to optimize redisplay by distinguishing @@ -2825,7 +2825,7 @@ or The X server generates this event whenever a destination region could not be computed because of an obscured or out-of-bounds source region. In addition, the X server guarantees to report contiguously all of the regions exposed by -some graphics request +some graphics request (for example, copying an area of a drawable to a destination drawable). @@ -2850,7 +2850,7 @@ To receive GraphicsExpose or NoExpose -events, you must first set the graphics-exposure +events, you must first set the graphics-exposure attribute of the graphics context to True. You also can set the graphics-expose attribute when creating a graphics @@ -2905,7 +2905,7 @@ typedef struct { Both structures have these common members: drawable, major_code, and minor_code. -The drawable member is set to the drawable of the destination region on +The drawable member is set to the drawable of the destination region on which the graphics request was to be performed. The major_code member is set to the graphics request initiated by the client and can be either @@ -2922,24 +2922,24 @@ If it is a call to initiated the request. -These constants are defined in +These constants are defined in <X11/Xproto.h>. X11/Xproto.h Files<X11/Xproto.h> Headers<X11/Xproto.h> The minor_code member, -like the major_code member, +like the major_code member, indicates which graphics request was initiated by -the client. +the client. However, the minor_code member is not defined by the core -X protocol and will be zero in these cases, +X protocol and will be zero in these cases, although it may be used by an extension. -The +The XGraphicsExposeEvent -structure has these additional members: x, y, width, height, and count. +structure has these additional members: x, y, width, height, and count. The x and y members are set to the coordinates relative to the drawable's origin and indicate the upper-left corner of the rectangle. The width and height members are set to the size (extent) of the rectangle. @@ -3038,9 +3038,9 @@ events CirculateNotify The X server can report CirculateNotify -events to clients wanting information about when a window changes +events to clients wanting information about when a window changes its position in the stack. -The X server generates this event type whenever a window is actually restacked +The X server generates this event type whenever a window is actually restacked as a result of a client application calling , , @@ -3049,7 +3049,7 @@ or -To receive +To receive CirculateNotify events, set the StructureNotifyMask @@ -3117,13 +3117,13 @@ The X server can report ConfigureNotify events to clients wanting information about actual changes to a window's state, such as size, position, border, and stacking order. -The X server generates this event type whenever one of the following configure +The X server generates this event type whenever one of the following configure window requests made by a client application actually completes: -A window's size, position, border, and/or stacking order is reconfigured +A window's size, position, border, and/or stacking order is reconfigured by calling . @@ -3171,7 +3171,7 @@ A window's border width is changed by calling -To receive +To receive ConfigureNotify events, set the StructureNotifyMask @@ -3213,35 +3213,35 @@ depending on whether or SubstructureNotify was selected. -The window member is set to the window whose size, position, +The window member is set to the window whose size, position, border, and/or stacking order was changed. -The x and y members are set to the coordinates relative to the parent window's +The x and y members are set to the coordinates relative to the parent window's origin and indicate the position of the upper-left outside corner of the window. -The width and height members are set to the inside size of the window, +The width and height members are set to the inside size of the window, not including the border. The border_width member is set to the width of the window's border, in pixels. -The above member is set to the sibling window and is used +The above member is set to the sibling window and is used for stacking operations. If the X server sets this member to None, the window whose state was changed is on the bottom of the stack with respect to sibling windows. -However, if this member is set to a sibling window, +However, if this member is set to a sibling window, the window whose state was changed is placed on top of this sibling window. The override_redirect member is set to the override-redirect attribute of the window. -Window manager clients normally should ignore this window if the +Window manager clients normally should ignore this window if the override_redirect member is True. @@ -3267,7 +3267,7 @@ or -To receive +To receive CreateNotify events, set the SubstructureNotifyMask @@ -3304,15 +3304,15 @@ typedef struct { The parent member is set to the created window's parent. The window member specifies the created window. -The x and y members are set to the created window's coordinates relative -to the parent window's origin and indicate the position of the upper-left +The x and y members are set to the created window's coordinates relative +to the parent window's origin and indicate the position of the upper-left outside corner of the created window. -The width and height members are set to the inside size of the created window +The width and height members are set to the inside size of the created window (not including the border) and are always nonzero. The border_width member is set to the width of the created window's border, in pixels. The override_redirect member is set to the override-redirect attribute of the window. -Window manager clients normally should ignore this window +Window manager clients normally should ignore this window if the override_redirect member is True. @@ -3329,7 +3329,7 @@ if the override_redirect member is The X server can report DestroyNotify events to clients wanting information about which windows are destroyed. -The X server generates this event whenever a client application destroys a +The X server generates this event whenever a client application destroys a window by calling or @@ -3337,18 +3337,18 @@ or -The ordering of the +The ordering of the DestroyNotify -events is such that for any given window, +events is such that for any given window, DestroyNotify is generated on all inferiors of the window -before being generated on the window itself. +before being generated on the window itself. The X protocol does not constrain the ordering among siblings and across subhierarchies. -To receive +To receive DestroyNotify events, set the StructureNotifyMask @@ -3384,7 +3384,7 @@ typedef struct { The event member is set either to the destroyed window or to its parent, depending on whether StructureNotify -or +or SubstructureNotify was selected. The window member is set to the window that is destroyed. @@ -3412,7 +3412,7 @@ or -To receive +To receive GravityNotify events, set the StructureNotifyMask @@ -3454,9 +3454,9 @@ or SubstructureNotify was selected. The window member is set to the child window that was moved. -The x and y members are set to the coordinates relative to the +The x and y members are set to the coordinates relative to the new parent window's origin -and indicate the position of the upper-left outside corner of the +and indicate the position of the upper-left outside corner of the window. @@ -3482,7 +3482,7 @@ or as a result of save-set processing. -To receive +To receive MapNotify events, set the StructureNotifyMask @@ -3525,7 +3525,7 @@ was selected. The window member is set to the window that was mapped. The override_redirect member is set to the override-redirect attribute of the window. -Window manager clients normally should ignore this window +Window manager clients normally should ignore this window if the override-redirect attribute is True, because these events usually are generated from pop-ups, @@ -3545,7 +3545,7 @@ The X server reports MappingNotify events to all clients. There is no mechanism to express disinterest in this event. -The X server generates this event type whenever a client application +The X server generates this event type whenever a client application successfully calls: @@ -3609,12 +3609,12 @@ If it is the keyboard mapping was changed. If it is MappingPointer, -the pointer button mapping was changed. -The first_keycode and count members are set only +the pointer button mapping was changed. +The first_keycode and count members are set only if the request member was set to MappingKeyboard. -The number in first_keycode represents the first number in the range -of the altered mapping, +The number in first_keycode represents the first number in the range +of the altered mapping, and count represents the number of keycodes altered. @@ -3643,7 +3643,7 @@ and the window is actually reparented. -To receive +To receive ReparentNotify events, set the StructureNotifyMask @@ -3684,15 +3684,15 @@ or to the old or the new parent, depending on whether StructureNotify or SubstructureNotify -was selected. +was selected. The window member is set to the window that was reparented. The parent member is set to the new parent window. -The x and y members are set to the reparented window's coordinates relative +The x and y members are set to the reparented window's coordinates relative to the new parent window's origin and define the upper-left outer corner of the reparented window. The override_redirect member is set to the override-redirect attribute of the window specified by the window member. -Window manager clients normally should ignore this window +Window manager clients normally should ignore this window if the override_redirect member is True. @@ -3714,7 +3714,7 @@ window's state from mapped to unmapped. -To receive +To receive UnmapNotify events, set the StructureNotifyMask @@ -3777,13 +3777,13 @@ The X server can report events to clients wanting any change in the visibility of the specified window. A region of a window is visible if someone looking at the screen can actually see it. -The X server generates this event whenever the visibility changes state. +The X server generates this event whenever the visibility changes state. However, this event is never generated for windows whose class is InputOnly. -All +All VisibilityNotify events caused by a hierarchy change are generated after any hierarchy event @@ -3798,26 +3798,26 @@ event on a given window is generated before any Expose events on that window, but it is not required that all VisibilityNotify -events on all windows be generated before all +events on all windows be generated before all Expose -events on all windows. -The X protocol does not constrain the ordering of +events on all windows. +The X protocol does not constrain the ordering of VisibilityNotify events with -respect to +respect to FocusOut, EnterNotify, -and +and LeaveNotify events. -To receive +To receive VisibilityNotify events, set the VisibilityChangeMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. @@ -3850,7 +3850,7 @@ The state member is set to the state of the window's visibility and can be or VisibilityFullyObscured. The X server ignores all of a window's subwindows -when determining the visibility state of the window and processes +when determining the visibility state of the window and processes VisibilityNotify events according to the following: @@ -3867,7 +3867,7 @@ structure set to -When the window changes state from viewable and completely unobscured or +When the window changes state from viewable and completely unobscured or not viewable to viewable and partially obscured, the X server generates the event with the state member of the XVisibilityEvent @@ -3877,8 +3877,8 @@ structure set to -When the window changes state from viewable and completely unobscured, -viewable and partially obscured, or not viewable to viewable and +When the window changes state from viewable and completely unobscured, +viewable and partially obscured, or not viewable to viewable and fully obscured, the X server generates the event with the state member of the XVisibilityEvent @@ -3935,11 +3935,11 @@ events CirculateRequest The X server can report CirculateRequest -events to clients wanting information about -when another client initiates a circulate window request +events to clients wanting information about +when another client initiates a circulate window request on a specified window. The X server generates this event type whenever a client initiates a circulate -window request on a window and a subwindow actually needs to be restacked. +window request on a window and a subwindow actually needs to be restacked. The client initiates a circulate window request on the window by calling , , @@ -3952,7 +3952,7 @@ To receive CirculateRequest events, set the SubstructureRedirectMask -in the event-mask attribute of the window. +in the event-mask attribute of the window. Then, in the future, the circulate window request for the specified window is not executed, and thus, any subwindow's position in the stack is not changed. @@ -4016,9 +4016,9 @@ the subwindow should be below all siblings. ConfigureRequest The X server can report ConfigureRequest -events to clients wanting information about when a different client initiates -a configure window request on any child of a specified window. -The configure window request attempts to +events to clients wanting information about when a different client initiates +a configure window request on any child of a specified window. +The configure window request attempts to reconfigure a window's size, position, border, and stacking order. The X server generates this event whenever a different client initiates a configure window request on a window by calling @@ -4039,7 +4039,7 @@ To receive ConfigureRequest events, set the SubstructureRedirectMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. ConfigureRequest events are generated when a ConfigureWindow @@ -4049,7 +4049,7 @@ For example, suppose a client application calls to lower a window. If you had selected SubstructureRedirectMask -on the parent window and if the override-redirect attribute +on the parent window and if the override-redirect attribute of the window is set to False, the X server reports a @@ -4087,7 +4087,7 @@ typedef struct { The parent member is set to the parent window. -The window member is set to the window whose size, position, border width, +The window member is set to the window whose size, position, border width, and/or stacking order is to be reconfigured. The value_mask member indicates which components were specified in the ConfigureWindow @@ -4113,11 +4113,11 @@ respectively, if they are not given in the request. MapRequest The X server can report MapRequest -events to clients wanting information about a different client's desire +events to clients wanting information about a different client's desire to map windows. A window is considered mapped when a map window request completes. -The X server generates this event whenever a different client initiates -a map window request on an unmapped window whose override_redirect member +The X server generates this event whenever a different client initiates +a map window request on an unmapped window whose override_redirect member is set to False. Clients initiate map window requests by calling @@ -4132,9 +4132,9 @@ To receive MapRequest events, set the SubstructureRedirectMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. This means another client's attempts to map a child window by calling one of -the map window request functions is intercepted, and you are sent a +the map window request functions is intercepted, and you are sent a MapRequest instead. For example, suppose a client application calls @@ -4142,14 +4142,14 @@ For example, suppose a client application calls to map a window. If you (usually a window manager) had selected SubstructureRedirectMask -on the parent window and if the override-redirect attribute +on the parent window and if the override-redirect attribute of the window is set to False, the X server reports a MapRequest -event to you +event to you and does not map the specified window. -Thus, this event gives your window manager client the ability +Thus, this event gives your window manager client the ability to control the placement of subwindows. @@ -4206,7 +4206,7 @@ To receive ResizeRequest events, set the ResizeRedirect -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. Any attempts to change the size by other clients are then redirected. @@ -4233,9 +4233,9 @@ typedef struct { -The window member is set to the window whose size another +The window member is set to the window whose size another client attempted to change. -The width and height members are set to the inside size of the window, +The width and height members are set to the inside size of the window, excluding the border. @@ -4251,8 +4251,8 @@ excluding the border. ColormapNotify The X server can report ColormapNotify -events to clients wanting information about when the colormap changes -and when a colormap is installed or uninstalled. +events to clients wanting information about when the colormap changes +and when a colormap is installed or uninstalled. The X server generates this event type whenever a client application: @@ -4260,7 +4260,7 @@ The X server generates this event type whenever a client application: Changes the colormap member of the XSetWindowAttributes -structure by +structure by calling , , @@ -4279,11 +4279,11 @@ or -To receive +To receive ColormapNotify events, set the ColormapChangeMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. @@ -4311,17 +4311,17 @@ typedef struct { -The window member is set to the window whose associated +The window member is set to the window whose associated colormap is changed, installed, or uninstalled. For a colormap that is changed, installed, or uninstalled, -the colormap member is set to the colormap associated with the window. +the colormap member is set to the colormap associated with the window. For a colormap that is changed by a call to , the colormap member is set to None. -The new member is set to indicate whether the colormap +The new member is set to indicate whether the colormap for the specified window was changed or installed or uninstalled -and can be +and can be True or False. @@ -4332,7 +4332,7 @@ If it is False, the colormap was installed or uninstalled. The state member is always set to indicate whether the colormap is installed or -uninstalled and can be +uninstalled and can be ColormapInstalled or ColormapUninstalled. @@ -4423,12 +4423,12 @@ typedef struct { -The message_type member is set to an atom that indicates how the data +The message_type member is set to an atom that indicates how the data should be interpreted by the receiving client. The format member is set to 8, 16, or 32 and specifies whether the data should be viewed as a list of bytes, shorts, or longs. The data member is a union that contains the members b, s, and l. -The b, s, and l members represent data of twenty 8-bit values, +The b, s, and l members represent data of twenty 8-bit values, ten 16-bit values, and five 32-bit values. Particular message types might not make use of all these values. The X server places no interpretation on the values in the window, @@ -4446,7 +4446,7 @@ message_type, or data members. PropertyNotify The X server can report PropertyNotify -events to clients wanting information about property changes +events to clients wanting information about property changes for a specified window. @@ -4455,7 +4455,7 @@ To receive PropertyNotify events, set the PropertyChangeMask -bit in the event-mask attribute of the window. +bit in the event-mask attribute of the window. @@ -4483,12 +4483,12 @@ typedef struct { -The window member is set to the window whose associated +The window member is set to the window whose associated property was changed. The atom member is set to the property's atom and indicates which property was changed or desired. The time member is set to the server time when the property was changed. -The state member is set to indicate whether the property was changed +The state member is set to indicate whether the property was changed to a new value or deleted and can be PropertyNewValue or @@ -4503,13 +4503,13 @@ or ) and when replacing all or part of a property with identical data using -or +or . The state member is set to PropertyDelete when a property of the window is deleted using -or, if the delete argument is +or, if the delete argument is True, . @@ -4556,7 +4556,7 @@ typedef struct { The selection member is set to the selection atom. -The time member is set to the last change time recorded for the +The time member is set to the last change time recorded for the selection. The window member is the window that was specified by the current owner (the owner losing the selection) in its @@ -4576,8 +4576,8 @@ call. The X server reports SelectionRequest events to the owner of a selection. -The X server generates this event whenever a client -requests a selection conversion by calling +The X server generates this event whenever a client +requests a selection conversion by calling for the owned selection. @@ -4618,9 +4618,9 @@ The selection member is set to the atom that names the selection. For example, PRIMARY is used to indicate the primary selection. The target member is set to the atom that indicates the type the selection is desired in. -The property member can be a property name or +The property member can be a property name or None. -The time member is set to the timestamp or +The time member is set to the timestamp or CurrentTime value from the ConvertSelection @@ -4663,11 +4663,11 @@ not be performed (which is indicated by setting the property member to If None -is specified as the property in the +is specified as the property in the ConvertSelection protocol request, the owner should choose a property name, store the result as that property on the requestor window, -and then send a +and then send a SelectionNotify giving that actual property name. @@ -4706,7 +4706,7 @@ The target member is set to the atom that indicates the converted type. For example, PIXMAP is used for a pixmap. The property member is set to the atom that indicates which property the result was stored on. -If the conversion failed, +If the conversion failed, the property member is set to None. The time member is set to the time the conversion took place and diff --git a/specs/libX11/CH11.xml b/specs/libX11/CH11.xml index 6b967b9a..23773679 100644 --- a/specs/libX11/CH11.xml +++ b/specs/libX11/CH11.xml @@ -92,7 +92,7 @@ Specifies the event mask. The -function requests that the X server report the events associated with the +function requests that the X server report the events associated with the specified event mask. Initially, X will not report any of these events. Events are reported relative to a window. @@ -141,7 +141,7 @@ the event mask -Only one client at a time can select a +Only one client at a time can select a ButtonPress event, which is associated with the event mask @@ -178,7 +178,7 @@ These functions differ in the additional tasks they might perform. -To flush the output buffer, use +To flush the output buffer, use . XFlush @@ -224,7 +224,7 @@ Events generated by the server may be enqueued into the library's event queue. To flush the output buffer and then wait until all requests have been processed, -use +use . XSync @@ -254,7 +254,7 @@ Specifies the connection to the X server. -Specifies a Boolean value that indicates whether +Specifies a Boolean value that indicates whether discards all events on the event queue. @@ -274,16 +274,16 @@ For each protocol error received by Xlib, calls the client application's error handling routine (see section 11.8.2). -Any events generated by the server are enqueued into the library's +Any events generated by the server are enqueued into the library's event queue. -Finally, if you passed +Finally, if you passed False, does not discard the events in the queue. -If you passed +If you passed True, discards all events in the queue, @@ -302,7 +302,7 @@ Client applications seldom need to call Xlib maintains an event queue. -However, the operating system also may be buffering data +However, the operating system also may be buffering data in its network connection that is not yet read into the event queue. @@ -351,27 +351,27 @@ or -If mode is +If mode is QueuedAlready, returns the number of events already in the event queue (and never performs a system call). -If mode is +If mode is QueuedAfterFlush, returns the number of events already in the queue if the number is nonzero. -If there are no events in the queue, +If there are no events in the queue, -flushes the output buffer, +flushes the output buffer, attempts to read more events out of the application's connection, and returns the number read. -If mode is +If mode is QueuedAfterReading, -returns the number of events already in the queue if the number is nonzero. -If there are no events in the queue, +returns the number of events already in the queue if the number is nonzero. +If there are no events in the queue, -attempts to read more events out of the application's connection +attempts to read more events out of the application's connection without flushing the output buffer and returns the number read. @@ -380,7 +380,7 @@ without flushing the output buffer and returns the number read. always returns immediately without I/O if there are events already in the queue. -with mode +with mode QueuedAfterFlush is identical in behavior to . @@ -394,7 +394,7 @@ function. -To return the number of events that are pending, use +To return the number of events that are pending, use . XPending @@ -576,7 +576,7 @@ structure without removing it from the event queue. Each of the functions discussed in this section requires you to -pass a predicate procedure that determines if an event matches +pass a predicate procedure that determines if an event matches what you want. Your predicate procedure must decide if the event is useful without calling any Xlib functions. @@ -631,7 +631,7 @@ structure. -Specifies the argument passed in from the +Specifies the argument passed in from the , , or @@ -645,8 +645,8 @@ function. The predicate procedure is called once for each -event in the queue until it finds a match. -After finding a match, the predicate procedure must return +event in the queue until it finds a match. +After finding a match, the predicate procedure must return True. If it did not find a match, it must return False. @@ -719,14 +719,14 @@ Specifies the user-supplied argument that will be passed to the predicate proced The function completes only when the specified predicate -procedure returns +procedure returns True -for an event, +for an event, which indicates an event in the queue matches. flushes the output buffer if it blocks waiting for additional events. -removes the matching event from the queue +removes the matching event from the queue and copies the structure into the client-supplied XEvent structure. @@ -799,7 +799,7 @@ When the predicate procedure finds a match, copies the matched event into the client-supplied XEvent -structure and returns +structure and returns True. (This event is removed from the queue.) If the predicate procedure finds no match, @@ -877,7 +877,7 @@ Specifies the user-supplied argument that will be passed to the predicate proced The function returns only when the specified predicate -procedure returns +procedure returns True for an event. After the predicate procedure finds a match, @@ -896,7 +896,7 @@ flushes the output buffer if it blocks waiting for additional events. -The functions discussed in this section let you select events by window +The functions discussed in this section let you select events by window or event types, allowing you to process events out of order. @@ -985,7 +985,7 @@ use XCheckWindowEvent This function is similar to -except that it never blocks and it returns a +except that it never blocks and it returns a Bool indicating if the event was returned. @@ -1048,7 +1048,7 @@ Returns the matched event's associated structure. The -function searches the event queue and then the events available +function searches the event queue and then the events available on the server connection for the first event that matches the specified window and event mask. If it finds a match, @@ -1118,7 +1118,7 @@ Returns the matched event's associated structure. The -function searches the event queue for the events associated with the +function searches the event queue for the events associated with the specified mask. When it finds a match, @@ -1135,9 +1135,9 @@ flushes the output buffer and blocks until one is received. To return and remove the next event that matches an event mask (if any), use . -This function is similar to +This function is similar to -except that it never blocks and it returns a +except that it never blocks and it returns a Bool indicating if the event was returned. @@ -1259,7 +1259,7 @@ Returns the matched event's associated structure. The -function searches the event queue and then any events available +function searches the event queue and then any events available on the server connection for the first event that matches the specified type. If it finds a match, @@ -1277,7 +1277,7 @@ and the output buffer will have been flushed. -To return and remove the next event in the queue that matches an event type +To return and remove the next event in the queue that matches an event type and a window, use . @@ -1341,7 +1341,7 @@ Returns the matched event's associated structure. The -function searches the event queue and then any events available +function searches the event queue and then any events available on the server connection for the first event that matches the specified type and window. If it finds a match, @@ -1429,7 +1429,7 @@ For example, the owner of a selection should use to send a SelectionNotify -event to a requestor when a selection has been converted +event to a requestor when a selection has been converted and stored as a property. XSendEvent @@ -1505,8 +1505,8 @@ Specifies the event that is to be sent. The -function identifies the destination window, -determines which clients should receive the specified events, +function identifies the destination window, +determines which clients should receive the specified events, and ignores any active grabs. This function requires you to pass an event mask. For a discussion of the valid event mask names, @@ -1525,8 +1525,8 @@ the destination window is the window that contains the pointer. If w is InputFocus -and if the focus window contains the pointer, -the destination window is the window that contains the pointer; +and if the focus window contains the pointer, +the destination window is the window that contains the pointer; otherwise, the destination window is the focus window. @@ -1548,7 +1548,7 @@ no event is sent. -If propagate is +If propagate is False, the event is sent to every client selecting on destination any of the event types in the event_mask argument. @@ -1556,15 +1556,15 @@ types in the event_mask argument. -If propagate is +If propagate is True and no clients have selected on destination any of the event types in event-mask, the destination is replaced with the closest ancestor of destination for which some client has selected a type in event-mask and for which no intervening window has that type in its -do-not-propagate-mask. +do-not-propagate-mask. If no such window exists or if the window is -an ancestor of the focus window and +an ancestor of the focus window and InputFocus was originally specified as the destination, the event is not sent to any clients. @@ -1578,10 +1578,10 @@ destination any of the types specified in event_mask. The event in the XEvent structure must be one of the core events or one of the events -defined by an extension (or a +defined by an extension (or a BadValue -error results) so that the X server can correctly byte-swap -the contents as necessary. +error results) so that the X server can correctly byte-swap +the contents as necessary. The contents of the event are otherwise unaltered and unchecked by the X server except to force send_event to True @@ -1601,7 +1601,7 @@ and returns nonzero otherwise. can generate BadValue -and +and BadWindow errors. @@ -1620,13 +1620,13 @@ stored in a buffer for later retrieval. This buffer is called the motion history buffer. For example, a few applications, such as paint programs, want to have a precise history of where the pointer -traveled. +traveled. However, this historical information is highly excessive for most applications. -To determine the approximate maximum number of elements in the motion buffer, +To determine the approximate maximum number of elements in the motion buffer, use XDisplayMotionBufferSize. @@ -1746,9 +1746,9 @@ function returns all events in the motion history buffer that fall between the specified start and stop times, inclusive, and that have coordinates that lie within the specified window (including its borders) at its present placement. -If the server does not support motion history, +If the server does not support motion history, if the start time is later than the stop time, -or if the start time is in the future, +or if the start time is in the future, no events are returned; returns NULL. @@ -1772,7 +1772,7 @@ typedef struct { -The time member is set to the time, in milliseconds. +The time member is set to the time, in milliseconds. The x and y members are set to the coordinates of the pointer and are reported relative to the origin of the specified window. @@ -1804,15 +1804,15 @@ and to use the default error handlers. -When debugging X applications, +When debugging X applications, it often is very convenient to require Xlib to behave synchronously so that errors are reported as they occur. The following function lets you disable or enable synchronous behavior. -Note that graphics may occur 30 or more times more slowly when +Note that graphics may occur 30 or more times more slowly when synchronization is enabled. _Xdebug On POSIX-conformant systems, -there is also a global variable +there is also a global variable _Xdebug that, if set to nonzero before starting a program under a debugger, will force synchronous library behavior. @@ -1866,7 +1866,7 @@ returns the previous after function. -To enable or disable synchronization, use +To enable or disable synchronization, use XSynchronize. Debuggingsynchronous mode @@ -1897,7 +1897,7 @@ Specifies the connection to the X server. -Specifies a Boolean value that indicates whether to enable +Specifies a Boolean value that indicates whether to enable or disable synchronization. @@ -1908,9 +1908,9 @@ or disable synchronization. The XSynchronize -function returns +function returns the previous after function. -If onoff is +If onoff is True, XSynchronize turns on synchronous behavior. @@ -1929,9 +1929,9 @@ turns off synchronous behavior. Debuggingerror handlers Errorhandlers -There are two default error handlers in Xlib: -one to handle typically fatal conditions (for example, -the connection to a display server dying because a machine crashed) +There are two default error handlers in Xlib: +one to handle typically fatal conditions (for example, +the connection to a display server dying because a machine crashed) and one to handle protocol errors from the X server. These error handlers can be changed to user-supplied routines if you prefer your own error handling and can be changed as often as you like. @@ -1986,7 +1986,7 @@ errors from a protocol request. These errors generally are reflected back to the program through the procedural interface. -Because this condition is not assumed to be fatal, +Because this condition is not assumed to be fatal, it is acceptable for your error handler to return; the returned value is ignored. However, the error handler should not @@ -1996,7 +1996,7 @@ The previous error handler is returned. -The +The XErrorEvent structure contains: Debuggingerror event @@ -2021,13 +2021,13 @@ typedef struct { Serial Number -The serial member is the number of requests, starting from one, -sent over the network connection since it was opened. -It is the number that was the value of +The serial member is the number of requests, starting from one, +sent over the network connection since it was opened. +It is the number that was the value of NextRequest -immediately before the failing call was made. +immediately before the failing call was made. The request_code member is a protocol request -of the procedure that failed, as defined in +of the procedure that failed, as defined in <X11/Xproto.h>. The following error codes can be returned by the functions described in this chapter: @@ -2113,7 +2113,7 @@ chapter: BadGC A value for a GContext - argument does not name a defined + argument does not name a defined GContext. @@ -2192,7 +2192,7 @@ chapter: -The +The BadAtom, BadColor, BadCursor, @@ -2200,7 +2200,7 @@ The BadFont, BadGC, BadPixmap, -and +and BadWindow errors are also used when the argument type is extended by a set of fixed alternatives. @@ -2211,7 +2211,7 @@ fixed alternatives. -To obtain textual descriptions of the specified error code, use +To obtain textual descriptions of the specified error code, use . XGetErrorText @@ -2418,7 +2418,7 @@ the major request protocol number is used for the message argument. For an extension request, the extension name (as given by InitExtension) -followed by a period (.) and the minor request protocol number +followed by a period (.) and the minor request protocol number is used for the message argument. If no string is found in the error database, the default_string is returned to the buffer argument. @@ -2459,7 +2459,7 @@ Specifies the character string. The -function returns the name of the display that +function returns the name of the display that would attempt to use. If a NULL string is specified, diff --git a/specs/libX11/CH12.xml b/specs/libX11/CH12.xml index fee46f1f..2734f2ec 100644 --- a/specs/libX11/CH12.xml +++ b/specs/libX11/CH12.xml @@ -68,11 +68,11 @@ explicitly (see and ). Passive grab -A passive grab occurs when clients grab a particular keyboard key +A passive grab occurs when clients grab a particular keyboard key or pointer button in a window, and the grab will activate when the key or button is actually pressed. Passive grabs are convenient for implementing reliable pop-up menus. -For example, you can guarantee that the pop-up is mapped +For example, you can guarantee that the pop-up is mapped before the up pointer button event occurs by grabbing a button requesting synchronous behavior. The down event will trigger the grab and freeze further @@ -101,17 +101,17 @@ application may be slow reacting to an event. You often need some way to specify that your request should not occur if another application has in the meanwhile taken control of the keyboard, pointer, or selection. -By providing the timestamp from the event in the request, +By providing the timestamp from the event in the request, you can arrange that the operation not take effect if someone else has performed an operation in the meanwhile. -A timestamp is a time value, expressed in milliseconds. +A timestamp is a time value, expressed in milliseconds. It typically is the time since the last server reset. Timestamp values wrap around (after about 49.7 days). -The server, given its current time is represented by timestamp T, -always interprets timestamps from clients by treating half of the timestamp +The server, given its current time is represented by timestamp T, +always interprets timestamps from clients by treating half of the timestamp space as being later in time than T. One timestamp value, named CurrentTime, @@ -202,8 +202,8 @@ Specifies the grab window. -Specifies a Boolean value that indicates whether the pointer -events are to be reported as usual or reported with respect to the grab window +Specifies a Boolean value that indicates whether the pointer +events are to be reported as usual or reported with respect to the grab window if selected by the event mask. @@ -226,7 +226,7 @@ The mask is the bitwise inclusive OR of the valid pointer event mask bits. Specifies further processing of pointer events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -240,7 +240,7 @@ or Specifies further processing of keyboard events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -293,33 +293,33 @@ if the grab was successful. Further pointer events are reported only to the grabbing client. overrides any active pointer grab by this client. -If owner_events is +If owner_events is False, all generated pointer events are reported with respect to grab_window and are reported only if selected by event_mask. -If owner_events is +If owner_events is True and if a generated -pointer event would normally be reported to this client, -it is reported as usual. +pointer event would normally be reported to this client, +it is reported as usual. Otherwise, the event is reported with respect to the grab_window and is reported only if selected by event_mask. For either value of owner_events, unreported events are discarded. -If the pointer_mode is +If the pointer_mode is GrabModeAsync, pointer event processing continues as usual. -If the pointer is currently frozen by this client, +If the pointer is currently frozen by this client, the processing of events for the pointer is resumed. -If the pointer_mode is +If the pointer_mode is GrabModeSync, the state of the pointer, as seen by client applications, appears to freeze, and the X server generates no further pointer events -until the grabbing client calls +until the grabbing client calls or until the pointer grab is released. Actual pointer changes are not lost while the pointer is frozen; @@ -327,15 +327,15 @@ they are simply queued in the server for later processing. -If the keyboard_mode is +If the keyboard_mode is GrabModeAsync, keyboard event processing is unaffected by activation of the grab. -If the keyboard_mode is +If the keyboard_mode is GrabModeSync, the state of the keyboard, as seen by client applications, appears to freeze, and the X server generates no further keyboard events -until the grabbing client calls +until the grabbing client calls or until the pointer grab is released. Actual keyboard changes are not lost while the pointer is frozen; @@ -344,8 +344,8 @@ they are simply queued in the server for later processing. If a cursor is specified, it is displayed regardless of what -window the pointer is in. -If +window the pointer is in. +If None is specified, the normal cursor for that window is displayed @@ -357,11 +357,11 @@ otherwise, the cursor for grab_window is displayed. If a confine_to window is specified, the pointer is restricted to stay contained in that window. The confine_to window need have no relationship to the grab_window. -If the pointer is not initially in the confine_to window, -it is warped automatically to the closest edge -just before the grab activates and enter/leave events are generated as usual. -If the confine_to window is subsequently reconfigured, -the pointer is warped automatically, as necessary, +If the pointer is not initially in the confine_to window, +it is warped automatically to the closest edge +just before the grab activates and enter/leave events are generated as usual. +If the confine_to window is subsequently reconfigured, +the pointer is warped automatically, as necessary, to keep it contained in the window. @@ -371,10 +371,10 @@ if applications take a long time to respond or if there are long network delays. Consider a situation where you have two applications, both of which normally grab the pointer when clicked on. -If both applications specify the timestamp from the event, +If both applications specify the timestamp from the event, the second application may wake up faster and successfully grab the pointer -before the first application. -The first application then will get an indication that the other application +before the first application. +The first application then will get an indication that the other application grabbed the pointer before its request was processed. @@ -400,7 +400,7 @@ it fails and returns If the pointer is frozen by an active grab of another client, it fails and returns GrabFrozen. -If the specified time is earlier than the last-pointer-grab time or later +If the specified time is earlier than the last-pointer-grab time or later than the current X server time, it fails and returns GrabInvalidTime. Otherwise, the last-pointer-grab time is set to the specified time @@ -473,14 +473,14 @@ or from a normal button press. does not release the pointer if the specified time is earlier than the last-pointer-grab time or is later than the current X server time. -It also generates +It also generates EnterNotify -and +and LeaveNotify events. -The X server performs an +The X server performs an UngrabPointer -request automatically if the event window or confine_to window +request automatically if the event window or confine_to window for an active pointer grab becomes not viewable or if window reconfiguration causes the confine_to window to lie completely outside the boundaries of the root window. @@ -649,8 +649,8 @@ Specifies the grab window. -Specifies a Boolean value that indicates whether the pointer -events are to be reported as usual or reported with respect to the grab window +Specifies a Boolean value that indicates whether the pointer +events are to be reported as usual or reported with respect to the grab window if selected by the event mask. @@ -673,7 +673,7 @@ The mask is the bitwise inclusive OR of the valid pointer event mask bits. Specifies further processing of pointer events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -687,7 +687,7 @@ or Specifies further processing of keyboard events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -775,13 +775,13 @@ may lag the physical state if device event processing is frozen. This request overrides all previous grabs by the same client on the same button/key combinations on the same window. -A modifiers of +A modifiers of AnyModifier is equivalent to issuing the grab request for all -possible modifier combinations (including the combination of no modifiers). -It is not required that all modifiers specified have currently assigned +possible modifier combinations (including the combination of no modifiers). +It is not required that all modifiers specified have currently assigned KeyCodes. -A button of +A button of AnyButton is equivalent to issuing the request for all possible buttons. @@ -795,9 +795,9 @@ If some other client has already issued an with the same button/key combination on the same window, a BadAccess error results. -When using +When using AnyModifier -or +or AnyButton, the request fails completely, and a @@ -889,13 +889,13 @@ The function releases the passive button/key combination on the specified window if it was grabbed by this client. -A modifiers of +A modifiers of AnyModifier is -equivalent to issuing -the ungrab request for all possible modifier combinations, including +equivalent to issuing +the ungrab request for all possible modifier combinations, including the combination of no modifiers. -A button of +A button of AnyButton is equivalent to issuing the request for all possible buttons. @@ -986,7 +986,7 @@ Specifies the grab window. -Specifies a Boolean value that indicates whether the keyboard events +Specifies a Boolean value that indicates whether the keyboard events are to be reported as usual. @@ -998,7 +998,7 @@ are to be reported as usual. Specifies further processing of pointer events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -1012,7 +1012,7 @@ or Specifies further processing of keyboard events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -1046,55 +1046,55 @@ Further key events are reported only to the grabbing client. overrides any active keyboard grab by this client. -If owner_events is +If owner_events is False, all generated key events are reported with -respect to grab_window. -If owner_events is +respect to grab_window. +If owner_events is True and if a generated key event would normally be reported to this client, it is reported normally; otherwise, the event is reported with respect to the -grab_window. -Both +grab_window. +Both KeyPress -and +and KeyRelease events are always reported, independent of any event selection made by the client. -If the keyboard_mode argument is +If the keyboard_mode argument is GrabModeAsync, keyboard event processing continues -as usual. -If the keyboard is currently frozen by this client, +as usual. +If the keyboard is currently frozen by this client, then processing of keyboard events is resumed. If the keyboard_mode argument is GrabModeSync, the state of the keyboard (as seen by client applications) appears to freeze, and the X server generates no further keyboard events until the -grabbing client issues a releasing +grabbing client issues a releasing call or until the keyboard grab is released. -Actual keyboard changes are not lost while the keyboard is frozen; +Actual keyboard changes are not lost while the keyboard is frozen; they are simply queued in the server for later processing. -If pointer_mode is +If pointer_mode is GrabModeAsync, pointer event processing is unaffected -by activation of the grab. -If pointer_mode is +by activation of the grab. +If pointer_mode is GrabModeSync, -the state of the pointer (as seen by client applications) appears to freeze, -and the X server generates no further pointer events -until the grabbing client issues a releasing +the state of the pointer (as seen by client applications) appears to freeze, +and the X server generates no further pointer events +until the grabbing client issues a releasing call or until the keyboard grab is released. -Actual pointer changes are not lost while the pointer is frozen; +Actual pointer changes are not lost while the pointer is frozen; they are simply queued in the server for later processing. @@ -1109,7 +1109,7 @@ it fails and returns If the keyboard is frozen by an active grab of another client, it fails and returns GrabFrozen. -If the specified time is earlier than the last-keyboard-grab time +If the specified time is earlier than the last-keyboard-grab time or later than the current X server time, it fails and returns GrabInvalidTime. @@ -1122,7 +1122,7 @@ is replaced by the current X server time). can generate BadValue -and +and BadWindow errors. @@ -1185,10 +1185,10 @@ if the specified time is earlier than the last-keyboard-grab time or is later than the current X server time. It also generates FocusIn -and +and FocusOut events. -The X server automatically performs an +The X server automatically performs an UngrabKeyboard request if the event window for an active keyboard grab becomes not viewable. @@ -1266,7 +1266,7 @@ Specifies the grab window. -Specifies a Boolean value that indicates whether the keyboard events +Specifies a Boolean value that indicates whether the keyboard events are to be reported as usual. @@ -1278,7 +1278,7 @@ are to be reported as usual. Specifies further processing of pointer events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -1292,7 +1292,7 @@ or Specifies further processing of keyboard events. -You can pass +You can pass GrabModeSync or GrabModeAsync. @@ -1340,7 +1340,7 @@ on any ancestor of grab_window. -The interpretation of the remaining arguments is as for +The interpretation of the remaining arguments is as for . The active grab is terminated automatically when the logical state of the keyboard has the specified key released @@ -1353,39 +1353,39 @@ may lag the physical state if device event processing is frozen. -A modifiers argument of +A modifiers argument of AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no -modifiers). +modifiers). It is not required that all modifiers specified have currently assigned KeyCodes. -A keycode argument of +A keycode argument of AnyKey is equivalent to issuing the request for all possible KeyCodes. Otherwise, the specified keycode must be in the range specified by min_keycode and max_keycode in the connection -setup, +setup, or a BadValue error results. -If some other client has issued a +If some other client has issued a -with the same key combination on the same window, a +with the same key combination on the same window, a BadAccess error results. When using AnyModifier -or +or AnyKey, the request fails completely, and a BadAccess -error results (no grabs are established) +error results (no grabs are established) if there is a conflicting grab for any combination. @@ -1536,7 +1536,7 @@ Specifies the connection to the X server. Specifies the event mode. -You can pass +You can pass AsyncPointer, SyncPointer, AsyncKeyboard, @@ -1567,7 +1567,7 @@ You can pass either a timestamp or The -function releases some queued events if the client has caused a device +function releases some queued events if the client has caused a device to freeze. It has no effect if the specified time is earlier than the last-grab time of the most recent active grab for the client or if the specified time @@ -1616,10 +1616,10 @@ Depending on the event_mode argument, the following occurs: with mode SyncPointer - but not from an + but not from an ), the pointer grab is released and that event is completely reprocessed. - This time, however, the function ignores any passive grabs at or above + This time, however, the function ignores any passive grabs at or above (toward the root of) the grab_window of the grab just released. The request has no effect if the pointer is not grabbed by the client or if the pointer is not frozen as the result of an event. @@ -1661,7 +1661,7 @@ Depending on the event_mode argument, the following occurs: with mode SyncKeyboard - but not from an + but not from an ), the keyboard grab is released and that event is completely reprocessed. This time, however, the function ignores any passive grabs at or above @@ -1677,22 +1677,22 @@ Depending on the event_mode argument, the following occurs: ButtonPress, ButtonRelease, KeyPress, - or + or KeyRelease - event is reported to the client for a grabbed device - (button event for the pointer, key event for the keyboard), - at which time the devices again appear to freeze. + event is reported to the client for a grabbed device + (button event for the pointer, key event for the keyboard), + at which time the devices again appear to freeze. However, if the reported event causes the grab to be released, then the devices do not freeze (but if the other device is still grabbed, then a subsequent event for it will still cause both devices - to freeze). + to freeze). SyncBoth has no effect unless both pointer and keyboard are frozen by the client. If the pointer or keyboard is frozen twice - by the client on behalf of two separate grabs, + by the client on behalf of two separate grabs, SyncBoth - thaws for both (but a subsequent freeze for + thaws for both (but a subsequent freeze for SyncBoth will only freeze each device once). @@ -1715,23 +1715,23 @@ Depending on the event_mode argument, the following occurs: AsyncPointer, SyncPointer, -and +and ReplayPointer have no effect on the processing of keyboard events. AsyncKeyboard, SyncKeyboard, -and +and ReplayKeyboard have no effect on the processing of pointer events. -It is possible for both a pointer grab and a keyboard grab (by the same +It is possible for both a pointer grab and a keyboard grab (by the same or different clients) to be active simultaneously. If a device is frozen on behalf of either grab, no event processing is performed for the device. It is possible for a single device to be frozen because of both grabs. In this case, -the freeze must be released on behalf of both grabs before events can +the freeze must be released on behalf of both grabs before events can again be processed. If a device is frozen twice by a single client, then a single @@ -1891,7 +1891,7 @@ If dest_w is a window, moves the pointer to the offsets (dest_x, dest_y) relative to the origin of dest_w. However, if src_w is a window, -the move only takes place if the window src_w contains the pointer +the move only takes place if the window src_w contains the pointer and if the specified rectangle of src_w contains the pointer. @@ -1904,7 +1904,7 @@ it is replaced with the current width of src_w minus src_x. -There is seldom any reason for calling this function. +There is seldom any reason for calling this function. The pointer should normally be left to the user. If you do use this function, however, it generates events just as if the user had instantaneously moved the pointer from one position to another. @@ -1912,7 +1912,7 @@ Note that you cannot use to move the pointer outside the confine_to window of an active pointer grab. An attempt to do so will only move the pointer as far as the closest edge of the -confine_to window. +confine_to window. @@ -1985,10 +1985,10 @@ or Specifies where the input focus reverts to if the window becomes not viewable. -You can pass +You can pass RevertToParent, RevertToPointerRoot, -or +or RevertToNone. @@ -2020,14 +2020,14 @@ is replaced by the current X server time). causes the X server to generate FocusIn -and +and FocusOut events. Depending on the focus argument, -the following occurs: +the following occurs: @@ -2040,10 +2040,10 @@ and the revert_to argument is ignored. -If focus is a window, +If focus is a window, it becomes the keyboard's focus window. If a generated keyboard event would normally be reported to this window -or one of its inferiors, the event is reported as usual. +or one of its inferiors, the event is reported as usual. Otherwise, the event is reported relative to the focus window. @@ -2051,30 +2051,30 @@ Otherwise, the event is reported relative to the focus window. If focus is PointerRoot, -the focus window is dynamically taken to be the root window of whatever screen -the pointer is on at each keyboard event. +the focus window is dynamically taken to be the root window of whatever screen +the pointer is on at each keyboard event. In this case, the revert_to argument is ignored. -The specified focus window must be viewable at the time +The specified focus window must be viewable at the time is called, or a BadMatch error results. -If the focus window later becomes not viewable, +If the focus window later becomes not viewable, the X server -evaluates the revert_to argument to determine the new focus window as follows: +evaluates the revert_to argument to determine the new focus window as follows: If revert_to is RevertToParent, -the focus reverts to the parent (or the closest viewable ancestor), +the focus reverts to the parent (or the closest viewable ancestor), and the new revert_to value is taken to be RevertToNone. @@ -2083,7 +2083,7 @@ and the new revert_to value is taken to be If revert_to is RevertToPointerRoot -or +or RevertToNone, the focus reverts to PointerRoot @@ -2145,7 +2145,7 @@ Specifies the connection to the X server. Returns the focus window, PointerRoot, -or +or None. @@ -2159,7 +2159,7 @@ or Returns the current focus state (RevertToParent, RevertToPointerRoot, -or +or RevertToNone). @@ -2182,8 +2182,8 @@ function returns the focus window and the current focus state. Xlib provides functions that you can use to change the keyboard control, obtain a list of the auto-repeat keys, -turn keyboard auto-repeat on or off, ring the bell, -set or obtain the pointer button or keyboard mapping, +turn keyboard auto-repeat on or off, ring the bell, +set or obtain the pointer button or keyboard mapping, and obtain a bit vector for the keyboard. @@ -2192,7 +2192,7 @@ and obtain a bit vector for the keyboard. Keyboardkeyclick volume Keyboardbit vector Mouseprogramming -This section discusses +This section discusses the user-preference options of bell, key click, pointer behavior, and so on. The default values for many of these options are server dependent. @@ -2241,8 +2241,8 @@ int auto_repeat_mode; /* AutoRepeatModeOff, AutoRepeatModeOn, -The key_click_percent member sets the volume for key clicks between 0 (off) -and 100 (loud) inclusive, if possible. +The key_click_percent member sets the volume for key clicks between 0 (off) +and 100 (loud) inclusive, if possible. A setting of -1 restores the default. Other negative values generate a BadValue @@ -2251,7 +2251,7 @@ error. The bell_percent sets the base volume for the bell between 0 (off) and 100 -(loud) inclusive, if possible. +(loud) inclusive, if possible. A setting of -1 restores the default. Other negative values generate a BadValue @@ -2262,7 +2262,7 @@ Other negative values generate a BadValue error. The bell_duration member sets the duration of the -bell specified in milliseconds, if possible. +bell specified in milliseconds, if possible. A setting of -1 restores the default. Other negative values generate a BadValue @@ -2271,22 +2271,22 @@ error. If both the led_mode and led members are specified, -the state of that LED is changed, if possible. +the state of that LED is changed, if possible. The led_mode member can be set to LedModeOn or LedModeOff. If only led_mode is specified, the state of -all LEDs are changed, if possible. -At most 32 LEDs numbered from one are supported. +all LEDs are changed, if possible. +At most 32 LEDs numbered from one are supported. No standard interpretation of LEDs is defined. If led is specified without led_mode, a BadMatch -error results. +error results. -If both the auto_repeat_mode and key members are specified, +If both the auto_repeat_mode and key members are specified, the auto_repeat_mode of that key is changed (according to AutoRepeatModeOn, AutoRepeatModeOff, @@ -2463,7 +2463,7 @@ typedef struct { -For the LEDs, +For the LEDs, the least significant bit of led_mask corresponds to LED one, and each bit set to 1 in led_mask indicates an LED that is lit. The global_auto_repeat member can be set to @@ -2471,9 +2471,9 @@ The global_auto_repeat member can be set to or AutoRepeatModeOff. The auto_repeats member is a bit vector. -Each bit set to 1 indicates that auto-repeat is enabled +Each bit set to 1 indicates that auto-repeat is enabled for the corresponding key. -The vector is represented as 32 bytes. +The vector is represented as 32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N + 7 with the least significant bit in the byte representing key 8N. @@ -2579,7 +2579,7 @@ Specifies the connection to the X server. Specifies the volume for the bell, -which can range from -100 to 100 inclusive. +which can range from -100 to 100 inclusive. @@ -2673,11 +2673,11 @@ Each bit represents one key of the keyboard. The -function returns a bit vector for the logical state of the keyboard, -where each bit set to 1 indicates that the corresponding key is currently +function returns a bit vector for the logical state of the keyboard, +where each bit set to 1 indicates that the corresponding key is currently pressed down. The vector is represented as 32 bytes. -Byte N (from 0) contains the bits for keys 8N to 8N + 7 +Byte N (from 0) contains the bits for keys 8N to 8N + 7 with the least significant bit in the byte representing key 8N. @@ -2833,7 +2833,7 @@ Pointer buttons are numbered starting from one. returns the number of physical buttons actually on the pointer. The nominal mapping for a pointer is map[i]=i+1. The nmap argument specifies the length of the array where the pointer -mapping is returned, and only the first nmap elements are returned +mapping is returned, and only the first nmap elements are returned in map_return. @@ -2873,7 +2873,7 @@ Specifies the connection to the X server. -Specifies a Boolean value that controls whether the values for +Specifies a Boolean value that controls whether the values for the accel_numerator or accel_denominator are used. @@ -2884,7 +2884,7 @@ the accel_numerator or accel_denominator are used. -Specifies a Boolean value that controls whether the value for the +Specifies a Boolean value that controls whether the value for the threshold is used. @@ -2927,15 +2927,15 @@ The function defines how the pointing device moves. The acceleration, expressed as a fraction, is a -multiplier for movement. +multiplier for movement. For example, specifying 3/1 means the pointer moves three times as fast as normal. -The fraction may be rounded arbitrarily by the X server. +The fraction may be rounded arbitrarily by the X server. Acceleration only takes effect if the pointer moves more than threshold pixels at once and only applies to the amount beyond the value in the threshold argument. Setting a value to -1 restores the default. -The values of the do_accel and do_threshold arguments must be +The values of the do_accel and do_threshold arguments must be True for the pointer values to be set, or the parameters are unchanged. @@ -3027,24 +3027,24 @@ and acceleration threshold. -A KeyCode represents a physical (or logical) key. -KeyCodes lie in the inclusive range [8,255]. +A KeyCode represents a physical (or logical) key. +KeyCodes lie in the inclusive range [8,255]. A KeyCode value carries no intrinsic information, -although server implementors may attempt to encode geometry +although server implementors may attempt to encode geometry (for example, matrix) information in some fashion so that it can be interpreted in a server-dependent fashion. The mapping between keys and KeyCodes cannot be changed. -A KeySym is an encoding of a symbol on the cap of a key. -The set of defined KeySyms includes the ISO Latin character sets (1-4), +A KeySym is an encoding of a symbol on the cap of a key. +The set of defined KeySyms includes the ISO Latin character sets (1-4), Katakana, Arabic, Cyrillic, Greek, Technical, Special, Publishing, APL, Hebrew, Thai, Korean and a miscellany of keys found -on keyboards (Return, Help, Tab, and so on). +on keyboards (Return, Help, Tab, and so on). To the extent possible, these sets are derived from international -standards. +standards. In areas where no standards exist, some of these sets are derived from Digital Equipment Corporation standards. The list of defined symbols can be found in @@ -3057,7 +3057,7 @@ limits on the number of defined symbols. If you must use KeySyms not in the Latin 1-4, Greek, and miscellaneous classes, you may have to define a symbol for those sets. -Most applications usually only include +Most applications usually only include <X11/keysym.h>, X11/keysym.h Files<X11/keysym.h> @@ -3070,9 +3070,9 @@ A list of KeySyms is associated with each KeyCode. The list is intended to convey the set of symbols on the corresponding key. If the list (ignoring trailing NoSymbol -entries) is +entries) is a single KeySym ``K'', -then the list is treated as if it were the list +then the list is treated as if it were the list ``K NoSymbol K NoSymbol''. If the list (ignoring trailing NoSymbol @@ -3095,13 +3095,13 @@ Group 2 contains the third and fourth KeySyms. Within each group, if the second element of the group is NoSymbol, -then the group should be treated as if the second element were +then the group should be treated as if the second element were the same as the first element, -except when the first element is an alphabetic KeySym ``K'' +except when the first element is an alphabetic KeySym ``K'' for which both lowercase and uppercase forms are defined. In that case, -the group should be treated as if the first element were -the lowercase form of ``K'' and the second element were +the group should be treated as if the first element were +the lowercase form of ``K'' and the second element were the uppercase form of ``K''. @@ -3112,7 +3112,7 @@ event make use of only the Group 1 and Group 2 KeySyms; no interpretation of other KeySyms in the list is given. Which group to use is determined by the modifier state. Switching between groups is controlled by the KeySym named MODE SWITCH, -by attaching that KeySym to some KeyCode and attaching +by attaching that KeySym to some KeyCode and attaching that KeyCode to any one of the modifiers Mod1 through @@ -3221,7 +3221,7 @@ as ShiftLock, or both. In this case, the second KeySym is used. No spatial geometry of the symbols on the key is defined by -their order in the KeySym list, +their order in the KeySym list, although a geometry might be defined on a server-specific basis. The X server does not use the mapping between KeyCodes and KeySyms. @@ -3354,13 +3354,13 @@ The function returns the symbols for the specified number of KeyCodes starting with first_keycode. -The value specified in first_keycode must be greater than +The value specified in first_keycode must be greater than or equal to min_keycode as returned by , or a BadValue error results. -In addition, the following expression must be less than or equal +In addition, the following expression must be less than or equal to max_keycode as returned by : @@ -3372,9 +3372,9 @@ first_keycode + keycode_count - 1 -If this is not the case, a +If this is not the case, a BadValue -error results. +error results. The number of elements in the KeySyms list is: @@ -3386,20 +3386,20 @@ keycode_count * keysyms_per_keycode_return KeySym number N, counting from zero, for KeyCode K has the following index -in the list, counting from zero: +in the list, counting from zero: (K - first_code) * keysyms_per_code_return + N -The X server arbitrarily chooses the keysyms_per_keycode_return value -to be large enough to report all requested symbols. -A special KeySym value of +The X server arbitrarily chooses the keysyms_per_keycode_return value +to be large enough to report all requested symbols. +A special KeySym value of NoSymbol is used to fill in unused elements for individual KeyCodes. -To free the storage returned by +To free the storage returned by , use . @@ -3489,7 +3489,7 @@ The function defines the symbols for the specified number of KeyCodes starting with first_keycode. -The symbols for KeyCodes outside this range remain unchanged. +The symbols for KeyCodes outside this range remain unchanged. The number of elements in keysyms must be: @@ -3500,13 +3500,13 @@ num_codes * keysyms_per_keycode -The specified first_keycode must be greater than or equal to min_keycode +The specified first_keycode must be greater than or equal to min_keycode returned by , -or a +or a BadValue error results. -In addition, the following expression must be less than or equal to +In addition, the following expression must be less than or equal to max_keycode as returned by , or a @@ -3522,7 +3522,7 @@ first_keycode + num_codes - 1 KeySym number N, counting from zero, for KeyCode K has the following index -in keysyms, counting from zero: +in keysyms, counting from zero: @@ -3533,23 +3533,23 @@ in keysyms, counting from zero: The specified keysyms_per_keycode can be chosen arbitrarily by the client -to be large enough to hold all desired symbols. -A special KeySym value of +to be large enough to hold all desired symbols. +A special KeySym value of NoSymbol -should be used to fill in unused elements -for individual KeyCodes. -It is legal for +should be used to fill in unused elements +for individual KeyCodes. +It is legal for NoSymbol to appear in nontrailing positions of the effective list for a KeyCode. -generates a +generates a MappingNotify event. -There is no requirement that the X server interpret this mapping. +There is no requirement that the X server interpret this mapping. It is merely stored for reading and writing by clients. @@ -3563,7 +3563,7 @@ errors. -The next six functions make use of the +The next six functions make use of the XModifierKeymap data structure, which contains: @@ -3622,7 +3622,7 @@ structure for later use. -To add a new entry to an +To add a new entry to an XModifierKeymap structure, use . @@ -3645,7 +3645,7 @@ structure, use -Specifies the +Specifies the XModifierKeymap structure. @@ -3657,7 +3657,7 @@ structure. -Specifies the KeyCode. +Specifies the KeyCode. @@ -3685,7 +3685,7 @@ structure (expanded as needed). -To delete an entry from an +To delete an entry from an XModifierKeymap structure, use . @@ -3708,7 +3708,7 @@ structure, use -Specifies the +Specifies the XModifierKeymap structure. @@ -3720,7 +3720,7 @@ structure. -Specifies the KeyCode. +Specifies the KeyCode. @@ -3769,7 +3769,7 @@ structure, use -Specifies the +Specifies the XModifierKeymap structure. @@ -3818,7 +3818,7 @@ Specifies the connection to the X server. -Specifies the +Specifies the XModifierKeymap structure. @@ -3830,7 +3830,7 @@ structure. The -function specifies the KeyCodes of the keys (if any) that are to be used +function specifies the KeyCodes of the keys (if any) that are to be used as modifiers. If it succeeds, the X server generates a @@ -3848,10 +3848,10 @@ error results. -The modifiermap member of the +The modifiermap member of the XModifierKeymap -structure contains 8 sets of max_keypermod KeyCodes, -one for each modifier in the order +structure contains 8 sets of max_keypermod KeyCodes, +one for each modifier in the order Shift, Lock, Control, @@ -3859,32 +3859,32 @@ one for each modifier in the order Mod2, Mod3, Mod4, -and +and Mod5. -Only nonzero KeyCodes have meaning in each set, +Only nonzero KeyCodes have meaning in each set, and zero KeyCodes are ignored. -In addition, all of the nonzero KeyCodes must be in the range specified by -min_keycode and max_keycode in the +In addition, all of the nonzero KeyCodes must be in the range specified by +min_keycode and max_keycode in the Display structure, -or a +or a BadValue error results. -An X server can impose restrictions on how modifiers can be changed, +An X server can impose restrictions on how modifiers can be changed, for example, if certain keys do not generate up transitions in hardware, if auto-repeat cannot be disabled on certain keys, -or if multiple modifier keys are not supported. -If some such restriction is violated, +or if multiple modifier keys are not supported. +If some such restriction is violated, the status reply is MappingFailed, and none of the modifiers are changed. If the new KeyCodes specified for a modifier differ from those currently defined and any (current or new) keys for that modifier are -in the logically down state, +in the logically down state, returns MappingBusy, @@ -3895,7 +3895,7 @@ and none of the modifiers is changed. can generate BadAlloc -and +and BadValue errors. @@ -3936,7 +3936,7 @@ function returns a pointer to a newly created structure that contains the keys being used as modifiers. The structure should be freed after use by calling . -If only zero values appear in the set for any modifier, +If only zero values appear in the set for any modifier, that modifier is disabled. diff --git a/specs/libX11/CH13.xml b/specs/libX11/CH13.xml index 6be4f1c2..ebd3d103 100644 --- a/specs/libX11/CH13.xml +++ b/specs/libX11/CH13.xml @@ -83,7 +83,7 @@ mechanisms for announcing the locale in addition to -On implementations that do not conform to the ANSI C library, +On implementations that do not conform to the ANSI C library, the locale announcement method is Xlib implementation-dependent. @@ -109,16 +109,16 @@ To determine if the current locale is supported by X, use -The +The XSupportsLocale -function returns +function returns True if Xlib functions are capable of operating under the current locale. -If it returns +If it returns False, -Xlib locale-dependent functions for which the +Xlib locale-dependent functions for which the XLocaleNotSupported -return status is defined will return +return status is defined will return XLocaleNotSupported. Other Xlib locale-dependent routines will operate in the ``C'' locale. @@ -127,12 +127,12 @@ Other Xlib locale-dependent routines will operate in the ``C'' locale. The client is responsible for selecting its locale and X modifiers. Clients should provide a means for the user to override the clients' locale selection at client invocation. -Most single-display X clients operate in a single locale +Most single-display X clients operate in a single locale for both X and the host processing environment. -They will configure the locale by calling three functions: +They will configure the locale by calling three functions: the host locale configuration function, XSupportsLocale, -and +and . @@ -179,7 +179,7 @@ function sets the X modifiers for the current locale setting. The modifier_list argument is a null-terminated string of the form ``{@category=value}'', that is, having zero or more concatenated ``@category=value'' -entries, where category is a category name +entries, where category is a category name and value is the (possibly empty) setting for that category. The values are encoded in the current locale. Category names are restricted to the POSIX Portable Filename Character Set. @@ -451,7 +451,7 @@ the following table describes the locale (and modifiers) dependency: -Clients may assume that a locale-encoded text string returned +Clients may assume that a locale-encoded text string returned by an X function can be passed to a C library routine, or vice versa, if the locale is the same at the two calls. @@ -465,16 +465,16 @@ is state-dependent. All Xlib functions behave as if they do not change the current locale or X modifier setting. -(This means that if they do change locale or call +(This means that if they do change locale or call with a non-NULL argument, they must save and restore the current state on entry and exit.) Also, Xlib functions on implementations that conform to the ANSI C library do -not alter the global state associated with the ANSI C functions +not alter the global state associated with the ANSI C functions mblen, mbtowc, wctomb, -and +and strtok. @@ -487,19 +487,19 @@ and Various functions in this chapter have arguments that conform to the ANSI C variable argument list calling convention. -Each function denoted with an argument of the form ``...'' takes +Each function denoted with an argument of the form ``...'' takes a variable-length list of name and value pairs, -where each name is a string and each value is of type +where each name is a string and each value is of type XPointer. -A name argument that is NULL identifies the end of the list. +A name argument that is NULL identifies the end of the list. A variable-length argument list may contain a nested list. -If the name +If the name XNVaNestedList is specified in place of an argument name, -then the following value is interpreted as an +then the following value is interpreted as an XVaNestedList value that specifies a list of values logically inserted into the original list at the point of declaration. @@ -675,16 +675,16 @@ the output method for clients. The abstraction used to communicate with an output method -is an opaque data structure represented by the +is an opaque data structure represented by the XOM data type. The abstraction for representing the state of a particular output thread is called an output context. -The Xlib representation of an output context is an +The Xlib representation of an output context is an XOC, -which is compatible with +which is compatible with XFontSet -in terms of its functional interface, but is +in terms of its functional interface, but is a broader, more generalized abstraction. @@ -772,7 +772,7 @@ is identified on the basis of the current locale and modifiers. will identify a default output method corresponding to the current locale. -That default can be modified using +That default can be modified using to set the output method modifier. @@ -787,8 +787,8 @@ no database is passed to the output method. -The res_name and res_class arguments specify the resource name -and class of the application. +The res_name and res_class arguments specify the resource name +and class of the application. They are intended to be used as prefixes by the output method when looking up resources that are common to all output contexts that may be created for this output method. @@ -847,7 +847,7 @@ function closes the specified output method. -To set output method attributes, use +To set output method attributes, use . XSetOMValues @@ -900,7 +900,7 @@ No standard arguments are currently defined by Xlib. -To query an output method, use +To query an output method, use . XGetOMValues @@ -1133,9 +1133,9 @@ charset names. The required charset list is owned by Xlib and should not be modified or freed by the client. -It will be freed by a call to +It will be freed by a call to -with the associated +with the associated XOM. Until freed, its contents will not be modified by Xlib. @@ -1177,7 +1177,7 @@ typedef struct { typedef enum { XOMOrientation_LTR_TTB, - XOMOrientation_RTL_TTB, + XOMOrientation_RTL_TTB, XOMOrientation_TTB_LTR, XOMOrientation_TTB_RTL, XOMOrientation_Context @@ -1528,7 +1528,7 @@ values. The -function returns NULL if no error occurred; +function returns NULL if no error occurred; otherwise, it returns the name of the first argument that could not be set. An argument might not be set for any of the following reasons: @@ -1836,7 +1836,7 @@ may be able to remap a required charset. The missing charset list is owned by Xlib and should not be modified or freed by the client. -It will be freed by a call to +It will be freed by a call to with the associated XOC. @@ -1904,19 +1904,19 @@ The value of the argument is of type XOrientation. When XNOrientation -is queried, the value specifies the current orientation. +is queried, the value specifies the current orientation. When XNOrientation is set, a value is used to set the current orientation. -When +When XOMOrientation_Context -is set, the text orientation of the +is set, the text orientation of the text is determined according to an implementation-defined method (for example, ISO 6429 control sequences), and the initial text orientation for -locale-dependent Xlib functions is assumed to +locale-dependent Xlib functions is assumed to be XOMOrientation_LTR_TTB. @@ -1924,8 +1924,8 @@ be The XNOrientation -value does not change the prime drawing direction -for Xlib drawing functions. +value does not change the prime drawing direction +for Xlib drawing functions. @@ -1980,7 +1980,7 @@ Until freed, the string contents will not be modified by Xlib. The XNFontInfo -argument specifies a list of one or more +argument specifies a list of one or more XFontStruct structures and font names for the fonts used for drawing by the given output context. @@ -2017,32 +2017,32 @@ structures and font names is returned to num_font. Because it is not guaranteed that a given character will be imaged using a single font glyph, -there is no provision for mapping a character or default string -to the font properties, font ID, or direction hint for the font +there is no provision for mapping a character or default string +to the font properties, font ID, or direction hint for the font for the character. -The client may access the +The client may access the XFontStruct list to obtain these values for all the fonts currently in use. Xlib does not guarantee that fonts are loaded from the server -at the creation of an +at the creation of an XOC. -Xlib may choose to cache font data, loading it only as needed to draw text +Xlib may choose to cache font data, loading it only as needed to draw text or compute text dimensions. -Therefore, existence of the per_char metrics in the +Therefore, existence of the per_char metrics in the XFontStruct structures in the XFontStructSet is undefined. -Also, note that all properties in the +Also, note that all properties in the XFontStruct structures are in the STRING encoding. -The client must not free the +The client must not free the XOMFontInfo struct itself; it will be freed when the XOC @@ -2065,16 +2065,16 @@ or not. Because the function not only destroys the output context but also closes the implicit output method associated with it, -should be used with any output context created by +should be used with any output context created by . However, it is possible that a client does not know how the output context was created. Before a client destroys the output context, it can query whether XNOMAutomatic -is set to determine whether +is set to determine whether -or +or should be used to destroy the output context. @@ -2089,7 +2089,7 @@ should be used to destroy the output context. Xlib international text drawing is done using a set of one or more fonts, as needed for the locale of the text. -Fonts are loaded according to a list of base font names +Fonts are loaded according to a list of base font names supplied by the client and the charsets required by the locale. The XFontSet @@ -2100,7 +2100,7 @@ and is equivalent to the type -The +The function is a convenience function for creating an output context using only default values. The returned @@ -2186,10 +2186,10 @@ Returns the string drawn for missing charsets. -The +The function creates a font set for the specified display. -The font set is bound to the current locale when +The font set is bound to the current locale when is called. The font set may be used in subsequent calls to obtain font @@ -2201,7 +2201,7 @@ The base_font_name_list argument is a list of base font names that Xlib uses to load the fonts needed for the locale. The base font names are a comma-separated list. The string is null-terminated -and is assumed to be in the Host Portable Character Encoding; +and is assumed to be in the Host Portable Character Encoding; otherwise, the result is implementation-dependent. White space immediately on either side of a separating comma is ignored. @@ -2230,22 +2230,22 @@ function will return this XLFD name instead of the client-sup Xlib uses the following algorithm to select the fonts -that will be used to display text with the +that will be used to display text with the XFontSet. For each font charset required by the locale, -the base font name list is searched for the first appearance of one +the base font name list is searched for the first appearance of one of the following cases that names a set of fonts that exist at the server: The first XLFD-conforming base font name that specifies the required -charset or a superset of the required charset in its +charset or a superset of the required charset in its CharSetRegistry -and +and CharSetEncoding fields. The implementation may use a base font name whose specified charset @@ -2258,10 +2258,10 @@ an ISO8859-1 font for an ASCII charset. The first set of one or more XLFD-conforming base font names that specify one or more charsets that can be remapped to support the required charset. -The Xlib implementation may recognize various mappings +The Xlib implementation may recognize various mappings from a required charset to one or more other charsets and use the fonts for those charsets. -For example, JIS Roman is ASCII with tilde and backslash replaced +For example, JIS Roman is ASCII with tilde and backslash replaced by yen and overbar; Xlib may load an ISO8859-1 font to support this character set if a JIS Roman font is not available. @@ -2271,7 +2271,7 @@ if a JIS Roman font is not available. The first XLFD-conforming font name or the first non-XLFD font name for which an XLFD font name can be obtained, combined with the -required charset (replacing the +required charset (replacing the CharSetRegistry and CharSetEncoding @@ -2347,9 +2347,9 @@ For example: -If +If -is unable to create the font set, +is unable to create the font set, either because there is insufficient memory or because the current locale is not supported, @@ -2378,12 +2378,12 @@ may be able to remap a required charset. If no font exists for any of the required charsets or if the locale definition in Xlib requires that a font exist -for a particular charset and a font is not found for that charset, +for a particular charset and a font is not found for that charset, returns NULL. -Otherwise, +Otherwise, -returns a valid +returns a valid XFontSet to font_set. @@ -2396,15 +2396,15 @@ drawable. If def_string_return is non-NULL, returns a pointer to a string that represents the glyphs -that are drawn with this +that are drawn with this XFontSet when the charsets of the available fonts do not include all font glyphs required to draw a codepoint. -The string does not necessarily consist of valid characters +The string does not necessarily consist of valid characters in the current locale and is not necessarily drawn with the fonts loaded for the font set, but the client can draw and measure the default glyphs -by including this string in a string being drawn or measured with the +by including this string in a string being drawn or measured with the XFontSet. @@ -2413,9 +2413,9 @@ If the string returned to def_string_return is the empty string (""), no glyphs are drawn, and the escapement is zero. The returned string is null-terminated. It is owned by Xlib and should not be modified or freed by the client. -It will be freed by a call to +It will be freed by a call to -with the associated +with the associated XFontSet. Until freed, its contents will not be modified by Xlib. @@ -2427,23 +2427,23 @@ operation in the case that some fonts did not exist. -The returned +The returned XFontSet -and missing charset list should be freed with +and missing charset list should be freed with and , respectively. -The client-supplied base_font_name_list may be freed -by the client after calling +The client-supplied base_font_name_list may be freed +by the client after calling . -To obtain a list of +To obtain a list of XFontStruct -structures and full font names given an +structures and full font names given an XFontSet, use . @@ -2496,7 +2496,7 @@ Returns the list of font names. The -function returns a list of one or more +function returns a list of one or more XFontStructs and font names for the fonts used by the Xmb and Xwc layers for the given font set. @@ -2514,34 +2514,34 @@ structures and font names is returned as the value of the function. Because it is not guaranteed that a given character will be imaged using a single font glyph, -there is no provision for mapping a character or default string -to the font properties, font ID, or direction hint for the font +there is no provision for mapping a character or default string +to the font properties, font ID, or direction hint for the font for the character. -The client may access the +The client may access the XFontStruct list to obtain these values for all the fonts currently in use. Xlib does not guarantee that fonts are loaded from the server -at the creation of an +at the creation of an XFontSet. -Xlib may choose to cache font data, loading it only as needed to draw text +Xlib may choose to cache font data, loading it only as needed to draw text or compute text dimensions. -Therefore, existence of the per_char metrics in the +Therefore, existence of the per_char metrics in the XFontStruct structures in the XFontStructSet is undefined. -Also, note that all properties in the +Also, note that all properties in the XFontStruct structures are in the STRING encoding. -The +The XFontStruct -and font name lists are owned by Xlib +and font name lists are owned by Xlib and should not be modified or freed by the client. They will be freed by a call to @@ -2584,7 +2584,7 @@ Specifies the font set. The function returns the original base font name list supplied -by the client when the +by the client when the XFontSet was created. A null-terminated string containing a list of @@ -2594,7 +2594,7 @@ White space may appear immediately on either side of separating commas. -If +If obtained an XLFD name from the font properties for the font specified by a non-XLFD base name, the @@ -2605,16 +2605,16 @@ function will return the XLFD name instead of the non- The base font name list is owned by Xlib and should not be modified or freed by the client. -It will be freed by a call to +It will be freed by a call to -with the associated +with the associated XFontSet. Until freed, its contents will not be modified by Xlib. -To obtain the locale name given an +To obtain the locale name given an XFontSet, use . @@ -2656,18 +2656,18 @@ The returned locale name string is owned by Xlib and should not be modified or freed by the client. It may be freed by a call to -with the associated +with the associated XFontSet. Until freed, it will not be modified by Xlib. -The +The function is a convenience function for freeing an output context. -also frees its associated +also frees its associated XOM if the output context was created by . @@ -2710,9 +2710,9 @@ Specifies the font set. The function frees the specified font set. -The associated base font name list, font name list, +The associated base font name list, font name list, XFontStruct -list, and +list, and XFontSetExtents, if any, are freed. @@ -2724,18 +2724,18 @@ if any, are freed. -Metrics for the internationalized text drawing functions -are defined in terms of a primary draw direction, +Metrics for the internationalized text drawing functions +are defined in terms of a primary draw direction, which is the default direction in which the character origin advances for each succeeding character in the string. The Xlib interface is currently defined to support only a left-to-right primary draw direction. -The drawing origin is the position passed to the drawing function +The drawing origin is the position passed to the drawing function when the text is drawn. The baseline is a line drawn through the drawing origin parallel to the primary draw direction. -Character ink is the pixels painted in the foreground color -and does not include interline or intercharacter spacing +Character ink is the pixels painted in the foreground color +and does not include interline or intercharacter spacing or image text background pixels. @@ -2760,14 +2760,14 @@ or The drawing functions are allowed to implement context-dependent rendering, where the glyphs drawn for a string are not simply a concatenation of the glyphs that represent each individual character. -A string of two characters drawn with +A string of two characters drawn with -may render differently than if the two characters +may render differently than if the two characters were drawn with separate calls to . -If the client appends or inserts a character +If the client appends or inserts a character in a previously drawn string, -the client may need to redraw some adjacent characters +the client may need to redraw some adjacent characters to obtain proper rendering. @@ -2897,7 +2897,7 @@ in a text stream. The maximum character extents for the fonts that are used by the text -drawing layers can be accessed by the +drawing layers can be accessed by the XFontSetExtents structure: XFontSetExtents @@ -2915,9 +2915,9 @@ typedef struct { -The +The XRectangle -structures used to return font set metrics are the usual Xlib screen-oriented +structures used to return font set metrics are the usual Xlib screen-oriented rectangles with x, y giving the upper left corner, and width and height always positive. @@ -2926,7 +2926,7 @@ with x, y giving the upper left corner, and width and height always positive. The max_ink_extent member gives the maximum extent, over all drawable characters, of the rectangles that bound the character glyph image drawn in the foreground color, relative to a constant origin. -See +See and XwcTextExtents @@ -2935,19 +2935,19 @@ for detailed semantics. The max_logical_extent member gives the maximum extent, -over all drawable characters, of the rectangles +over all drawable characters, of the rectangles that specify minimum spacing to other graphical features, relative to a constant origin. Other graphical features drawn by the client, for example, a border surrounding the text, should not intersect this rectangle. -The max_logical_extent member should be used to compute minimum +The max_logical_extent member should be used to compute minimum interline spacing and the minimum area that must be allowed in a text field to draw a given number of arbitrary characters. Due to context-dependent rendering, -appending a given character to a string may change +appending a given character to a string may change the string's extent by an amount other than that character's individual extent. @@ -2999,13 +2999,13 @@ for the given font set. -The +The XFontSetExtents structure is owned by Xlib and should not be modified or freed by the client. -It will be freed by a call to +It will be freed by a call to -with the associated +with the associated XFontSet. Until freed, its contents will not be modified by Xlib. @@ -3015,7 +3015,7 @@ Until freed, its contents will not be modified by Xlib. To obtain the escapement in pixels of the specified text as a value, use -or +or . XmbTextEscapement @@ -3208,7 +3208,7 @@ functions set the components of the specified overall_ink_return and overall_logical_return arguments to the overall bounding box of the string's image and a logical bounding box for spacing purposes, respectively. -They return the value returned by +They return the value returned by or . @@ -3238,11 +3238,11 @@ should not intersect this rectangle. -When the +When the XFontSet has missing charsets, -metrics for each unavailable character are taken -from the default string returned by +metrics for each unavailable character are taken +from the default string returned by so that the metrics represent the text as it will actually be drawn. The behavior for an invalid codepoint is undefined. @@ -3250,10 +3250,10 @@ The behavior for an invalid codepoint is undefined. To determine the effective drawing origin for a character in a drawn string, -the client should call +the client should call on the entire string, then on the character, -and subtract the x values of the returned +and subtract the x values of the returned rectangles for the character. This is useful to redraw portions of a line of text or to justify words, but for context-dependent rendering, @@ -3416,7 +3416,7 @@ functions return the text dimensions of each character of the specified text, using the fonts loaded for the specified font set. Each successive element of ink_array_return and logical_array_return is set to the successive character's drawn metrics, -relative to the drawing origin of the string and one +relative to the drawing origin of the string and one rectangle for each character in the supplied text string. The number of elements of ink_array_return and logical_array_return @@ -3424,9 +3424,9 @@ that have been set is returned to num_chars_return. -Each element of ink_array_return is set to the bounding box +Each element of ink_array_return is set to the bounding box of the corresponding character's drawn foreground color. -Each element of logical_array_return is set to the bounding box +Each element of logical_array_return is set to the bounding box that provides minimum spacing to other graphical features for the corresponding character. Other graphical features should not intersect any of the @@ -3434,22 +3434,22 @@ logical_array_return rectangles. -Note that an +Note that an XRectangle represents the effective drawing dimensions of the character, regardless of the number of font glyphs that are used to draw the character or the direction in which the character is drawn. If multiple characters map to a single character glyph, -the dimensions of all the +the dimensions of all the XRectangles of those characters are the same. -When the +When the XFontSet has missing charsets, metrics for each unavailable -character are taken from the default string returned by +character are taken from the default string returned by so that the metrics represent the text as it will actually be drawn. The behavior for an invalid codepoint is undefined. @@ -3465,12 +3465,12 @@ Otherwise, the functions return a nonzero value. If the overall_ink_return or overall_logical_return argument is non-NULL, -and +and return the maximum extent of the string's metrics to overall_ink_return -or overall_logical_return, as returned by +or overall_logical_return, as returned by -or +or XwcTextExtents. @@ -3494,7 +3494,7 @@ instead of treating the bytes of the string as direct font indexes. See section 8.6 for details of the use of Graphics Contexts (GCs) and possible protocol errors. -If a +If a BadFont error is generated, characters prior to the offending character may have been drawn. @@ -3597,7 +3597,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -3659,7 +3659,7 @@ Specifies the number of text items in the array. The -and +and functions allow complex spacing and font set shifts between text strings. Each text item is processed in turn, with the origin of a text @@ -3667,7 +3667,7 @@ element advanced in the primary draw direction by the escapement of the previous text item. A text item delta specifies an additional escapement of the text item drawing origin in the primary draw direction. -A font_set member other than +A font_set member other than None in an item causes the font set to be used for this and subsequent text items in the text_items list. @@ -3685,14 +3685,14 @@ Clients may compute the drawing metrics by passing each text segment to and XwcTextExtents -or +or and . -When the +When the XFontSet -has missing charsets, each unavailable character is drawn -with the default string returned by +has missing charsets, each unavailable character is drawn +with the default string returned by . The behavior for an invalid codepoint is undefined. @@ -3752,7 +3752,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -3837,10 +3837,10 @@ The and functions draw the specified text with the foreground pixel. -When the +When the XFontSet -has missing charsets, each unavailable character is drawn -with the default string returned by +has missing charsets, each unavailable character is drawn +with the default string returned by . The behavior for an invalid codepoint is undefined. @@ -3900,7 +3900,7 @@ Specifies the connection to the X server. -Specifies the drawable. +Specifies the drawable. @@ -3988,17 +3988,17 @@ functions fill a destination rectangle with the background pixel defined in the GC and then paint the text with the foreground pixel. The filled rectangle is the rectangle returned to overall_logical_return by -or +or XwcTextExtents -for the same text and +for the same text and XFontSet. -When the +When the XFontSet -has missing charsets, each unavailable character is drawn -with the default string returned by +has missing charsets, each unavailable character is drawn +with the default string returned by . The behavior for an invalid codepoint is undefined. @@ -4086,12 +4086,12 @@ a user usually has a keyboard on which there exist key symbols corresponding to the alphabet. Sometimes, a few characters of an alphabetic language are missing on the keyboard. -Many computer users who speak a Latin-alphabet-based language +Many computer users who speak a Latin-alphabet-based language only have an English-based keyboard. They need to hit a combination of keystrokes to enter a character that does not exist directly on the keyboard. A number of algorithms have been developed for entering such characters. -These are known as European input methods, compose input methods, +These are known as European input methods, compose input methods, or dead-key input methods. @@ -4110,7 +4110,7 @@ Each set consists of 48 characters. Korean also has a phonetic symbol set, called Hangul. Each of the 24 basic phonetic symbols (14 consonants and 10 vowels) represents a specific sound. -A syllable is composed of two or three parts: +A syllable is composed of two or three parts: the initial consonants, the vowels, and the optional last consonants. With Hangul, syllables can be treated as the basic units on which text processing is done. @@ -4134,7 +4134,7 @@ ideographic writing system. In an ideographic system, rather than taking a small set of symbols and combining them in different ways to create words, each word consists of one unique symbol (or, occasionally, several symbols). -The number of symbols can be very large: +The number of symbols can be very large: approximately 50,000 have been identified in Hanzi, the Chinese ideographic system. @@ -4185,7 +4185,7 @@ and then follows the same basic method as that described for Japanese. Probably because there are well-accepted phonetic writing systems for Japanese and Korean, -computer input methods in these countries for entering ideographs +computer input methods in these countries for entering ideographs are fairly standard. Keyboard keys have both English characters and phonetic symbols engraved on them, and the user can switch between the two sets. @@ -4197,8 +4197,8 @@ While there is a phonetic system called Pinyin promoted by authorities, there is no consensus for entering Chinese text. Some vendors use a phonetic decomposition (Pinyin or another), others use ideographic decomposition of Chinese words, -with various implementations and keyboard layouts. -There are about 16 known methods, none of which is a clear standard. +with various implementations and keyboard layouts. +There are about 16 known methods, none of which is a clear standard. @@ -4208,9 +4208,9 @@ and Simplified Chinese. Several years ago, the People's Republic of China launched a campaign to simplify some ideographic characters and eliminate redundancies altogether. -Under the plan, +Under the plan, characters would be streamlined every five years. -Characters have been revised several times now, +Characters have been revised several times now, resulting in the smaller, simpler set that makes up Simplified Chinese. @@ -4222,13 +4222,13 @@ resulting in the smaller, simpler set that makes up Simplified Chinese. As shown in the previous section, there are many different input methods in use today, -each varying with language, culture, and history. +each varying with language, culture, and history. A common feature of many input methods is that the user may type multiple keystrokes to compose a single character (or set of characters). The process of composing characters from keystrokes is called preediting. -It may require complex algorithms and large dictionaries +It may require complex algorithms and large dictionaries involving substantial computer resources. @@ -4251,8 +4251,8 @@ The status area may consist of text data and bitmaps or some combination. The preedit area displays the -intermediate text for those languages that are composing prior to -the client handling the data. +intermediate text for those languages that are composing prior to +the client handling the data. @@ -4296,7 +4296,7 @@ Often, this type of window is placed at the bottom of the application window. Root-window preediting refers to input methods that use a preedit -window that is the child of +window that is the child of RootWindow. @@ -4306,7 +4306,7 @@ window that is the child of It would require a lot of computing resources if portable applications had to include input methods for all the languages in the world. To avoid this, -a goal of the Xlib design is to allow an application +a goal of the Xlib design is to allow an application to communicate with an input method placed in a separate process. Such a process is called an input server. The server to which the application should connect is dependent on @@ -4358,7 +4358,7 @@ and a filtering mechanism for noncharacter keystrokes A back-end architecture sometimes implies more communication overhead and more process switching. If all three processes (X server, input server, client) -are running on a single workstation, +are running on a single workstation, there are two process switches for each keystroke in a back-end architecture, but there is only one in a front-end architecture. @@ -4366,15 +4366,15 @@ but there is only one in a front-end architecture. The abstraction used by a client to communicate with an input method -is an opaque data structure represented by the +is an opaque data structure represented by the XIM data type. -This data structure is returned by the +This data structure is returned by the function, which opens an input method on a given display. Subsequent operations on this data structure encapsulate all communication between client and input method. -There is no need for an X client to use any networking library +There is no need for an X client to use any networking library or natural language package to use an input method. @@ -4400,7 +4400,7 @@ each window with multiple text entry areas, and the user possibly switching among them at any time. The abstraction for representing the state of a particular input thread is called an input context. -The Xlib representation of an input context is an +The Xlib representation of an input context is an XIC. @@ -4419,15 +4419,15 @@ abstraction defined for graphics output. One input context belongs to exactly one input method. Different input contexts may be associated with the same input method, possibly with the same client window. -An +An XIC is created with the -function, providing an +function, providing an XIM argument and affiliating the input context to the input method -for its lifetime. -When an input method is closed with +for its lifetime. +When an input method is closed with , all of its affiliated input contexts should not be used any more (and should preferably be destroyed before closing the input method). @@ -4448,7 +4448,7 @@ in that context. A single context is created for a top-level window in the application. -If such a window contains several text entry areas, +If such a window contains several text entry areas, each time the user moves to another text entry area, the client has to indicate changes in the context. @@ -4471,16 +4471,16 @@ according to the needs of their application. To obtain characters from an input method, a client must call the function -or +or with an input context created from that input method. Both a locale and display are bound to an input method when it is opened, and an input context inherits this locale and display. -Any strings returned by +Any strings returned by or -will be encoded in that locale. +will be encoded in that locale. @@ -4502,7 +4502,7 @@ there will be an associated input context. When the application focus moves to a text entry area, the application must set the input context focus to the input context associated with that area. -The input context focus is set by calling +The input context focus is set by calling with the appropriate input context. @@ -4515,7 +4515,7 @@ by calling As an optimization, if is called successively on two different input contexts, -setting the focus on the second +setting the focus on the second will automatically unset the focus on the first. @@ -4541,7 +4541,7 @@ input context whenever the focus window changes -In most input method architectures +In most input method architectures (on-the-spot being the notable exception), the input method will perform the display of its own data. To provide better visual locality, @@ -4584,20 +4584,20 @@ and it must accept the size it is given. Before a client provides geometry management for an input method, it must determine if geometry management is needed. -The input method indicates the need for geometry management -by setting +The input method indicates the need for geometry management +by setting XIMPreeditArea -or +or XIMStatusArea -in its +in its XIMStyles -value returned by +value returned by . When a client has decided that it will provide geometry management -for an input method, +for an input method, it indicates that decision by setting the XNInputStyle -value in the +value in the XIC. @@ -4620,7 +4620,7 @@ Otherwise, it will set one of the values. -The client will get the XIC value +The client will get the XIC value XNAreaNeeded. The input method will return its suggested size in this value. The input method should pay attention to any constraints suggested @@ -4631,7 +4631,7 @@ by the client. The client sets the XIC value XNArea -to inform the input method of the geometry of its window. +to inform the input method of the geometry of its window. The client should try to honor the geometry requested by the input method. The input method must accept this geometry. @@ -4641,11 +4641,11 @@ The input method must accept this geometry. Clients doing geometry management must be aware that setting other XIC values may affect the geometry desired by an input method. -For example, +For example, XNFontSet and XNLineSpace -may change the geometry desired by the input method. +may change the geometry desired by the input method. @@ -4709,7 +4709,7 @@ to translations such as those the X Toolkit Intrinsics library provides. -Clients are expected to get the XIC value +Clients are expected to get the XIC value XNFilterEvents and augment the event mask for the client window with that event mask. This mask may be zero. @@ -4725,7 +4725,7 @@ This mask may be zero. When an on-the-spot input method is implemented, only the client can insert or delete preedit data in place and possibly scroll existing text. -This means that the echo of the keystrokes has to be achieved +This means that the echo of the keystrokes has to be achieved by the client itself, tightly coupled with the input method logic. @@ -4791,7 +4791,7 @@ scrolling of a long preedit string within a short preedit display area. As highlighted before, the input method architecture provides preediting, which supports a type of preprocessor input composition. In this case, composition consists of interpreting a sequence -of key events and returning a committed string via +of key events and returning a committed string via or . @@ -4801,15 +4801,15 @@ This provides the basics for input methods. In addition to preediting based on key events, a general framework is provided to give a client that desires it more advanced preediting based -on the text within the client. This framework is called -string conversion and is provided using XIC values. +on the text within the client. This framework is called +string conversion and is provided using XIC values. The fundamental concept of string conversion is to allow the input method to manipulate the client's text independent of any user preediting operation. -The need for string conversion is based on +The need for string conversion is based on language needs and input method capabilities. The following are some examples of string conversion: @@ -4818,40 +4818,40 @@ The following are some examples of string conversion: Transliteration conversion provides language-specific conversions within the input method. -In the case of Korean input, users wish to convert a Hangul string +In the case of Korean input, users wish to convert a Hangul string into a Hanja string while in preediting, after preediting, or in other situations (for example, on a selected string). The conversion is triggered when the user presses a Hangul-to-Hanja key sequence (which may be input method specific). Sometimes the user may want to invoke the conversion after finishing -preediting or on a user-selected string. -Thus, the string to be converted is in an application buffer, not in +preediting or on a user-selected string. +Thus, the string to be converted is in an application buffer, not in the preedit area of the input method. The string conversion services -allow the client to request this transliteration conversion from the +allow the client to request this transliteration conversion from the input method. -There are many other transliteration conversions defined for +There are many other transliteration conversions defined for various languages, for example, Kana-to-Kanji conversion in Japanese. The key to remember is that transliteration conversions are triggered -at the request of the user and returned to the client +at the request of the user and returned to the client immediately without affecting the preedit area of the input method. -Reconversion of a previously committed string or -a selected string is supported by many input methods as a +Reconversion of a previously committed string or +a selected string is supported by many input methods as a convenience to the user. For example, a user tends to mistype the commit key while preediting. In that case, some input methods provide a special -key sequence to request a ``reconvert'' operation on the +key sequence to request a ``reconvert'' operation on the committed string, similar to the undo facility provided by most text editors. -Another example is where the user is proofreading a document +Another example is where the user is proofreading a document that has some misconversions from preediting and wants to correct the misconverted text. Such reconversion is again triggered by the user invoking some special action, but reconversions should -not affect the state of the preedit area. +not affect the state of the preedit area. @@ -4859,18 +4859,18 @@ not affect the state of the preedit area. Context-sensitive conversion is required for some languages and input methods that need to retrieve text that surrounds the current spot location (cursor position) of the client's buffer. -Such text is needed when the preediting operation depends on +Such text is needed when the preediting operation depends on some surrounding characters (usually preceding the spot location). -For example, +For example, in Thai language input, certain character sequences may be invalid and the input method may want to check whether characters constitute a valid word. Input methods that do such context-dependent checking need to retrieve the characters surrounding the current cursor position to obtain complete words. -Unlike other conversions, this conversion is not explicitly +Unlike other conversions, this conversion is not explicitly requested by the user. -Input methods that provide such context-sensitive conversion +Input methods that provide such context-sensitive conversion continuously need to request context from the client, and any change in the context of the spot location may affect such conversions. The client's context would be needed if the user moves the cursor @@ -4881,7 +4881,7 @@ should take notice of when the client calls or , -which is usually an indication of a context change. +which is usually an indication of a context change. @@ -4899,9 +4899,9 @@ functions. -String conversion support is dependent on the availability of the +String conversion support is dependent on the availability of the XNStringConversion -or +or XNStringConversionCallback XIC values. Because the input method may not support string conversions, @@ -4915,15 +4915,15 @@ IM value. The difference between these two values is whether the -conversion is invoked by the client or the input method. -The +conversion is invoked by the client or the input method. +The XNStringConversion -XIC value is used by clients to request +XIC value is used by clients to request a string conversion from the input method. The client -is responsible for determining which events are used +is responsible for determining which events are used to trigger the string conversion and whether the string to be converted should be copied or deleted. The type of conversion -is determined by the input method; the client can only +is determined by the input method; the client can only pass the string to be converted. The client is guaranteed that no XNStringConversionCallback @@ -4941,7 +4941,7 @@ it is the input method's responsibility to determine which events are used to trigger the string conversion. When such events occur, the input method issues a call to the client-supplied procedure to retrieve the string to be converted. The client's -callback procedure is notified whether to copy or delete the string and +callback procedure is notified whether to copy or delete the string and is provided with hints as to the amount of text needed. The XIMStringConversionCallbackStruct @@ -4949,14 +4949,14 @@ specifies which text should be passed back to the input method. -Finally, the input method may call the client's +Finally, the input method may call the client's XNStringConversionCallback procedure multiple times if the string returned from the callback is not sufficient to perform a successful conversion. The arguments to the client's procedure allow the input method to define a -position (in character units) relative to the client's cursor position +position (in character units) relative to the client's cursor position and the size of the text needed. By varying the position and size of -the desired text in subsequent callbacks, the input method can retrieve +the desired text in subsequent callbacks, the input method can retrieve additional text. @@ -4976,7 +4976,7 @@ an input method () and freeing an input method (). -However, input methods may +However, input methods may require complex communication with input method servers (IM servers), for example: @@ -4987,14 +4987,14 @@ for example: If the X server, IM server, and X clients are started asynchronously, some clients may attempt to connect to the IM server before it is fully operational, and fail. -Therefore, some mechanism is needed to allow clients to detect when an IM +Therefore, some mechanism is needed to allow clients to detect when an IM server has started. -It is up to clients to decide what should be done when an IM server is +It is up to clients to decide what should be done when an IM server is not available (for example, wait, or use some other IM server). @@ -5003,14 +5003,14 @@ not available (for example, wait, or use some other IM server). -Some input methods may allow the underlying IM server to be switched. +Some input methods may allow the underlying IM server to be switched. Such customization may be desired without restarting the entire client. -To support management of input methods in these cases, the following +To support management of input methods in these cases, the following functions are provided: @@ -5033,12 +5033,12 @@ functions are provided: , These functions use the XIM and XIC values, XNDestroyCallback, - to allow a client + to allow a client to register a callback procedure to be called when Xlib detects that - an IM server that was associated with an opened + an IM server that was associated with an opened input method is no longer available. - In addition, this function can be used to switch IM servers for those input - methods that support such functionality. The IM value for switching IM + In addition, this function can be used to switch IM servers for those input + methods that support such functionality. The IM value for switching IM servers is implementation-dependent; see the description below about switching IM servers. @@ -5058,7 +5058,7 @@ side-effects: -The input method will ensure that any new IM server supports any of the +The input method will ensure that any new IM server supports any of the input styles being used by input contexts already associated with the input method. However, the list of supported input styles may be different. @@ -5090,8 +5090,8 @@ Some clients need to guarantee which keys can be used to escape from the input method, regardless of the input method state; for example, the client-specific Help key or the keys to move the input focus. -The HotKey mechanism allows clients -to specify a set of keys for this purpose. However, the input +The HotKey mechanism allows clients +to specify a set of keys for this purpose. However, the input method might not allow clients to specify hot keys. Therefore, clients have to query support of hot keys by checking the supported XIC values list by calling @@ -5099,8 +5099,8 @@ supported XIC values list by calling with the XNQueryICValuesList IM value. -When the hot keys specified conflict with the key bindings of the -input method, hot keys take precedence over the key bindings of the input +When the hot keys specified conflict with the key bindings of the +input method, hot keys take precedence over the key bindings of the input method. @@ -5132,19 +5132,19 @@ an application needs to register a callback by calling with the XNPreeditStateNotifyCallback -XIC value. -In order to change the preedit state programmatically, an application -needs to call +XIC value. +In order to change the preedit state programmatically, an application +needs to call with XNPreeditState. -Availability of the preedit state is input method dependent. The input +Availability of the preedit state is input method dependent. The input method may not provide the ability to set the state or to -retrieve the state programmatically. Therefore, clients have to -query availability of preedit state operations by checking the +retrieve the state programmatically. Therefore, clients have to +query availability of preedit state operations by checking the supported XIC values list by calling with the @@ -5222,7 +5222,7 @@ Specifies the full class name of the application. The -function opens an input method, +function opens an input method, matching the current locale and modifiers specification. Current locale and modifiers are bound to the input method at opening time. The locale associated with an input method cannot be changed dynamically. @@ -5236,11 +5236,11 @@ will be encoded in the locale current at the time the input method is opened. The specific input method to which this call will be routed -is identified on the basis of the current locale. +is identified on the basis of the current locale. will identify a default input method corresponding to the current locale. -That default can be modified using +That default can be modified using for the input method modifier. @@ -5255,8 +5255,8 @@ no database is passed to the input method. -The res_name and res_class arguments specify the resource name -and class of the application. +The res_name and res_class arguments specify the resource name +and class of the application. They are intended to be used as prefixes by the input method when looking up resources that are common to all input contexts that may be created for this input method. @@ -5368,7 +5368,7 @@ correctly. -To query an input method, use +To query an input method, use . XGetIMValues @@ -5588,9 +5588,9 @@ locale and modifiers. -The function returns +The function returns True - if it succeeds; otherwise, it returns + if it succeeds; otherwise, it returns False. @@ -5731,7 +5731,7 @@ function removes an input method instantiation callback previously registered. The function returns True -if it succeeds; otherwise, it returns +if it succeeds; otherwise, it returns False. @@ -5745,7 +5745,7 @@ if it succeeds; otherwise, it returns The following table describes how XIM values are interpreted by an input method. The first column lists the XIM values. -The second column indicates how each of the XIM values +The second column indicates how each of the XIM values are treated by that input style. @@ -5850,7 +5850,7 @@ is obsolete and its use is not recommended -A client should always query the input method to determine which input +A client should always query the input method to determine which input styles are supported. The client should then find an input style it is capable of supporting. @@ -5866,7 +5866,7 @@ The argument value must be a pointer to a location where the returned value will be stored. The returned value is a pointer to a structure of type XIMStyles. -Clients are responsible for freeing the +Clients are responsible for freeing the XIMStyles structure. To do so, use @@ -5918,7 +5918,7 @@ typedef struct { -An +An XIMStyles structure contains the number of input styles supported in its count_styles field. @@ -5955,7 +5955,7 @@ by the input method for preedit information. If chosen, the input method would require the client to provide some area values for it to do its preediting. - Refer to XIC values + Refer to XIC values XNArea and XNAreaNeeded. @@ -5963,8 +5963,8 @@ by the input method for preedit information. XIMPreeditPosition If chosen, - the input method would require the client to provide positional values. - Refer to XIC values + the input method would require the client to provide positional values. + Refer to XIC values XNSpotLocation and XNFocusWindow. @@ -5973,7 +5973,7 @@ by the input method for preedit information. XIMPreeditCallbacks If chosen, the input method would require the client to define the set of preedit callbacks. - Refer to XIC values + Refer to XIC values XNPreeditStartCallback, XNPreeditDoneCallback, XNPreeditDrawCallback, @@ -6075,12 +6075,12 @@ set as resources. -The +The XNDestroyCallback argument is a pointer to a structure of type XIMCallback. XNDestroyCallback -is triggered when an input method stops its service for any reason. +is triggered when an input method stops its service for any reason. After the callback is invoked, the input method is closed and the associated input context(s) are destroyed by Xlib. Therefore, the client should not call @@ -6162,7 +6162,7 @@ The argument value must be a pointer to a location where the returned value will be stored. The returned value is a pointer to a structure of type XIMValuesList. -Clients are responsible for freeing the +Clients are responsible for freeing the XIMValuesList structure. To do so, use @@ -6195,9 +6195,9 @@ typedef struct { -The +The XNVisiblePosition -argument indicates whether the visible position masks of +argument indicates whether the visible position masks of XIMFeedback in XIMText @@ -6223,9 +6223,9 @@ Because this XIM value is optional, a client should call with argument XNQueryIMValuesList before using this argument. -If the +If the XNVisiblePosition -does not exist in the IM values list returned from +does not exist in the IM values list returned from XNQueryIMValuesList, the visible position masks of XIMFeedback @@ -6263,7 +6263,7 @@ before it was published. -The +The XNR6PreeditCallback argument indicates whether the behavior of preedit callbacks regarding XIMPreeditDrawCallbackStruct @@ -6453,7 +6453,7 @@ destroys the specified input context. To communicate to and synchronize with input method for any changes in keyboard focus from the client side, -use +use and . @@ -6532,7 +6532,7 @@ Complete feedback specification is a matter of user interface policy. Calling does not affect the focus window value; -the client may still receive +the client may still receive events from the input method that are directed to the focus window. @@ -6591,7 +6591,7 @@ the current input context state is preserved. In both cases, any input pending on that context is deleted. The input method is required to clear the preedit area, if any, and update the status accordingly. -Calling +Calling or @@ -6604,8 +6604,8 @@ The return value of is its current preedit string as a multibyte string. If there is any preedit text drawn or visible to the user, then these procedures must return a non-NULL string. -If there is no visible preedit text, -then it is input method implementation-dependent +If there is no visible preedit text, +then it is input method implementation-dependent whether these procedures return a non-NULL string or NULL. @@ -6701,7 +6701,7 @@ values. The -function returns NULL if no error occurred; +function returns NULL if no error occurred; otherwise, it returns the name of the first argument that could not be set. An argument might not be set for any of the following reasons: @@ -6829,7 +6829,7 @@ applies to each element of the nested list. The following tables describe how XIC values are interpreted -by an input method depending on the input style chosen by the +by an input method depending on the input style chosen by the user. @@ -6839,7 +6839,7 @@ The second column indicates which values are involved in affecting, negotiating, and setting the geometry of the input method windows. The subentries under the third column indicate the different input styles that are supported. -Each of these columns indicates how each of the XIC values +Each of these columns indicates how each of the XIC values are treated by that input style. @@ -6864,14 +6864,14 @@ The following keys apply to these tables. D - This value may be set using + This value may be set using .> If it is not set,> a default is provided. G - This value may be read using + This value may be read using . @@ -6883,7 +6883,7 @@ The following keys apply to these tables. GR - This value will be the response of the input method when any + This value will be the response of the input method when any GN value is changed. @@ -7396,7 +7396,7 @@ and the client window will not be changed. If the client window is not a valid window ID on the display attached to the input method, -a +a BadWindow error can be generated when this value is used by the input method. @@ -7412,7 +7412,7 @@ error can be generated when this value is used by the input method. The XNFocusWindow argument specifies the focus window. -The primary purpose of the +The primary purpose of the XNFocusWindow is to identify the window that will receive the key event when input is composed. @@ -7437,17 +7437,17 @@ Modify its properties -Grab the keyboard within that window +Grab the keyboard within that window -The associated value must be of type +The associated value must be of type Window. -If the focus window is not a valid window ID on the display +If the focus window is not a valid window ID on the display attached to the input method, -a +a BadWindow error can be generated when this value is used by the input method. @@ -7471,7 +7471,7 @@ The and XNResourceClass arguments are strings that specify the full name and class -used by the client to obtain resources for the client window. +used by the client to obtain resources for the client window. These values should be used as prefixes for name and class when looking up resources that may vary according to the input context. If these values are not set, @@ -7491,21 +7491,21 @@ set as resources. XNGeometryCallback -The +The XNGeometryCallback -argument is a structure of type +argument is a structure of type XIMCallback (see section 13.5.6.13.12). -The +The XNGeometryCallback argument specifies the geometry callback that a client can set. -This callback is not required for correct operation of either +This callback is not required for correct operation of either an input method or a client. It can be set for a client whose user interface policy permits -an input method to request the dynamic change of that input +an input method to request the dynamic change of that input method's window. An input method that does dynamic change will need to filter any events that it uses to initiate the change. @@ -7519,11 +7519,11 @@ events that it uses to initiate the change. XNFilterEvents -The +The XNFilterEvents argument returns the event mask that an input method needs to have selected for. -The client is expected to augment its own event mask +The client is expected to augment its own event mask for the client window with this one. @@ -7533,7 +7533,7 @@ and is never changed. -The type of this argument is +The type of this argument is unsigned long. Setting this value will cause an error. @@ -7546,16 +7546,16 @@ Setting this value will cause an error. -The +The XNDestroyCallback argument is a pointer to a structure of type XIMCallback (see section 13.5.6.13.12). This callback is triggered when the input method stops its service for any reason; for example, when a connection to an IM -server is broken. After the destroy callback is called, +server is broken. After the destroy callback is called, the input context is destroyed and the input method is closed. -Therefore, the client should not call +Therefore, the client should not call and . @@ -7732,7 +7732,7 @@ state of the XIC. If XIMPreserveState -is set, then +is set, then and @@ -7919,10 +7919,10 @@ The XNPreeditAttributes and XNStatusAttributes -arguments specify to an input method the attributes to be used for the +arguments specify to an input method the attributes to be used for the preedit and status areas, if any. -Those attributes are passed to +Those attributes are passed to or @@ -7947,7 +7947,7 @@ argument is dependent on the input method style that has been set. -If the input method style is +If the input method style is XIMPreeditPosition, XNArea specifies the clipping region within which preediting will take place. @@ -7959,7 +7959,7 @@ the results are undefined. -If +If XNArea is not specified, is set to NULL, or is invalid, the input method will default the clipping region @@ -7970,9 +7970,9 @@ the results are undefined. -If the input style is +If the input style is XIMPreeditArea -or +or XIMStatusArea, XNArea specifies the geometry provided by the client to the input method. @@ -7983,9 +7983,9 @@ with dimensions that fit the XNArea. The coordinates are relative to the client window. If the client window has not been set yet, -the input method should save these values +the input method should save these values and apply them when the client window is set. -If +If XNArea is not specified, is set to NULL, or is invalid, the results are undefined. @@ -8003,11 +8003,11 @@ When set, the XNAreaNeeded argument specifies the geometry suggested by the client for this area (preedit or status). -The value associated with the argument must be a pointer to a -structure of type +The value associated with the argument must be a pointer to a +structure of type XRectangle. Note that the x, y values are not used -and that nonzero values for width or height are the constraints +and that nonzero values for width or height are the constraints that the client wishes the input method to respect. @@ -8019,12 +8019,12 @@ for the area. -This argument is only valid if the input style is +This argument is only valid if the input style is XIMPreeditArea -or +or XIMStatusArea. It is used for geometry negotiation between the client and the input method -and has no other effect on the input method +and has no other effect on the input method (see section 13.5.1.5). @@ -8039,11 +8039,11 @@ and has no other effect on the input method The XNSpotLocation argument specifies to the input method the coordinates of the spot -to be used by an input method executing with +to be used by an input method executing with XNInputStyle -set to +set to XIMPreeditPosition. -When specified to any input method other than +When specified to any input method other than XIMPreeditPosition, this XIC value is ignored. Some Xlib implementations will allow this to be set when @@ -8086,7 +8086,7 @@ The argument is used to specify a colormap ID. The argument value is of type Colormap. -An invalid argument may generate a +An invalid argument may generate a BadColor error when it is used by the input method. @@ -8097,7 +8097,7 @@ The XNStdColormap argument is used to indicate the name of the standard colormap in which the input method should allocate colors. -The argument value is an +The argument value is an Atom that should be a valid atom for calling . @@ -8147,7 +8147,7 @@ The XNBackgroundPixmap argument specifies a background pixmap to be used as the background of the window. -The value must be of type +The value must be of type Pixmap. An invalid argument may generate a BadPixmap @@ -8211,7 +8211,7 @@ The XNCursor argument specifies to the input method what cursor is to be used in the specified window. -This argument is of type +This argument is of type Cursor. @@ -8489,7 +8489,7 @@ typedef struct { Each callback has some particular semantics and will carry the data -that expresses the environment necessary to the client +that expresses the environment necessary to the client into a specific data structure. This paragraph only describes the arguments to be used to set the callback. @@ -8523,7 +8523,7 @@ Callbacks are mostly provided so that clients (or text editing packages) can implement on-the-spot preediting in their own window. In that case, the input method needs to communicate and synchronize with the client. -The input method needs to communicate changes in the preedit window +The input method needs to communicate changes in the preedit window when it is under control of the client. Those callbacks allow the client to initialize the preedit area, display a new preedit string, @@ -8602,7 +8602,7 @@ and specific data structure associated with the different reasons. -The geometry callback is triggered by the input method +The geometry callback is triggered by the input method to indicate that it wants the client to negotiate geometry. The generic prototype is as follows: @@ -8662,7 +8662,7 @@ The callback is called with a NULL call_data argument. -The destroy callback is triggered by the input method +The destroy callback is triggered by the input method when it stops service for any reason. After the callback is invoked, the input context will be freed by Xlib. The generic prototype is as follows: @@ -8723,7 +8723,7 @@ The callback is called with a NULL call_data argument. -The string conversion callback is triggered by the input method +The string conversion callback is triggered by the input method to request the client to return the string to be converted. The returned string may be either a multibyte or wide character string, with an encoding matching the locale bound to the input context. @@ -8783,13 +8783,13 @@ The text member is an structure (see section 13.5.6.9) to be filled in by the client and describes the text to be sent to the input method. -The data pointed to by the +The data pointed to by the string and feedback elements of the XIMStringConversionText structure will be freed using by the input method -after the callback returns. So the client should not point to +after the callback returns. So the client should not point to internal buffers that are critical to the client. Similarly, because the feedback element is currently reserved for future use, the client should set feedback to NULL to prevent the library from @@ -8797,7 +8797,7 @@ freeing memory at some random location due to an uninitialized pointer. -The +The XIMStringConversionCallbackStruct structure is defined as follows: @@ -8809,7 +8809,7 @@ structure is defined as follows: typedef struct _XIMStringConversionCallbackStruct { - XIMStringConversionPosition position; + XIMStringConversionPosition position; XIMCaretDirection direction; short factor; XIMStringConversionOperation operation; @@ -8838,28 +8838,28 @@ relative to the client's cursor position in the client's buffer. The ending position of the text buffer is determined by -the direction and factor members. Specifically, it is the character position +the direction and factor members. Specifically, it is the character position relative to the starting point as defined by the XIMCaretDirection. -The factor member of +The factor member of XIMStringConversionCallbackStruct specifies the number of XIMCaretDirection positions to be applied. For example, if the direction specifies XIMLineEnd -and factor is 1, then all characters from the starting position to +and factor is 1, then all characters from the starting position to the end of the current display line are returned. If the direction specifies XIMForwardChar or XIMBackwardChar, -then the factor specifies a relative position, indicated in characters, +then the factor specifies a relative position, indicated in characters, from the starting position. XIMStringConversionOperation -specifies whether the string to be converted should be +specifies whether the string to be converted should be deleted (substitution) or copied (retrieval) from the client's buffer. When the XIMStringConversionOperation @@ -8873,7 +8873,7 @@ is the client must not delete the string to be converted from its buffer. The substitute operation is typically used for reconversion and transliteration conversion, -while the retrieval operation is typically used for context-sensitive +while the retrieval operation is typically used for context-sensitive conversion. @@ -8942,7 +8942,7 @@ the callback is called with a NULL call_data argument. will return the maximum size of the preedit string. A positive number indicates the maximum number of bytes allowed -in the preedit string, +in the preedit string, and a value of -1 indicates there is no limit. PreeditDoneCallback @@ -9000,7 +9000,7 @@ The client can release the data allocated by should initialize appropriate data needed for -displaying preedit information and for handling further +displaying preedit information and for handling further calls. Once @@ -9021,7 +9021,7 @@ This callback is triggered to draw and insert, delete or replace, preedit text in the preedit region. The preedit text may include unconverted input text such as Japanese Kana, converted text such as Japanese Kanji characters, or characters of both kinds. -That string is either a multibyte or wide character string, +That string is either a multibyte or wide character string, whose encoding matches the locale bound to the input context. The callback prototype is as follows: @@ -9072,7 +9072,7 @@ Specifies the preedit drawing information. -The callback is passed an +The callback is passed an XIMPreeditDrawCallbackStruct structure in the call_data argument. The text member of this structure contains the text to be drawn. @@ -9081,7 +9081,7 @@ the caret should be moved to the specified location. -The +The XIMPreeditDrawCallbackStruct structure is defined as follows: @@ -9111,9 +9111,9 @@ as follows: -To indicate text deletion, +To indicate text deletion, the call_data member specifies a NULL text field. -The text to be deleted is then the current text in the buffer +The text to be deleted is then the current text in the buffer from position chg_first (starting at zero) on a character length of chg_length. @@ -9202,11 +9202,11 @@ the first and second character. typedef struct _XIMText { unsigned short length; XIMFeedback * feedback; - Bool encoding_is_wchar; + Bool encoding_is_wchar; union { char * multi_byte; wchar_t * wide_char; - } string; + } string; } XIMText; @@ -9223,7 +9223,7 @@ The length member is the text length in characters. -The encoding_is_wchar member is a value that indicates +The encoding_is_wchar member is a value that indicates if the text string is encoded in wide character or multibyte format. The text string may be passed either as multibyte or as wide character; the input method controls in which form data is passed. @@ -9255,33 +9255,33 @@ Rendering of the text to be drawn is specified either in generic ways (for example, primary, secondary) or in specific ways (reverse, underline). When generic indications are given, the client is free to choose the rendering style. -It is necessary, however, that primary and secondary be mapped +It is necessary, however, that primary and secondary be mapped to two distinct rendering styles. -If an input method wants to control display of the preedit string, an +If an input method wants to control display of the preedit string, an input method can indicate the visibility hints using feedbacks in a specific way. -The +The XIMVisibleToForward, XIMVisibleToBackword, and XIMVisibleToCenter masks are exclusively used for these visibility hints. -The +The XIMVisibleToForward mask indicates that the preedit text is preferably displayed in the primary draw direction from the caret position in the preedit area forward. -The +The XIMVisibleToBackword mask indicates that the preedit text is preferably displayed from the caret position in the preedit area backward, relative to the primary draw direction. -The +The XIMVisibleToCenter mask indicates that the preedit text is preferably displayed with @@ -9291,7 +9291,7 @@ the caret position in the preedit area centered. The insertion point of the preedit string could exist outside of the visible area when visibility hints are used. -Only one of the +Only one of the masks is valid for the entire preedit string, and only one character can hold one of these feedbacks for a given input context at one time. @@ -9316,13 +9316,13 @@ character of the string, and the length of the array is thus length. If an input method wants to indicate that it is only updating the feedback of -the preedit text without changing the content of it, +the preedit text without changing the content of it, the XIMText structure will contain a NULL value for the string field, the number of characters affected (relative to chg_first) will be in the length field, -and the feedback field will point to an array of +and the feedback field will point to an array of XIMFeedback. @@ -9407,8 +9407,8 @@ to agree with the values in the Consortium's X11R5 and X11R6 implementations. An input method may have its own navigation keys to allow the user -to move the text insertion point in the preedit area -(for example, to move backward or forward). +to move the text insertion point in the preedit area +(for example, to move backward or forward). Consequently, input method needs to indicate to the client that it should move the text insertion point. It then calls the PreeditCaretCallback. @@ -9461,12 +9461,12 @@ Specifies the preedit caret information. The input method will trigger PreeditCaretCallback to move the text insertion point during preedit. -The call_data argument contains a pointer to an +The call_data argument contains a pointer to an XIMPreeditCaretCallbackStruct structure, which indicates where the caret should be moved. The callback must move the insertion point to its new location -and return, in field position, the new offset value from the initial position. +and return, in field position, the new offset value from the initial position. @@ -9503,7 +9503,7 @@ structure is defined as follows: typedef enum { - XIMIsInvisible, /* Disable caret feedback */ + XIMIsInvisible, /* Disable caret feedback */ XIMIsPrimary, /* UI defined caret feedback */ XIMIsSecondary, /* UI defined caret feedback */ } XIMCaretStyle; @@ -9528,7 +9528,7 @@ typedef enum { XIMForwardWord, XIMBackwardWord, XIMCaretUp, XIMCaretDown, XIMNextLine, XIMPreviousLine, - XIMLineStart, XIMLineEnd, + XIMLineStart, XIMLineEnd, XIMAbsolutePosition, XIMDontChange, } XIMCaretDirection; @@ -9627,7 +9627,7 @@ callbacks: StatusStartCallback, StatusDoneCallback, and StatusDrawCallback. -When the input context is created or gains focus, +When the input context is created or gains focus, the input method calls the StatusStartCallback callback. StatusStartCallback @@ -9677,7 +9677,7 @@ Not used for this callback and always passed as NULL. The callback should initialize appropriate data for displaying status -and for responding to StatusDrawCallback calls. +and for responding to StatusDrawCallback calls. Once StatusStartCallback is called, it will not be called again before StatusDoneCallback has been called. @@ -9733,7 +9733,7 @@ Not used for this callback and always passed as NULL. -The callback may release any data allocated on +The callback may release any data allocated on StatusStart. @@ -9854,9 +9854,9 @@ Xlib provides the ability for an input method to register a filter internal to Xlib. This filter is called by a client (or toolkit) by calling -after calling +after calling . -Any client that uses the +Any client that uses the XIM interface should call @@ -9870,7 +9870,7 @@ of event filters with respect to other event-handling mechanisms Clients may not know how many filters there are, if any, and what they do. -They may only know if an event has been filtered on return of +They may only know if an event has been filtered on return of . Clients should discard filtered events. @@ -10106,13 +10106,13 @@ begins in the initial state of the encoding of the locale To insure proper input processing, -it is essential that the client pass only +it is essential that the client pass only KeyPress events to and . -Their behavior when a client passes a +Their behavior when a client passes a KeyRelease event is undefined. @@ -10122,7 +10122,7 @@ event is undefined. Clients should check the status_return argument before using the other returned values. -These two functions both return a value to status_return +These two functions both return a value to status_return that indicates what has been returned in the other arguments. The possible values returned are: @@ -10148,7 +10148,7 @@ The possible values returned are: XLookupNone No consistent input has been composed so far. - The contents of buffer_return and keysym_return are not modified, + The contents of buffer_return and keysym_return are not modified, and the function returns zero. @@ -10227,14 +10227,14 @@ or raise an exception or error of some sort. -A +A KeyPress event with a KeyCode of zero is used exclusively as a signal that an input method has composed input that can be returned by or . -No other use is made of a +No other use is made of a KeyPress event with KeyCode of zero. @@ -10258,7 +10258,7 @@ onto a client's event queue -A +A KeyPress event whose KeyCode value is modified by an input method filter diff --git a/specs/libX11/CH14.xml b/specs/libX11/CH14.xml index 03bb85c2..e4c0f11f 100644 --- a/specs/libX11/CH14.xml +++ b/specs/libX11/CH14.xml @@ -89,7 +89,7 @@ managers are: Additional hints set by the client for use by the window manager. The C type of this property is XWMHints. - + WM_ICON_NAME @@ -127,7 +127,7 @@ managers are: WM_PROTOCOLS ATOM 32 - List of atoms that identify the + List of atoms that identify the communications protocols between the client and window manager in which the client is willing to participate. @@ -145,7 +145,7 @@ managers are: WM_TRANSIENT_FOR WINDOW 32 - Set by application programs to + Set by application programs to indicate to the window manager that a transient top-level window, such as a dialog box. @@ -249,7 +249,7 @@ Use window manager convenience functions Xlib provides functions that you can use to change the visibility or size -of top-level windows (that is, those that were created as children +of top-level windows (that is, those that were created as children of the root window). Note that the subwindows that you create are ignored by window managers. Therefore, @@ -308,11 +308,11 @@ Specifies the appropriate screen number on the host server. -The +The -function sends a WM_CHANGE_STATE +function sends a WM_CHANGE_STATE ClientMessage -event with a format of 32 and a first data element of +event with a format of 32 and a first data element of IconicState (as described in section 4.1.4 of the @@ -323,9 +323,9 @@ with an event mask set to SubstructureNotifyMask | SubstructureRedirectMask. Window managers may elect to receive this message and -if the window is in its normal state, +if the window is in its normal state, may treat it as a request to change the window's state from normal to iconic. -If the WM_CHANGE_STATE property cannot be interned, +If the WM_CHANGE_STATE property cannot be interned, does not send a message and returns a zero status. It returns a nonzero status if the client message is sent successfully; @@ -383,19 +383,19 @@ Specifies the appropriate screen number on the host server. -The +The -function unmaps the specified window -and sends a synthetic +function unmaps the specified window +and sends a synthetic UnmapNotify event to the root window of the specified screen. -Window managers may elect to receive this message +Window managers may elect to receive this message and may treat it as a request to change the window's state to withdrawn. -When a window is in the withdrawn state, +When a window is in the withdrawn state, neither its normal nor its iconic representations is visible. -It returns a nonzero status if the +It returns a nonzero status if the UnmapNotify -event is successfully sent; +event is successfully sent; otherwise, it returns a zero status. @@ -473,7 +473,7 @@ This mask is the bitwise inclusive OR of the valid configure window values bits. -Specifies the +Specifies the XWindowChanges structure. @@ -483,19 +483,19 @@ structure. -The +The -function issues a +function issues a ConfigureWindow request on the specified top-level window. -If the stacking mode is changed and the request fails with a +If the stacking mode is changed and the request fails with a BadMatch -error, -the error is trapped by Xlib and a synthetic +error, +the error is trapped by Xlib and a synthetic ConfigureRequestEvent -containing the same configuration parameters is sent to the root +containing the same configuration parameters is sent to the root of the specified window. -Window managers may elect to receive this event +Window managers may elect to receive this event and treat it as a request to reconfigure the indicated window. It returns a nonzero status if the request or event is successfully sent; otherwise, it returns a zero status. @@ -505,7 +505,7 @@ otherwise, it returns a zero status. can generate BadValue -and +and BadWindow errors. @@ -521,7 +521,7 @@ Many of the text properties allow a variety of types and formats. Because the data stored in these properties are not simple null-terminated strings, an XTextProperty -structure is used to describe the encoding, type, and length of the text +structure is used to describe the encoding, type, and length of the text as well as its value. The XTextProperty @@ -544,13 +544,13 @@ typedef struct { Xlib provides functions to convert localized text to or from encodings that support the inter-client communication conventions for text. -In addition, functions are provided for converting between lists of pointers +In addition, functions are provided for converting between lists of pointers to character strings and text properties in the STRING encoding. -The functions for localized text return a signed integer error status -that encodes +The functions for localized text return a signed integer error status +that encodes Success as zero, specific error conditions as negative numbers, and partial conversion as a count of unconvertible characters. @@ -577,7 +577,7 @@ typedef enum { -To convert a list of text strings to an +To convert a list of text strings to an XTextProperty structure, use @@ -670,32 +670,32 @@ The and -functions set the specified +functions set the specified XTextProperty value to a set of null-separated elements representing the concatenation of the specified list of null-terminated text strings. -A final terminating null is stored at the end of the value field +A final terminating null is stored at the end of the value field of text_prop_return but is not included in the nitems member. The functions set the encoding field of text_prop_return to an Atom -for the specified display +for the specified display naming the encoding determined by the specified style and convert the specified text list to this encoding for storage in the text_prop_return value field. -If the style +If the style XStringStyle -or +or XCompoundTextStyle is specified, this encoding is ``STRING'' or ``COMPOUND_TEXT'', respectively. -If the style +If the style XTextStyle is specified, this encoding is the encoding of the current locale. -If the style +If the style XStdICCTextStyle is specified, this encoding is ``STRING'' if the text is fully convertible to STRING, @@ -704,10 +704,10 @@ else ``COMPOUND_TEXT''. If insufficient memory is available for the new value string, -the functions return +the functions return XNoMemory. If the current locale is not supported, -the functions return +the functions return XLocaleNotSupported. In both of these error cases, the functions do not set text_prop_return. @@ -725,9 +725,9 @@ If the supplied text is not fully convertible to the specified encoding, the functions return the number of unconvertible characters. Each unconvertible character is converted to an implementation-defined and encoding-specific default string. -Otherwise, the functions return +Otherwise, the functions return Success. -Note that full convertibility to all styles except +Note that full convertibility to all styles except XStringStyle is guaranteed. @@ -739,7 +739,7 @@ To free the storage for the value field, use -To obtain a list of text strings from an +To obtain a list of text strings from an XTextProperty structure, use @@ -816,9 +816,9 @@ Returns the number of strings. -The +The -and +and functions return a list of text strings in the current locale representing the null-separated elements of the specified @@ -839,12 +839,12 @@ If insufficient memory is available for the list and its elements, and -return +return XNoMemory. If the current locale is not supported, the functions return XLocaleNotSupported. -Otherwise, if the encoding field of text_prop is not convertible +Otherwise, if the encoding field of text_prop is not convertible to the encoding of the current locale, the functions return XConverterNotFound. @@ -852,7 +852,7 @@ For supported locales, existence of a converter from COMPOUND_TEXT, STRING or the encoding of the current locale is guaranteed if XSupportsLocale -returns +returns True for the current locale (but the actual text may contain unconvertible characters). @@ -862,7 +862,7 @@ the functions do not set any return values. -Otherwise, +Otherwise, and @@ -876,14 +876,14 @@ the current locale, the functions return the number of unconvertible characters. Each unconvertible character is converted to a string in the current locale that is specific to the current locale. -To obtain the value of this string, +To obtain the value of this string, use XDefaultString. Otherwise, and -return +return Success. @@ -952,9 +952,9 @@ use The XDefaultString function returns the default string used by Xlib for text conversion -(for example, in +(for example, in ). -The default string is the string in the current locale that is output +The default string is the string in the current locale that is output when an unconvertible character is found during text conversion. If the string returned by XDefaultString @@ -965,10 +965,10 @@ does not return NULL. -The string returned by +The string returned by XDefaultString is independent of the default string for text drawing; -see +see to obtain the default string for an XFontSet. @@ -988,7 +988,7 @@ Until freed, it will not be modified by Xlib. -To set the specified list of strings in the STRING encoding to a +To set the specified list of strings in the STRING encoding to a XTextProperty structure, use . @@ -1041,22 +1041,22 @@ structure. -The +The -function sets the specified +function sets the specified XTextProperty to be of type STRING (format 8) with a value representing the concatenation of the specified list of null-separated character strings. -An extra null byte (which is not included in the nitems member) +An extra null byte (which is not included in the nitems member) is stored at the end of the value field of text_prop_return. The strings are assumed (without verification) to be in the STRING encoding. -If insufficient memory is available for the new value string, +If insufficient memory is available for the new value string, does not set any fields in the XTextProperty structure and returns a zero status. Otherwise, it returns a nonzero status. -To free the storage for the value field, use +To free the storage for the value field, use . @@ -1115,22 +1115,22 @@ Returns the number of strings. -The +The -function returns a list of strings representing the null-separated elements +function returns a list of strings representing the null-separated elements of the specified XTextProperty structure. -The data in text_prop must be of type STRING and format 8. -Multiple elements of the property -(for example, the strings in a disjoint text selection) +The data in text_prop must be of type STRING and format 8. +Multiple elements of the property +(for example, the strings in a disjoint text selection) are separated by NULL (encoding 0). The contents of the property are not null-terminated. -If insufficient memory is available for the list and its elements, +If insufficient memory is available for the list and its elements, sets no return values and returns a zero status. Otherwise, it returns a nonzero status. -To free the storage for the list and its contents, use +To free the storage for the list and its contents, use . @@ -1163,13 +1163,13 @@ Specifies the list of strings to be freed. -The +The -function releases memory allocated by +function releases memory allocated by and -and the missing charset list allocated by +and the missing charset list allocated by . @@ -1185,7 +1185,7 @@ the text properties for a given window. You can use these functions to set and read those properties of type TEXT (WM_NAME, WM_ICON_NAME, WM_COMMAND, and WM_CLIENT_MACHINE). In addition, -Xlib provides separate convenience functions that you can use to set each +Xlib provides separate convenience functions that you can use to set each of these properties. For further information about these convenience functions, see sections @@ -1262,9 +1262,9 @@ Specifies the property name. The -function replaces the existing specified property for the named window -with the data, type, format, and number of items determined -by the value field, the encoding field, the format field, +function replaces the existing specified property for the named window +with the data, type, format, and number of items determined +by the value field, the encoding field, the format field, and the nitems field, respectively, of the specified XTextProperty structure. @@ -1279,7 +1279,7 @@ can generate BadAlloc, BadAtom, BadValue, -and +and BadWindow errors. @@ -1356,18 +1356,18 @@ and stores the data in the returned structure. It stores the data in the value field, the type of the data in the encoding field, -the format of the data in the format field, +the format of the data in the format field, and the number of items of data in the nitems field. -An extra byte containing null (which is not included in the nitems member) +An extra byte containing null (which is not included in the nitems member) is stored at the end of the value field of text_prop_return. -The particular interpretation of the property's encoding +The particular interpretation of the property's encoding and data as text is left to the calling application. If the specified property does not exist on the window, -sets the value field to NULL, +sets the value field to NULL, the encoding field to None, -the format field to zero, +the format field to zero, and the nitems field to zero. @@ -1376,7 +1376,7 @@ If it was able to read and store the data in the XTextProperty structure, -returns a nonzero status; +returns a nonzero status; otherwise, it returns a zero status. @@ -1384,7 +1384,7 @@ otherwise, it returns a zero status. can generate BadAtom -and +and BadWindow errors. @@ -1396,7 +1396,7 @@ errors. -Xlib provides convenience functions that you can use to set and read +Xlib provides convenience functions that you can use to set and read the WM_NAME property for a given window. @@ -1527,8 +1527,8 @@ The following two functions have been superseded by and , -respectively. -You can use these additional convenience functions +respectively. +You can use these additional convenience functions for window names that are encoded as STRING properties. @@ -1661,7 +1661,7 @@ The function returns the name of the specified window. If it succeeds, -it returns a nonzero status; +it returns a nonzero status; otherwise, no name has been set for the window, and it returns zero. If the WM_NAME property has not been set for this window, @@ -1689,7 +1689,7 @@ error. -Xlib provides convenience functions that you can use to set and read +Xlib provides convenience functions that you can use to set and read the WM_ICON_NAME property for a given window. @@ -1808,7 +1808,7 @@ structure. -The +The convenience function calls @@ -1823,7 +1823,7 @@ The next two functions have been superseded by and , respectively. -You can use these additional convenience functions +You can use these additional convenience functions for window names that are encoded as STRING properties. @@ -1946,7 +1946,7 @@ which is a null-terminated string. The function returns the name to be displayed in the specified window's icon. -If it succeeds, it returns a nonzero status; otherwise, +If it succeeds, it returns a nonzero status; otherwise, if no icon name has been set for the window, it returns zero. If you never assigned a name to the window, @@ -1974,7 +1974,7 @@ error. -Xlib provides functions that you can use to set and read +Xlib provides functions that you can use to set and read the WM_HINTS property for a given window. These functions use the flags and the XWMHints @@ -2012,7 +2012,7 @@ structure. Note that all fields in the XWMHints structure are initially set to zero. -If insufficient memory is available, +If insufficient memory is available, XAllocWMHints returns NULL. To free the memory allocated to this structure, @@ -2062,35 +2062,35 @@ typedef struct { The input member is used to communicate to the window manager the input focus model used by the application. -Applications that expect input but never explicitly set focus to any -of their subwindows (that is, use the push model of focus management), +Applications that expect input but never explicitly set focus to any +of their subwindows (that is, use the push model of focus management), such as X Version 10 style applications that use real-estate -driven focus, should set this member to +driven focus, should set this member to True. Similarly, applications that set input focus to their subwindows only when it is given to their -top-level window by a window manager should also set this member to +top-level window by a window manager should also set this member to True. Applications that manage their own input focus by explicitly setting -focus to one of their subwindows whenever they want keyboard input -(that is, use the pull model of focus management) should set this member to +focus to one of their subwindows whenever they want keyboard input +(that is, use the pull model of focus management) should set this member to False. Applications that never expect any keyboard input also should set this member -to +to False. Pull model window managers should make it possible for push model applications to get input by setting input focus to the top-level windows of -applications whose input member is +applications whose input member is True. Push model window managers should -make sure that pull model applications do not break them -by resetting input focus to +make sure that pull model applications do not break them +by resetting input focus to PointerRoot when it is appropriate (for example, whenever an application whose -input member is +input member is False sets input focus to one of its subwindows). @@ -2107,14 +2107,14 @@ The definitions for the initial_state flag are: The icon_mask specifies which pixels of the icon_pixmap should be used as the -icon. +icon. This allows for nonrectangular icons. Both icon_pixmap and icon_mask must be bitmaps. The icon_window lets an application provide a window for use as an icon for window managers that support such use. The window_group lets you specify that this window belongs to a group of other windows. -For example, if a single application manipulates multiple +For example, if a single application manipulates multiple top-level windows, this allows you to provide enough information that a window manager can iconify all of the windows rather than just the one window. @@ -2175,7 +2175,7 @@ Specifies the window. -Specifies the +Specifies the XWMHints structure to be used. @@ -2243,9 +2243,9 @@ Specifies the window. The -function reads the window manager hints and -returns NULL if no WM_HINTS property was set on the window -or returns a pointer to an +function reads the window manager hints and +returns NULL if no WM_HINTS property was set on the window +or returns a pointer to an XWMHints structure if it succeeds. When finished with the data, @@ -2267,7 +2267,7 @@ error. -Xlib provides functions that you can use to set or read +Xlib provides functions that you can use to set or read the WM_NORMAL_HINTS property for a given window. The functions use the flags and the XSizeHints @@ -2316,7 +2316,7 @@ structure. Note that all fields in the XSizeHints structure are initially set to zero. -If insufficient memory is available, +If insufficient memory is available, XAllocSizeHints returns NULL. To free the memory allocated to this structure, @@ -2379,19 +2379,19 @@ The max_width and max_height members specify the maximum window size. The width_inc and height_inc members define an arithmetic progression of sizes (minimum to maximum) into which the window prefers to be resized. The min_aspect and max_aspect members are expressed -as ratios of x and y, +as ratios of x and y, and they allow an application to specify the range of aspect ratios it prefers. The base_width and base_height members define the desired size of the window. -The window manager will interpret the position of the window -and its border width to position the point of the outer rectangle +The window manager will interpret the position of the window +and its border width to position the point of the outer rectangle of the overall window specified by the win_gravity member. The outer rectangle of the window includes any borders or decorations supplied by the window manager. In other words, if the window manager decides to place the window where the client asked, -the position on the parent window's border named by the win_gravity -will be placed where the client window would have been placed +the position on the parent window's border named by the win_gravity +will be placed where the client window would have been placed in the absence of a window manager. @@ -2452,9 +2452,9 @@ Specifies the size hints for the window in its normal state. -The +The -function replaces the size hints for the WM_NORMAL_HINTS property +function replaces the size hints for the WM_NORMAL_HINTS property on the specified window. If the property does not already exist, @@ -2533,26 +2533,26 @@ Returns the hints that were supplied by the user. -The +The -function returns the size hints stored in the WM_NORMAL_HINTS property +function returns the size hints stored in the WM_NORMAL_HINTS property on the specified window. If the property is of type WM_SIZE_HINTS, is of format 32, -and is long enough to contain either an old (pre-ICCCM) -or new size hints structure, +and is long enough to contain either an old (pre-ICCCM) +or new size hints structure, -sets the various fields of the +sets the various fields of the XSizeHints -structure, sets the supplied_return argument to the list of fields +structure, sets the supplied_return argument to the list of fields that were supplied by the user (whether or not they contained defined values), and returns a nonzero status. Otherwise, it returns a zero status. -If +If -returns successfully and a pre-ICCCM size hints property is read, +returns successfully and a pre-ICCCM size hints property is read, the supplied_return argument will contain the following bits: @@ -2564,8 +2564,8 @@ the supplied_return argument will contain the following bits: -If the property is large enough to contain the base size -and window gravity fields as well, +If the property is large enough to contain the base size +and window gravity fields as well, the supplied_return argument will also contain the following bits: @@ -2646,17 +2646,17 @@ Specifies the property name. -The +The -function replaces the size hints for the specified property +function replaces the size hints for the specified property on the named window. If the specified property does not already exist, sets the size hints for the specified property on the named window. The property is stored with a type of WM_SIZE_HINTS and a format of 32. -To set a window's normal size hints, -you can use the +To set a window's normal size hints, +you can use the function. @@ -2666,7 +2666,7 @@ function. can generate BadAlloc, BadAtom, -and +and BadWindow errors. @@ -2746,31 +2746,31 @@ Specifies the property name. -The +The -function returns the size hints stored in the specified property +function returns the size hints stored in the specified property on the named window. -If the property is of type WM_SIZE_HINTS, is of format 32, -and is long enough to contain either an old (pre-ICCCM) -or new size hints structure, +If the property is of type WM_SIZE_HINTS, is of format 32, +and is long enough to contain either an old (pre-ICCCM) +or new size hints structure, -sets the various fields of the +sets the various fields of the XSizeHints structure, sets the supplied_return argument to the -list of fields that were supplied by the user -(whether or not they contained defined values), +list of fields that were supplied by the user +(whether or not they contained defined values), and returns a nonzero status. Otherwise, it returns a zero status. -To get a window's normal size hints, -you can use the +To get a window's normal size hints, +you can use the function. -If +If -returns successfully and a pre-ICCCM size hints property is read, +returns successfully and a pre-ICCCM size hints property is read, the supplied_return argument will contain the following bits: @@ -2782,8 +2782,8 @@ the supplied_return argument will contain the following bits: -If the property is large enough to contain the base size -and window gravity fields as well, +If the property is large enough to contain the base size +and window gravity fields as well, the supplied_return argument will also contain the following bits: @@ -2797,7 +2797,7 @@ PBaseSize|PWinGravity can generate BadAtom -and +and BadWindow errors. @@ -2809,7 +2809,7 @@ errors. -Xlib provides functions that you can use to set and get +Xlib provides functions that you can use to set and get the WM_CLASS property for a given window. These functions use the XClassHint @@ -2849,7 +2849,7 @@ structure. Note that the pointer fields in the XClassHint structure are initially set to NULL. -If insufficient memory is available, +If insufficient memory is available, XAllocClassHint returns NULL. To free the memory allocated to this structure, @@ -2878,15 +2878,15 @@ typedef struct { -The res_name member contains the application name, -and the res_class member contains the application class. +The res_name member contains the application name, +and the res_class member contains the application class. Note that the name set in this property may differ from the name set as WM_NAME. That is, WM_NAME specifies what should be displayed in the title bar and, therefore, can contain temporal information (for example, the name of a file currently in an editor's buffer). -On the other hand, +On the other hand, the name specified as part of WM_CLASS is the formal name of the application -that should be used when retrieving the application's resources from the +that should be used when retrieving the application's resources from the resource database. @@ -2956,7 +2956,7 @@ can generate BadAlloc and BadWindow -errors. +errors. @@ -3002,7 +3002,7 @@ Specifies the window. -Returns the +Returns the XClassHint structure. @@ -3098,7 +3098,7 @@ Specifies the window that the WM_TRANSIENT_FOR property is The -function sets the WM_TRANSIENT_FOR property of the specified window to the +function sets the WM_TRANSIENT_FOR property of the specified window to the specified prop_window. @@ -3249,16 +3249,16 @@ Specifies the number of protocols in the list. -The +The -function replaces the WM_PROTOCOLS property on the specified window +function replaces the WM_PROTOCOLS property on the specified window with the list of atoms specified by the protocols argument. If the property does not already exist, sets the WM_PROTOCOLS property on the specified window to the list of atoms specified by the protocols argument. The property is stored with a type of ATOM and a format of 32. -If it cannot intern the WM_PROTOCOLS atom, +If it cannot intern the WM_PROTOCOLS atom, returns a zero status. Otherwise, it returns a nonzero status. @@ -3335,17 +3335,17 @@ Returns the number of protocols in the list. -The +The -function returns the list of atoms stored in the WM_PROTOCOLS property +function returns the list of atoms stored in the WM_PROTOCOLS property on the specified window. -These atoms describe window manager protocols in which the owner +These atoms describe window manager protocols in which the owner of this window is willing to participate. -If the property exists, is of type ATOM, is of format 32, -and the atom WM_PROTOCOLS can be interned, +If the property exists, is of type ATOM, is of format 32, +and the atom WM_PROTOCOLS can be interned, -sets the protocols_return argument to a list of atoms, -sets the count_return argument to the number of elements in the list, +sets the protocols_return argument to a list of atoms, +sets the count_return argument to the number of elements in the list, and returns a nonzero status. Otherwise, it sets neither of the return arguments and returns a zero status. @@ -3433,7 +3433,7 @@ Specifies the number of windows in the list. -The +The function replaces the WM_COLORMAP_WINDOWS property on the specified window with the list of windows specified by the colormap_windows argument. @@ -3519,17 +3519,17 @@ Returns the number of windows in the list. -The +The -function returns the list of window identifiers stored +function returns the list of window identifiers stored in the WM_COLORMAP_WINDOWS property on the specified window. These identifiers indicate the colormaps that the window manager may need to install for this window. -If the property exists, is of type WINDOW, is of format 32, -and the atom WM_COLORMAP_WINDOWS can be interned, +If the property exists, is of type WINDOW, is of format 32, +and the atom WM_COLORMAP_WINDOWS can be interned, -sets the windows_return argument to a list of window identifiers, -sets the count_return argument to the number of elements in the list, +sets the windows_return argument to a list of window identifiers, +sets the count_return argument to the number of elements in the list, and returns a nonzero status. Otherwise, it sets neither of the return arguments and returns a zero status. @@ -3551,9 +3551,9 @@ error. -Xlib provides functions that you can use to set and read +Xlib provides functions that you can use to set and read the WM_ICON_SIZE property for a given window. -These functions use the +These functions use the XIconSize XIconSize structure, which is defined in the @@ -3590,7 +3590,7 @@ structure. Note that all fields in the XIconSize structure are initially set to zero. -If insufficient memory is available, +If insufficient memory is available, XAllocIconSize returns NULL. To free the memory allocated to this structure, @@ -3793,7 +3793,7 @@ error. -The +The function stores the standard set of window manager properties, with text properties in standard encodings @@ -3922,8 +3922,8 @@ structure to be used. The -convenience function provides a simple programming interface -for setting those essential window properties that are used +convenience function provides a simple programming interface +for setting those essential window properties that are used for communicating with other clients (particularly window and session managers). @@ -3938,8 +3938,8 @@ sets the WM_ICON_NAME property. The window_name and icon_name arguments are null-terminated strings in the encoding of the current locale. If the arguments can be fully converted to the STRING encoding, -the properties are created with type ``STRING''; -otherwise, the arguments are converted to Compound Text, +the properties are created with type ``STRING''; +otherwise, the arguments are converted to Compound Text, and the properties are created with type ``COMPOUND_TEXT''. @@ -3950,7 +3950,7 @@ calls , which sets the WM_NORMAL_HINTS property (see section 14.1.7). -If the wm_hints argument is non-NULL, +If the wm_hints argument is non-NULL, calls , @@ -3966,7 +3966,7 @@ An argc of zero indicates a zero-length command. -The hostname of the machine is stored using +The hostname of the machine is stored using (see section 14.2.2). @@ -3975,7 +3975,7 @@ The hostname of the machine is stored using If the class_hints argument is non-NULL, sets the WM_CLASS property. -If the res_name member in the +If the res_name member in the XClassHint structure is set to the NULL pointer and the RESOURCE_NAME environment variable is set, @@ -4140,16 +4140,16 @@ structure to be used. -The +The -convenience function provides a single programming interface -for setting those essential window properties that are used +convenience function provides a single programming interface +for setting those essential window properties that are used for communicating with other clients (particularly window and session managers). -If the window_name argument is non-NULL, +If the window_name argument is non-NULL, calls , @@ -4161,7 +4161,7 @@ calls , which sets the WM_ICON_NAME property (see section 14.1.5). -If the argv argument is non-NULL, +If the argv argument is non-NULL, calls , @@ -4174,13 +4174,13 @@ Note also that the hostname of this machine is stored using -If the normal_hints argument is non-NULL, +If the normal_hints argument is non-NULL, calls , which sets the WM_NORMAL_HINTS property (see section 14.1.7). -If the wm_hints argument is non-NULL, +If the wm_hints argument is non-NULL, calls , @@ -4189,7 +4189,7 @@ which sets the WM_HINTS property -If the class_hints argument is non-NULL, +If the class_hints argument is non-NULL, calls , @@ -4197,12 +4197,12 @@ which sets the WM_CLASS property (see section 14.1.8). If the res_name member in the XClassHint -structure is set to the NULL pointer and the RESOURCE_NAME environment -variable is set, +structure is set to the NULL pointer and the RESOURCE_NAME environment +variable is set, then the value of the environment variable is substituted for res_name. -If the res_name member is NULL, -the environment variable is not set, -and argv and argv[0] are set, +If the res_name member is NULL, +the environment variable is not set, +and argv and argv[0] are set, then the value of argv[0], stripped of any directory prefixes, is substituted for res_name. @@ -4391,13 +4391,13 @@ Returns the number of arguments returned. -The +The -function reads the WM_COMMAND property from the specified window +function reads the WM_COMMAND property from the specified window and returns a string list. -If the WM_COMMAND property exists, +If the WM_COMMAND property exists, it is of type STRING and format 8. -If sufficient memory can be allocated to contain the string list, +If sufficient memory can be allocated to contain the string list, fills in the argv_return and argc_return arguments and returns a nonzero status. @@ -4416,7 +4416,7 @@ To free the memory allocated to the string list, use -Xlib provides functions that you can use to set and read +Xlib provides functions that you can use to set and read the WM_CLIENT_MACHINE property for a given window. @@ -4535,7 +4535,7 @@ structure. The -convenience function performs an +convenience function performs an on the WM_CLIENT_MACHINE property. It returns a nonzero status on success; @@ -4551,21 +4551,21 @@ otherwise, it returns a zero status. Applications with color palettes, smooth-shaded drawings, or digitized -images demand large numbers of colors. -In addition, these applications often require an efficient mapping +images demand large numbers of colors. +In addition, these applications often require an efficient mapping from color triples to pixel values that display the appropriate colors. -As an example, consider a three-dimensional display program that wants -to draw a smoothly shaded sphere. -At each pixel in the image of the sphere, +As an example, consider a three-dimensional display program that wants +to draw a smoothly shaded sphere. +At each pixel in the image of the sphere, the program computes the intensity and color of light -reflected back to the viewer. +reflected back to the viewer. The result of each computation is a triple of red, green, and blue (RGB) -coefficients in the range 0.0 to 1.0. +coefficients in the range 0.0 to 1.0. To draw the sphere, the program needs a colormap that provides a -large range of uniformly distributed colors. +large range of uniformly distributed colors. The colormap should be arranged so that the program can convert its RGB triples into pixel values very quickly, because drawing the entire sphere requires many such @@ -4574,25 +4574,25 @@ conversions. On many current workstations, -the display is limited to 256 or fewer colors. -Applications must allocate colors carefully, -not only to make sure they cover the entire range they need +the display is limited to 256 or fewer colors. +Applications must allocate colors carefully, +not only to make sure they cover the entire range they need but also to make use of as many of the available colors as possible. -On a typical X display, +On a typical X display, many applications are active at once. Most workstations have only one hardware look-up table for colors, so only one application colormap can be installed at a given time. -The application using the installed colormap is displayed correctly, +The application using the installed colormap is displayed correctly, and the other applications go technicolor and are displayed with false colors. -As another example, consider a user who is running an -image processing program to display earth-resources data. -The image processing program needs a colormap set up with 8 reds, +As another example, consider a user who is running an +image processing program to display earth-resources data. +The image processing program needs a colormap set up with 8 reds, 8 greens, and 4 blues, for a total of 256 colors. -Because some colors are already in use in the default colormap, +Because some colors are already in use in the default colormap, the image processing program allocates and installs a new colormap. @@ -4609,31 +4609,31 @@ install a new colormap. Because only one colormap can be installed at a time, the color palette may be displayed incorrectly whenever the image processing program is active. -Conversely, whenever the palette program is active, -the image may be displayed incorrectly. +Conversely, whenever the palette program is active, +the image may be displayed incorrectly. The user can never match or compare colors in the palette and image. Contention for colormap resources can be reduced if applications with similar color needs share colormaps. -The image processing program and the color palette program +The image processing program and the color palette program could share the same colormap if there existed a convention that described -how the colormap was set up. -Whenever either program was active, +how the colormap was set up. +Whenever either program was active, both would be displayed correctly. The standard colormap properties define a set of commonly used -colormaps. -Applications that share these colormaps and conventions display +colormaps. +Applications that share these colormaps and conventions display true colors more often and provide a better interface to the user. Standard colormaps allow applications to share commonly used color -resources. +resources. This allows many applications to be displayed in true colors simultaneously, even when each application needs an entirely filled colormap. @@ -4671,7 +4671,7 @@ structure. Note that all fields in the XStandardColormap structure are initially set to zero. -If insufficient memory is available, +If insufficient memory is available, XAllocStandardColormap returns NULL. To free the memory allocated to this structure, @@ -4680,7 +4680,7 @@ use -The +The XStandardColormap structure contains: @@ -4712,34 +4712,34 @@ The colormap member is the colormap created by the function. The red_max, green_max, and blue_max members give the maximum -red, green, and blue values, respectively. -Each color coefficient ranges from zero to its max, inclusive. +red, green, and blue values, respectively. +Each color coefficient ranges from zero to its max, inclusive. For example, a common colormap allocation is 3/3/2 (3 planes for red, 3 -planes for green, and 2 planes for blue). -This colormap would have red_max = 7, green_max = 7, -and blue_max = 3. -An alternate allocation that uses only 216 colors is red_max = 5, +planes for green, and 2 planes for blue). +This colormap would have red_max = 7, green_max = 7, +and blue_max = 3. +An alternate allocation that uses only 216 colors is red_max = 5, green_max = 5, and blue_max = 5. The red_mult, green_mult, and blue_mult members give the -scale factors used to compose a full pixel value. +scale factors used to compose a full pixel value. (See the discussion of the base_pixel members for further information.) For a 3/3/2 allocation, red_mult might be 32, -green_mult might be 4, and blue_mult might be 1. -For a 6-colors-each allocation, red_mult might be 36, +green_mult might be 4, and blue_mult might be 1. +For a 6-colors-each allocation, red_mult might be 36, green_mult might be 6, and blue_mult might be 1. The base_pixel member gives the base pixel value used to -compose a full pixel value. -Usually, the base_pixel is obtained from a call to the +compose a full pixel value. +Usually, the base_pixel is obtained from a call to the -function. -Given integer red, green, and blue coefficients in their appropriate +function. +Given integer red, green, and blue coefficients in their appropriate ranges, one then can compute a corresponding pixel value by using the following expression: @@ -4753,13 +4753,13 @@ using the following expression: -For +For GrayScale -colormaps, -only the colormap, red_max, red_mult, -and base_pixel members are defined. -The other members are ignored. -To compute a +colormaps, +only the colormap, red_max, red_mult, +and base_pixel members are defined. +The other members are ignored. +To compute a GrayScale pixel value, use the following expression: @@ -4786,7 +4786,7 @@ depending on the size of the integer type used to do the computation. The visualid member gives the ID number of the visual from which the colormap was created. The killid member gives a resource ID that indicates whether -the cells held by this standard colormap are to be released +the cells held by this standard colormap are to be released by freeing the colormap ID or by calling the function on the indicated resource. @@ -4794,9 +4794,9 @@ function on the indicated resource. -The properties containing the +The properties containing the XStandardColormap -information have +information have the type RGB_COLOR_MAP. @@ -4813,9 +4813,9 @@ as well as how to manipulate standard colormaps. Standard Colormaps Colormapsstandard -Several standard colormaps are available. -Each standard colormap is defined by a property, -and each such property is identified by an atom. +Several standard colormaps are available. +Each standard colormap is defined by a property, +and each such property is identified by an atom. The following list names the atoms and describes the colormap associated with each one. The @@ -4850,10 +4850,10 @@ with correct colors at all times. A typical allocation for the RGB_DEFAULT_MAP on 8-plane displays -is 6 reds, 6 greens, and 6 blues. -This gives 216 uniformly distributed colors -(6 intensities of 36 different hues) and still leaves 40 elements -of a 256-element colormap available for special-purpose colors +is 6 reds, 6 greens, and 6 blues. +This gives 216 uniformly distributed colors +(6 intensities of 36 different hues) and still leaves 40 elements +of a 256-element colormap available for special-purpose colors for text, borders, and so on. @@ -4862,7 +4862,7 @@ for text, borders, and so on. RGB_BEST_MAP -This atom names a property. The value of the property is an +This atom names a property. The value of the property is an XStandardColormap. @@ -4876,14 +4876,14 @@ This implies that there may be more green values available than red, as well as more green or red than blue. -For an 8-plane +For an 8-plane PseudoColor -visual, -RGB_BEST_MAP is likely to be a 3/3/2 allocation. -For a 24-plane +visual, +RGB_BEST_MAP is likely to be a 3/3/2 allocation. +For a 24-plane DirectColor -visual, -RGB_BEST_MAP is normally an 8/8/8 allocation. +visual, +RGB_BEST_MAP is normally an 8/8/8 allocation. @@ -4897,32 +4897,32 @@ The value of each property is an The properties define all-red, all-green, and all-blue -colormaps, respectively. -These maps are used by applications that want to make color-separated -images. -For example, a user might generate a full-color image -on an 8-plane display both by rendering an image three times -(once with high color resolution in red, once with green, +colormaps, respectively. +These maps are used by applications that want to make color-separated +images. +For example, a user might generate a full-color image +on an 8-plane display both by rendering an image three times +(once with high color resolution in red, once with green, and once with blue) and by multiply exposing a single frame in a camera. - + RGB_GRAY_MAP This atom names a property. -The value of the property is an +The value of the property is an XStandardColormap. -The property describes the best +The property describes the best GrayScale -colormap available on the screen. -As previously mentioned, +colormap available on the screen. +As previously mentioned, only the colormap, red_max, red_mult, and base_pixel members of the XStandardColormap -structure are used for +structure are used for GrayScale colormaps. @@ -5021,9 +5021,9 @@ Specifies the property name. -The +The -function replaces the RGB colormap definition in the specified property +function replaces the RGB colormap definition in the specified property on the named window. If the property does not already exist, @@ -5038,7 +5038,7 @@ restriction that only RGB_DEFAULT_MAP contain more than one definition. The function usually is only used by window or session managers. -To create a standard colormap, +To create a standard colormap, follow this procedure: @@ -5081,14 +5081,14 @@ Allocate cells in the colormap (or create it with -Call +Call to store appropriate color values in the colormap. -Fill in the descriptive members in the +Fill in the descriptive members in the XStandardColormap structure. @@ -5125,7 +5125,7 @@ errors. -To obtain the +To obtain the XStandardColormap structure associated with the specified property, use . @@ -5200,23 +5200,23 @@ Specifies the property name. -The +The -function returns the RGB colormap definitions stored +function returns the RGB colormap definitions stored in the specified property on the named window. -If the property exists, is of type RGB_COLOR_MAP, is of format 32, +If the property exists, is of type RGB_COLOR_MAP, is of format 32, and is long enough to contain a colormap definition, allocates and fills in space for the returned colormaps and returns a nonzero status. -If the visualid is not present, +If the visualid is not present, -assumes the default visual for the screen on which the window is located; -if the killid is not present, +assumes the default visual for the screen on which the window is located; +if the killid is not present, None is assumed, which indicates that the resources cannot be released. -Otherwise, -none of the fields are set, and +Otherwise, +none of the fields are set, and returns a zero status. Note that it is the caller's responsibility to honor the ICCCM diff --git a/specs/libX11/CH15.xml b/specs/libX11/CH15.xml index eb9760e7..f93dd8c2 100644 --- a/specs/libX11/CH15.xml +++ b/specs/libX11/CH15.xml @@ -28,11 +28,11 @@ and in server properties. The resource manager is a database manager with a twist. -In most database systems, +In most database systems, you perform a query using an imprecise specification, and you get back a set of records. The resource manager, however, allows you to specify a large -set of values with an imprecise specification, to query the database +set of values with an imprecise specification, to query the database with a precise specification, and to get back only a single value. This should be used by applications that need to know what the user prefers for colors, fonts, and other resources. @@ -42,9 +42,9 @@ although the resource manager can be and is used in other ways. -For example, -a user of your application may want to specify -that all windows should have a blue background +For example, +a user of your application may want to specify +that all windows should have a blue background but that all mail-reading windows should have a red background. With well-engineered and coordinated applications, a user can define this information using only two lines of specifications. @@ -75,24 +75,24 @@ and the first letter of name components is in lowercase. Each name and class finally has an attribute (for example, "foreground" or "font"). If each window is properly assigned a name and class, -it is easy for the user to specify attributes of any portion +it is easy for the user to specify attributes of any portion of the application. -At the top level, +At the top level, the application might consist of a paned window (that is, a window divided into several sections) named "toc". One pane of the paned window is a button box window named "buttons" -and is filled with command buttons. +and is filled with command buttons. One of these command buttons is used to incorporate new mail and has the name "incorporate". This window has a fully qualified name, "xmh.toc.buttons.incorporate", and a fully qualified class, "Xmh.Paned.Box.Command". -Its fully qualified name is the name of its parent, "xmh.toc.buttons", +Its fully qualified name is the name of its parent, "xmh.toc.buttons", followed by its name, "incorporate". -Its class is the class of its parent, "Xmh.Paned.Box", -followed by its particular class, "Command". +Its class is the class of its parent, "Xmh.Paned.Box", +followed by its particular class, "Command". The fully qualified name of a resource is the attribute's name appended to the object's fully qualified name, and the fully qualified class is its class appended to the object's @@ -100,7 +100,7 @@ class. -The incorporate button might need the following resources: +The incorporate button might need the following resources: Title string, Font, Foreground color for its inactive state, @@ -337,12 +337,12 @@ Most uses of the resource manager involve defining names, classes, and representation types as string constants. However, always referring to strings in the resource manager can be slow, because it is so heavily used in some toolkits. -To solve this problem, +To solve this problem, a shorthand for a string is used in place of the string in many of the resource manager functions. Simple comparisons can be performed rather than string comparisons. The shorthand name for a string is called a quark and is the -type +type XrmQuark. On some occasions, you may want to allocate a quark that has no string equivalent. @@ -471,7 +471,7 @@ all future calls will return the same value (identical address). -To convert a quark to a string, use +To convert a quark to a string, use . @@ -555,7 +555,7 @@ Specifies the string for which a quark list is to be allocated. Returns the list of quarks. -The caller must allocate sufficient space for the quarks list before calling +The caller must allocate sufficient space for the quarks list before calling . @@ -569,7 +569,7 @@ The function converts the null-terminated string (generally a fully qualified name) to a list of quarks. -Note that the string must be in the valid ResourceName format +Note that the string must be in the valid ResourceName format (see section 15.1). If the string is not in the Host Portable Character Encoding, the conversion is implementation-dependent. @@ -630,7 +630,7 @@ Specifies the string for which a quark list is to be allocated. Returns the binding list. -The caller must allocate sufficient space for the binding list before calling +The caller must allocate sufficient space for the binding list before calling . @@ -642,7 +642,7 @@ The caller must allocate sufficient space for the binding list before calling Returns the list of quarks. -The caller must allocate sufficient space for the quarks list before calling +The caller must allocate sufficient space for the quarks list before calling . @@ -651,11 +651,11 @@ The caller must allocate sufficient space for the quarks list before calling -Component names in the list are separated by a period or +Component names in the list are separated by a period or an asterisk character. The string must be in the format of a valid ResourceName (see section 15.1). -If the string does not start with a period or an asterisk, +If the string does not start with a period or an asterisk, a tight binding is assumed. For example, the string ``*a.b*c'' becomes: @@ -684,9 +684,9 @@ Each database value is stored in an structure. This structure consists of a size, an address, and a representation type. The size is specified in bytes. -The representation type is a way for you to store data tagged by some +The representation type is a way for you to store data tagged by some application-defined type (for example, the strings ``font'' or ``color''). -It has nothing to do with the C data type or with its class. +It has nothing to do with the C data type or with its class. The XrmValue structure is defined as: @@ -759,7 +759,7 @@ The specified file should contain a sequence of entries in valid ResourceLine format (see section 15.1); the database that results from reading a file with incorrect syntax is implementation-dependent. -The file is parsed in the current locale, +The file is parsed in the current locale, and the database is created in the current locale. If it cannot open the specified file, @@ -855,7 +855,7 @@ function returns the RESOURCE_MANAGER property from the server's root window of screen zero, which was returned when the connection was opened using . The property is converted from type STRING to the current locale. -The conversion is identical to that produced by +The conversion is identical to that produced by for a single element STRING property. The returned string is owned by Xlib and should not be freed by the client. @@ -898,7 +898,7 @@ The function returns the SCREEN_RESOURCES property from the root window of the specified screen. The property is converted from type STRING to the current locale. -The conversion is identical to that produced by +The conversion is identical to that produced by for a single element STRING property. The property value must be in a format that is acceptable to @@ -950,7 +950,7 @@ format (see section 15.1) terminated by a null character; the database that results from using a string with incorrect syntax is implementation-dependent. -The string is parsed in the current locale, +The string is parsed in the current locale, and the database is created in the current locale. @@ -1150,7 +1150,7 @@ Specifies the resource database file name. -Specifies the resource database into which the source +Specifies the resource database into which the source database is to be merged. @@ -1224,7 +1224,7 @@ Specifies the resource database that is to be merged into the target database. -Specifies the resource database into which the source +Specifies the resource database into which the source database is to be merged. @@ -1294,7 +1294,7 @@ Specifies the resource database that is to be merged into the target database. -Specifies the resource database into which the source +Specifies the resource database into which the source database is to be merged. @@ -1457,14 +1457,14 @@ Returns the value in the database. -The +The -and +and functions retrieve a resource from the specified database. Both take a fully qualified name/class pair, a destination resource representation, and the address of a value -(size/address pair). +(size/address pair). The value and returned type point into database memory; therefore, you must not modify the data. @@ -1473,18 +1473,18 @@ therefore, you must not modify the data. The database only frees or overwrites entries on , , -or +or . A client that is not storing new values into the database or -is not merging the database should be safe using the address passed +is not merging the database should be safe using the address passed back at any time until it exits. If a resource was found, both and -return +return True; -otherwise, they return +otherwise, they return False. @@ -1493,9 +1493,9 @@ otherwise, they return Most applications and toolkits do not make random probes into a resource database to fetch resources. The X toolkit access pattern for a resource database is quite stylized. -A series of from 1 to 20 probes is made with only the +A series of from 1 to 20 probes is made with only the last name/class differing in each probe. -The +The function is at worst a 2n algorithm, @@ -1560,7 +1560,7 @@ Specifies a list of resource classes. Returns a search list for further use. -The caller must allocate sufficient space for the list before calling +The caller must allocate sufficient space for the list before calling XrmQGetSearchList. @@ -1584,12 +1584,12 @@ The function takes a list of names and classes and returns a list of database levels where a match might occur. The returned list is in best-to-worst order and -uses the same algorithm as +uses the same algorithm as for determining precedence. If list_return was large enough for the search list, XrmQGetSearchList -returns +returns True; otherwise, it returns False. @@ -1597,7 +1597,7 @@ otherwise, it returns The size of the search list that the caller must allocate is -dependent upon the number of levels and wildcards in the resource specifiers +dependent upon the number of levels and wildcards in the resource specifiers that are stored in the database. The worst case length is 3n, @@ -1606,10 +1606,10 @@ components in names or classes. -When using +When using XrmQGetSearchList followed by multiple probes for resources with a common name and class prefix, -only the common prefix should be specified in the name and class list to +only the common prefix should be specified in the name and class list to XrmQGetSearchList. @@ -1689,11 +1689,11 @@ Returns the value in the database. The -function searches the specified database levels for the resource +function searches the specified database levels for the resource that is fully identified by the specified name and class. The search stops with the first match. -returns +returns True if the resource was found; otherwise, it returns @@ -1701,14 +1701,14 @@ otherwise, it returns -A call to +A call to XrmQGetSearchList -with a name and class list containing all but the last component -of a resource name followed by a call to +with a name and class list containing all but the last component +of a resource name followed by a call to -with the last component name and class returns the same database entry as +with the last component name and class returns the same database entry as -and +and with the fully qualified name and class. @@ -2275,7 +2275,7 @@ typedef enum { Note that XrmoptionSkipArg -is equivalent to +is equivalent to XrmoptionSkipNArgs with the XrmOptionDescRec.value @@ -2295,7 +2295,7 @@ typedef struct { char *option; /* Option specification string in argv */ char *specifier; /* Binding and resource name (sans application name) */ XrmOptionKind argKind; /* Which style of option it is */ - XPointer value; /* Value to provide if XrmoptionNoArg or + XPointer value; /* Value to provide if XrmoptionNoArg or \ \ \ XrmoptionSkipNArgs */ } XrmOptionDescRec, *XrmOptionDescList; @@ -2405,8 +2405,8 @@ Recognized options in the table are removed from argv, and entries are added to the specified resource database in the order they occur in argv. The table entries contain information on the option string, -the option name, the style of option, -and a value to provide if the option kind is +the option name, the style of option, +and a value to provide if the option kind is XrmoptionNoArg. The option names are compared byte-for-byte to arguments in argv, independent of any locale. @@ -2467,18 +2467,18 @@ static XrmOptionDescRec opTable[] = { In this table, if the -background (or -bg) option is used to set background colors, the stored resource specifier matches all -resources of attribute background. -If the -borderwidth option is used, +resources of attribute background. +If the -borderwidth option is used, the stored resource specifier applies only to border width attributes of class TopLevelShell (that is, outer-most windows, including -pop-up windows). +pop-up windows). If the -title option is used to set a window name, only the topmost application windows receive the resource. When parsing the command line, -any unique unambiguous abbreviation for an option name in the table is +any unique unambiguous abbreviation for an option name in the table is considered a match for the option. Note that uppercase and lowercase matter. diff --git a/specs/libX11/CH16.xml b/specs/libX11/CH16.xml index 59614f65..d7cdf332 100644 --- a/specs/libX11/CH16.xml +++ b/specs/libX11/CH16.xml @@ -73,7 +73,7 @@ Use the context manager As a group, -the functions discussed in this chapter provide the functionality that +the functions discussed in this chapter provide the functionality that is frequently needed and that spans toolkits. Many of these functions do not generate actual protocol requests to the server. @@ -116,7 +116,7 @@ To obtain a KeySym for the KeyCode of an event, use -Specifies the +Specifies the KeyPress or KeyRelease @@ -403,7 +403,7 @@ Standard KeySym names are obtained from by removing the XK_ prefix from each name. KeySyms that are not part of the Xlib standard also may be obtained with this function. -The set of KeySyms that are available in this manner +The set of KeySyms that are available in this manner and the mechanisms by which Xlib obtains them is implementation-dependent. @@ -458,7 +458,7 @@ returns a NULL. -You may want to test if a KeySym is, for example, +You may want to test if a KeySym is, for example, on the keypad or on one of the function keys. You can use KeySym macros to perform the following tests. @@ -507,7 +507,7 @@ Specifies the KeySym that is to be tested. IsFunctionKey -Returns +Returns True if the specified KeySym is a function key. @@ -586,7 +586,7 @@ Specifies the KeySym that is to be tested. IsMiscFunctionKey -Returns +Returns True if the specified KeySym is a miscellaneous function key. @@ -612,7 +612,7 @@ Specifies the KeySym that is to be tested. IsModifierKey -Returns +Returns True if the specified KeySym is a modifier key. @@ -636,7 +636,7 @@ Specifies the KeySym that is to be tested. IsPFKey -Returns +Returns True if the specified KeySym is a PF key. @@ -730,7 +730,7 @@ Returns the KeySym computed from the event if this argument is not NULL. -Specifies or returns the +Specifies or returns the XComposeStatus structure or NULL. @@ -848,7 +848,7 @@ Specifies the number of modifiers in the modifier list. -Specifies the string that is copied and will be returned by +Specifies the string that is copied and will be returned by . @@ -1004,7 +1004,7 @@ Specifically, this function lets you parse strings of the form: -[=][<width>{xX}<height>][{+-}<xoffset>{+-}<yoffset>] +[=][<width>{xX}<height>][{+-}<xoffset>{+-}<yoffset>] @@ -1022,8 +1022,8 @@ the result is implementation-dependent. The function returns a bitmask that indicates which of the four values (width, -height, xoffset, and yoffset) were actually found in the string -and whether the x and y values are negative. +height, xoffset, and yoffset) were actually found in the string +and whether the x and y values are negative. By convention, −0 is not equal to +0, because the user needs to be able to say ``position the window relative to the right or bottom edge.'' For each value found, the corresponding argument is updated. @@ -1036,19 +1036,19 @@ The bits are represented by XNegative, or YNegative -and are defined in +and are defined in <X11/Xutil.h>. X11/Xutil.h Files<X11/Xutil.h> Headers<X11/Xutil.h> -They will be set whenever one of the values is defined +They will be set whenever one of the values is defined or one of the signs is set. -If the function returns either the +If the function returns either the XValue -or +or YValue flag, you should place the window at the requested position. @@ -1195,12 +1195,12 @@ Returns the window gravity. -The +The -function combines any geometry information (given in the format used by +function combines any geometry information (given in the format used by ) -specified by the user and by the calling program with size hints -(usually the ones to be stored in WM_NORMAL_HINTS) and returns the position, +specified by the user and by the calling program with size hints +(usually the ones to be stored in WM_NORMAL_HINTS) and returns the position, size, and gravity (NorthWestGravity, NorthEastGravity, @@ -1208,26 +1208,26 @@ size, and gravity or SouthWestGravity) that describe the window. -If the base size is not set in the +If the base size is not set in the XSizeHints -structure, +structure, the minimum size is used if set. Otherwise, a base size of zero is assumed. -If no minimum size is set in the hints structure, +If no minimum size is set in the hints structure, the base size is used. -A mask (in the form returned by +A mask (in the form returned by ) -that describes which values came from the user specification +that describes which values came from the user specification and whether or not the position coordinates are relative to the right and bottom edges is returned. -Note that these coordinates will have already been accounted for +Note that these coordinates will have already been accounted for in the x_return and y_return values. -Note that invalid geometry specifications can cause a width or height +Note that invalid geometry specifications can cause a width or height of zero to be returned. -The caller may pass the address of the hints win_gravity field +The caller may pass the address of the hints win_gravity field as gravity_return to update the hints directly. @@ -1240,9 +1240,9 @@ as gravity_return to update the hints directly. Regions are arbitrary sets of pixel locations. Xlib provides functions for manipulating regions. -The opaque type +The opaque type Region -is defined in +is defined in <X11/Xutil.h>. X11/Xutil.h Files<X11/Xutil.h> @@ -1332,7 +1332,7 @@ Specifies an array of points. -Specifies the number of points in the polygon. +Specifies the number of points in the polygon. @@ -1343,7 +1343,7 @@ Specifies the number of points in the polygon. Specifies the fill-rule you want to set for the specified GC. -You can pass +You can pass EvenOddRule or WindingRule. @@ -1461,7 +1461,7 @@ Specifies the region. -To move a region by a specified amount, use +To move a region by a specified amount, use . XOffsetRegion @@ -1564,7 +1564,7 @@ which define the amount you want to shrink the specified region. -Positive values shrink the size of the region, +Positive values shrink the size of the region, and negative values expand the region. @@ -1837,7 +1837,7 @@ function subtracts srb from sra and stores the results in dr_return. -To calculate the difference between the union and intersection +To calculate the difference between the union and intersection of two regions, use . @@ -2038,7 +2038,7 @@ Specify the x and y coordinates, which define the point. The -function returns +function returns True if the point (x, y) is contained in the region r. @@ -2159,7 +2159,7 @@ and can be accessed as a ring or as explicit buffers (numbered 0 through 7). -To store data in cut buffer 0, use +To store data in cut buffer 0, use . XStoreBytes @@ -2298,7 +2298,7 @@ error. -To return data from cut buffer 0, use +To return data from cut buffer 0, use . XFetchBytes @@ -2350,7 +2350,7 @@ The client must free this storage when finished with it by calling -To return data from a specified cut buffer, use +To return data from a specified cut buffer, use . XFetchBuffer @@ -2401,14 +2401,14 @@ Specifies the buffer from which you want the stored data returned. The -function returns zero to the nbytes_return argument +function returns zero to the nbytes_return argument if there is no data in the buffer or if an invalid buffer is specified. -To rotate the cut buffers, use +To rotate the cut buffers, use . XRotateBuffers @@ -2449,7 +2449,7 @@ Specifies how much to rotate the cut buffers. The function rotates the cut -buffers, such that buffer 0 becomes buffer n, +buffers, such that buffer 0 becomes buffer n, buffer 1 becomes n + 1 mod 8, and so on. This cut buffer numbering is global to the display. Note that @@ -2467,7 +2467,7 @@ errors if any of the eight buffers have not been created. A single display can support multiple screens. -Each screen can have several different visual types supported +Each screen can have several different visual types supported at different depths. You can use the functions described in this section to determine which visual to use for your application. @@ -2591,7 +2591,7 @@ Returns the number of matching visual structures. The -function returns a list of visual structures that have attributes +function returns a list of visual structures that have attributes equal to the attributes specified by vinfo_template. If no visual structures match the template using the specified vinfo_mask, @@ -2696,9 +2696,9 @@ returns zero. Xlib provides several functions that perform basic operations on images. -All operations on images are defined using an +All operations on images are defined using an XImage -structure, +structure, as defined in <X11/Xlib.h>. X11/Xlib.h @@ -2718,32 +2718,32 @@ Rather, they are here to provide minimal functions on screen format images. The basic operations for getting and putting images are -and +and . -Note that no functions have been defined, as yet, to read and write images +Note that no functions have been defined, as yet, to read and write images to and from disk files. The XImage -structure describes an image as it exists in the client's memory. -The user can request that some of the members such as height, width, +structure describes an image as it exists in the client's memory. +The user can request that some of the members such as height, width, and xoffset be changed when the image is sent to the server. Note that bytes_per_line in concert with offset can be used to extract a subset of the image. Other members (for example, byte order, bitmap_unit, and so forth) -are characteristics of both the image and the server. +are characteristics of both the image and the server. If these members -differ between the image and the server, +differ between the image and the server, makes the appropriate conversions. The first byte of the first line of plane n must be located at the address (data + (n * height * bytes_per_line)). -For a description of the +For a description of the XImage structure, see section 8.7. @@ -2751,7 +2751,7 @@ see section 8.7 -To allocate an +To allocate an XImage structure and initialize it with image format values from a display, use . @@ -2817,7 +2817,7 @@ Specifies the format for the image. You can pass XYBitmap, XYPixmap, -or +or ZPixmap. @@ -2869,8 +2869,8 @@ Specifies the height of the image, in pixels. Specifies the quantum of a scanline (8, 16, or 32). -In other words, the start of one scanline is separated in client memory from -the start of the next scanline by an integer multiple of this many bits. +In other words, the start of one scanline is separated in client memory from +the start of the next scanline by an integer multiple of this many bits. @@ -2881,7 +2881,7 @@ the start of the next scanline by an integer multiple of this many bits. Specifies the number of bytes in the client image between -the start of one scanline and the start of the next. +the start of one scanline and the start of the next. @@ -2896,15 +2896,15 @@ function allocates the memory needed for an structure for the specified display but does not allocate space for the image itself. Rather, it initializes the structure byte-order, bit-order, and bitmap-unit -values from the display and returns a pointer to the +values from the display and returns a pointer to the XImage structure. The red, green, and blue mask values are defined for Z format images only -and are derived from the +and are derived from the Visual structure passed in. Other values also are passed in. -The offset permits the rapid displaying of the image without requiring each +The offset permits the rapid displaying of the image without requiring each scanline to be shifted into position. If you pass a zero value in bytes_per_line, Xlib assumes that the scanlines are contiguous @@ -2917,9 +2917,9 @@ Note that when the image is created using , or , -the destroy procedure that the +the destroy procedure that the -function calls frees both the image structure +function calls frees both the image structure and the data pointed to by the image structure. @@ -3242,10 +3242,10 @@ structure. Note that when the image is created using , , -or +or , the destroy procedure that this macro calls -frees both the image structure and the data pointed to by the image structure. +frees both the image structure and the data pointed to by the image structure. @@ -3256,7 +3256,7 @@ frees both the image structure and the data pointed to by the image structure. Xlib provides functions that you can use to read a bitmap from a file, -save a bitmap to a file, or create a bitmap. +save a bitmap to a file, or create a bitmap. This section describes those functions that transfer bitmaps to and from the client's file system, thus allowing their reuse in a later connection (for example, from an entirely different client or to a @@ -3402,20 +3402,20 @@ The function reads in a file containing a bitmap. The file is parsed in the encoding of the current locale. -The ability to read other than the standard format +The ability to read other than the standard format is implementation-dependent. -If the file cannot be opened, +If the file cannot be opened, -returns +returns BitmapOpenFailed. -If the file can be opened but does not contain valid bitmap data, -it returns +If the file can be opened but does not contain valid bitmap data, +it returns BitmapFileInvalid. If insufficient working storage is allocated, it returns BitmapNoMemory. If the file is readable and valid, -it returns +it returns BitmapSuccess. @@ -3423,10 +3423,10 @@ it returns returns the bitmap's height and width, as read from the file, to width_return and height_return. -It then creates a pixmap of the appropriate size, +It then creates a pixmap of the appropriate size, reads the bitmap data from the file into the pixmap, -and assigns the pixmap to the caller's variable bitmap. -The caller must free the bitmap using +and assigns the pixmap to the caller's variable bitmap. +The caller must free the bitmap using when finished. If name_x_hot and name_y_hot exist, @@ -3649,8 +3649,8 @@ function writes a bitmap out to a file in the X Version 11 format. The name used in the output file is derived from the file name by deleting the directory prefix. The file is written in the encoding of the current locale. -If the file cannot be opened for writing, -it returns +If the file cannot be opened for writing, +it returns BitmapOpenFailed. If insufficient memory is allocated, @@ -3805,7 +3805,7 @@ errors. -To include a bitmap written out by +To include a bitmap written out by XWriteBitmapFile in a program directly, as opposed to reading it in every time at run time, use @@ -3927,18 +3927,18 @@ errors. The context manager provides a way of associating data with an X resource ID -(mostly typically a window) in your program. +(mostly typically a window) in your program. Note that this is local to your program; the data is not stored in the server on a property list. Any amount of data in any number of pieces can be associated with a resource ID, -and each piece of data has a type associated with it. +and each piece of data has a type associated with it. The context manager requires knowledge of the resource ID and type to store or retrieve data. -Essentially, the context manager can be viewed as a two-dimensional, +Essentially, the context manager can be viewed as a two-dimensional, sparse array: one dimension is subscripted by the X resource ID and the other by a context type field. Each entry in the array contains a pointer to the data. @@ -4152,7 +4152,7 @@ Specifies the context type to which the data belongs. The -function deletes the entry for the given resource ID +function deletes the entry for the given resource ID and type from the data structure. This function returns the same error codes that diff --git a/specs/libX11/credits.xml b/specs/libX11/credits.xml index c3d1f738..5bc4c5f4 100644 --- a/specs/libX11/credits.xml +++ b/specs/libX11/credits.xml @@ -8,11 +8,11 @@ The design and implementation of the first 10 versions of X were primarily the work of three individuals: Robert Scheifler of the MIT Laboratory for Computer Science and Jim Gettys of Digital Equipment Corporation and Ron Newman of MIT, both at MIT -Project Athena. -X version 11, however, is the result of the efforts of +Project Athena. +X version 11, however, is the result of the efforts of dozens of individuals at almost as many locations and organizations. -At the risk of offending some of the players by exclusion, -we would like to acknowledge some of the people who deserve special credit +At the risk of offending some of the players by exclusion, +we would like to acknowledge some of the people who deserve special credit and recognition for their work on Xlib. Our apologies to anyone inadvertently overlooked. @@ -24,25 +24,25 @@ who contributed substantially to the design and implementation of the Version 11 Xlib interface. -Our thanks also goes to Ralph Swick (Project Athena and Digital) who kept +Our thanks also goes to Ralph Swick (Project Athena and Digital) who kept it all together for us during the early releases. He handled literally thousands of requests from people everywhere and saved the sanity of at least one of us. His calm good cheer was a foundation on which we could build. -Our thanks also goes to Todd Brunhoff (Tektronix) who was ``loaned'' -to Project Athena at exactly the right moment to provide very capable +Our thanks also goes to Todd Brunhoff (Tektronix) who was ``loaned'' +to Project Athena at exactly the right moment to provide very capable and much-needed assistance during the alpha and beta releases. He was responsible for the successful integration of sources from multiple sites; we would not have had a release without him. -Our thanks also goes to Al Mento and Al Wojtas of Digital's ULTRIX +Our thanks also goes to Al Mento and Al Wojtas of Digital's ULTRIX Documentation Group. With good humor and cheer, -they took a rough draft and made it an infinitely better and more useful +they took a rough draft and made it an infinitely better and more useful document. The work they have done will help many everywhere. We also would like to thank Hal Murray (Digital SRC) and @@ -50,13 +50,13 @@ Peter George (Digital VMS) who contributed much by proofreading the early drafts of this document. -Our thanks also goes to Jeff Dike (Digital UEG), Tom Benson, -Jackie Granfield, and Vince Orgovan (Digital VMS) who helped with the +Our thanks also goes to Jeff Dike (Digital UEG), Tom Benson, +Jackie Granfield, and Vince Orgovan (Digital VMS) who helped with the library utilities implementation; to Hania Gajewska (Digital UEG-WSL) who, along with Ellis Cohen (CMU and Siemens), was instrumental in the semantic design of the window manager properties; -and to Dave Rosenthal (Sun Microsystems) who also contributed to the protocol +and to Dave Rosenthal (Sun Microsystems) who also contributed to the protocol and provided the sample generic color frame buffer device-dependent code. @@ -65,24 +65,24 @@ as well. It is significant that the bug reports (and many fixes) during alpha and beta test came almost exclusively from just a few of the alpha testers, mostly hardware vendors -working on product implementations of X. +working on product implementations of X. The continued public -contribution of vendors and universities is certainly to the benefit +contribution of vendors and universities is certainly to the benefit of the entire X community. Our special thanks must go to Sam Fuller, Vice-President of Corporate -Research at Digital, who has remained committed to the widest public +Research at Digital, who has remained committed to the widest public availability of X and who made it possible to greatly supplement MIT's resources with the Digital staff in order to make version 11 a reality. Many of the people mentioned here are part of the Western Software Laboratory (Digital UEG-WSL) of the ULTRIX Engineering group -and work for Smokey Wallace, who has been vital to the project's success. -Others not mentioned here worked on the toolkit and are acknowledged +and work for Smokey Wallace, who has been vital to the project's success. +Others not mentioned here worked on the toolkit and are acknowledged in the X Toolkit documentation. -Of course, +Of course, we must particularly thank Paul Asente, formerly of Stanford University and now of Digital UEG-WSL, who wrote W, the predecessor to X, and Brian Reid, formerly of Stanford University and now of Digital WRL, @@ -137,8 +137,8 @@ Shoji Sugiyama (IBM), and Eiji Tosa (IBM). We are deeply indebted to Tatsuya Kato (NTT), Hiroshi Kuribayashi (OMRON), Seiji Kuwari (OMRON), Muneiyoshi Suzuki (NTT), and Li Yuhong (OMRON) for producing one of the first complete -sample implementation of the internationalization facilities, and -Hiromu Inukai (Nihon Sun), Takashi Fujiwara (Fujitsu), Hideki Hiura (Sun), +sample implementation of the internationalization facilities, and +Hiromu Inukai (Nihon Sun), Takashi Fujiwara (Fujitsu), Hideki Hiura (Sun), Yasuhiro Kawai (Oki Technosystems Laboratory), Kazunori Nishihara (Fuji Xerox), Masaki Takeuchi (Sony), Katsuhisa Yano (Toshiba), Makoto Wakamatsu (Sony Corporation) for producing the another complete @@ -147,7 +147,7 @@ sample implementation of the internationalization facilities. The principal authors (design and implementation) of the Xcms color management facilities are Al Tabayoyon (Tektronix) -and Chuck Adams (Tektronix). +and Chuck Adams (Tektronix). Joann Taylor (Tektronix), Bob Toole (Tektronix), and Keith Packard (MIT X Consortium) also contributed significantly to the design. Others who contributed are: @@ -186,19 +186,19 @@ Makoto Wakamatsu (Sony), Masaki Wakao (IBM), Katsuhisa Yano(Toshiba) and Jinsoo Yoon (KAIST). -The principal producers of the sample implementation of the -internationalization facilities are: +The principal producers of the sample implementation of the +internationalization facilities are: Jeffrey Bloomfield (Fujitsu OSSI), Takashi Fujiwara (Fujitsu), -Hideki Hiura (SunSoft), Yoshio Horiuchi (IBM), -Makoto Inada (Digital), Hiromu Inukai (Nihon SunSoft), -Song JaeKyung (KAIST), Riki Kawaguchi (Fujitsu), -Franky Ling (Digital), Hiroyuki Miyamoto (Digital), -Hidetoshi Tajima (HP), Toshimitsu Terazono (Fujitsu), -Makoto Wakamatsu (Sony), Masaki Wakao (IBM), +Hideki Hiura (SunSoft), Yoshio Horiuchi (IBM), +Makoto Inada (Digital), Hiromu Inukai (Nihon SunSoft), +Song JaeKyung (KAIST), Riki Kawaguchi (Fujitsu), +Franky Ling (Digital), Hiroyuki Miyamoto (Digital), +Hidetoshi Tajima (HP), Toshimitsu Terazono (Fujitsu), +Makoto Wakamatsu (Sony), Masaki Wakao (IBM), Shigeru Yamada (Fujitsu OSSI) and Katsuhisa Yano (Toshiba). -The coordinators of the integration, testing, and release of this +The coordinators of the integration, testing, and release of this implementation of the internationalization facilities are Nobuyuki Tanaka (Sony) and Makoto Wakamatsu (Sony). @@ -207,8 +207,8 @@ Others who have contributed to the architectural design or testing of the sample implementation of the internationalization facilities are: Hector Chan (Digital), Michael Kung (IBM), Joseph Kwok (Digital), -Hiroyuki Machida (Sony), Nelson Ng (SunSoft), Frank Rojas (IBM), -Yoshiyuki Segawa (Fujitsu OSSI), Makiko Shimamura (Fujitsu), +Hiroyuki Machida (Sony), Nelson Ng (SunSoft), Frank Rojas (IBM), +Yoshiyuki Segawa (Fujitsu OSSI), Makiko Shimamura (Fujitsu), Shoji Sugiyama (IBM), Lining Sun (SGI), Masaki Takeuchi (Sony), Jinsoo Yoon (KAIST) and Akiyasu Zen (HP). diff --git a/specs/libX11/glossary.xml b/specs/libX11/glossary.xml index 14ad2e2d..c84b67b6 100644 --- a/specs/libX11/glossary.xml +++ b/specs/libX11/glossary.xml @@ -8,15 +8,15 @@ Access control list -X maintains a list of hosts from which client programs can be run. -By default, +X maintains a list of hosts from which client programs can be run. +By default, only programs on the local host and hosts specified in an initial list read by the server can use the display. -This access control list can be changed by clients on the local host. +This access control list can be changed by clients on the local host. Some server implementations can also implement other authorization mechanisms in addition to or in place of this mechanism. -The action of this mechanism can be conditional based on the authorization -protocol name and data received by the server at connection setup. +The action of this mechanism can be conditional based on the authorization +protocol name and data received by the server at connection setup. @@ -25,7 +25,7 @@ protocol name and data received by the server at connection setup. Active grab -A grab is active when the pointer or keyboard is actually owned by the +A grab is active when the pointer or keyboard is actually owned by the single grabbing client. @@ -57,7 +57,7 @@ Atoms are used to identify properties, types, and selections. An InputOutput window can have a background, which is defined as a pixmap. -When regions of the window have their contents lost +When regions of the window have their contents lost or invalidated, the server automatically tiles those regions with the background. @@ -68,7 +68,7 @@ the server automatically tiles those regions with the background. Backing store -When a server maintains the contents of a window, +When a server maintains the contents of a window, the pixels saved off-screen are known as a backing store. @@ -78,24 +78,24 @@ the pixels saved off-screen are known as a backing store. Base font name -A font name used to select a family of fonts whose members may be encoded +A font name used to select a family of fonts whose members may be encoded in various charsets. The CharSetRegistry -and +and CharSetEncoding fields of an XLFD name identify the charset of the font. -A base font name may be a full XLFD name, with all fourteen '-' delimiters, +A base font name may be a full XLFD name, with all fourteen '-' delimiters, or an abbreviated XLFD name containing only the first 12 fields of an XLFD name, -up to but not including +up to but not including CharSetRegistry, with or without the thirteenth '-', or a non-XLFD name. Any XLFD fields may contain wild cards. -When creating an +When creating an XFontSet, -Xlib accepts from the client a list of one or more base font names +Xlib accepts from the client a list of one or more base font names which select one or more font families. They are combined with charset names obtained from the encoding of the locale to load the fonts required to render text. @@ -107,9 +107,9 @@ to load the fonts required to render text. Bitgravity -When a window is resized, -the contents of the window are not necessarily discarded. -It is possible to request that the server relocate the previous contents +When a window is resized, +the contents of the window are not necessarily discarded. +It is possible to request that the server relocate the previous contents to some region of the window (though no guarantees are made). This attraction of window contents for some location of a window is known as bit gravity. @@ -155,7 +155,7 @@ Exposure events are never generated for border regions. Buttons on the pointer can be passively grabbed by a client. -When the button is pressed, +When the button is pressed, the pointer is then actively grabbed by the client. @@ -165,11 +165,11 @@ the pointer is then actively grabbed by the client. Byteorder -For image (pixmap/bitmap) data, +For image (pixmap/bitmap) data, the server defines the byte order, and clients with different native byte ordering must swap bytes as -necessary. -For all other parts of the protocol, +necessary. +For all other parts of the protocol, the client defines the byte order, and the server swaps bytes as necessary. @@ -182,7 +182,7 @@ and the server swaps bytes as necessary. A member of a set of elements used for the organization, control, or representation of text (ISO2022, as adapted by XPG3). -Note that in ISO2022 terms, a character is not bound to a coded value +Note that in ISO2022 terms, a character is not bound to a coded value until it is identified as part of a coded character set. @@ -213,7 +213,7 @@ A collection of characters. Charset -An encoding with a uniform, state-independent mapping from characters +An encoding with a uniform, state-independent mapping from characters to codepoints. A coded character set. @@ -264,12 +264,12 @@ windows for further information about valid window types. An application program connects to the window system server by some interprocess communication (IPC) path, such as a TCP connection or a -shared memory buffer. -This program is referred to as a client of the window system server. -More precisely, -the client is the IPC path itself. +shared memory buffer. +This program is referred to as a client of the window system server. +More precisely, +the client is the IPC path itself. A program with multiple paths open to the server is viewed as -multiple clients by the protocol. +multiple clients by the protocol. Resource lifetimes are controlled by connection lifetimes, not by program lifetimes. @@ -280,9 +280,9 @@ connection lifetimes, not by program lifetimes. Clipping region -In a graphics context, +In a graphics context, a bitmap or list of rectangles can be specified -to restrict output to a particular region of the window. +to restrict output to a particular region of the window. The image defined by the bitmap or rectangles is called a clipping region. @@ -301,8 +301,8 @@ A character bound to a codepoint. Coded character set -A set of unambiguous rules that establishes a character set -and the one-to-one relationship between each character of the set +A set of unambiguous rules that establishes a character set +and the one-to-one relationship between each character of the set and its bit representation. (ISO2022, as adapted by XPG3) A definition of a one-to-one mapping of a set of characters to a set of @@ -328,7 +328,7 @@ A colormap consists of a set of entries defining color values. The colormap associated with a window is used to display the contents of the window; each pixel value indexes the colormap to produce an RGB value that drives the guns of a monitor. -Depending on hardware limitations, +Depending on hardware limitations, one or more colormaps can be installed at one time so that windows associated with those maps display with true colors. @@ -352,8 +352,8 @@ connection to the server over which requests and events are sent. A window contains the pointer if the window is viewable and the hotspot of the cursor is within a visible region of the window or a -visible region of one of its inferiors. -The border of the window is included as part of the window for containment. +visible region of one of its inferiors. +The border of the window is included as part of the window for containment. The pointer is in a window if the window contains the pointer but no inferior contains the pointer. @@ -364,11 +364,11 @@ but no inferior contains the pointer. Coordinate system -The coordinate system has X horizontal and Y vertical, -with the origin [0, 0] at the upper left. +The coordinate system has X horizontal and Y vertical, +with the origin [0, 0] at the upper left. Coordinates are integral and coincide with pixel centers. -Each window and pixmap has its own coordinate system. -For a window, +Each window and pixmap has its own coordinate system. +For a window, the origin is inside the border at the inside upper-left corner. @@ -378,9 +378,9 @@ the origin is inside the border at the inside upper-left corner. Cursor -A cursor is the visible shape of the pointer on a screen. -It consists of a hotspot, a source bitmap, a shape bitmap, -and a pair of colors. +A cursor is the visible shape of the pointer on a screen. +It consists of a hotspot, a source bitmap, a shape bitmap, +and a pair of colors. The cursor defined for a window controls the visible appearance when the pointer is in that window. @@ -404,9 +404,9 @@ used in conjunction with graphics output. Keyboards, mice, tablets, track-balls, button boxes, and so on are all collectively known as input devices. -Pointers can have one or more buttons +Pointers can have one or more buttons (the most common number is three). -The core protocol only deals with two devices: the keyboard +The core protocol only deals with two devices: the keyboard and the pointer. @@ -419,10 +419,10 @@ and the pointer. DirectColor is a class of colormap in which a pixel value is decomposed into three separate subfields for indexing. -The first subfield indexes an array to produce red intensity values. +The first subfield indexes an array to produce red intensity values. The second subfield indexes a second array to produce blue intensity values. The third subfield indexes a third array to produce green intensity values. -The RGB (red, green, and blue) values in the colormap entry can be +The RGB (red, green, and blue) values in the colormap entry can be changed dynamically. @@ -447,10 +447,10 @@ particular connection. Drawable -Both windows and pixmaps can be used as sources and destinations -in graphics operations. +Both windows and pixmaps can be used as sources and destinations +in graphics operations. These windows and pixmaps are collectively known as drawables. -However, an +However, an InputOnly window cannot be used as a source or destination in a graphics operation. @@ -462,12 +462,12 @@ graphics operation. Encoding -A set of unambiguous rules that establishes a character set +A set of unambiguous rules that establishes a character set and a relationship between the characters and their representations. The character set does not have to be fixed to a finite pre-defined set of characters. The representations do not have to be of uniform length. -Examples are an ISO2022 graphic set, a state-independent +Examples are an ISO2022 graphic set, a state-independent or state-dependent combination of graphic sets, possibly including control sets, and the X Compound Text encoding. @@ -481,7 +481,7 @@ components of an XLFD name; the name of a charset of the locale for which a font could not be found; or an atom which identifies the encoding of a text property or which names an encoding for a text selection target type. -Encoding names should be composed of characters from the X Portable +Encoding names should be composed of characters from the X Portable Character Set. @@ -504,11 +504,11 @@ character (that is, the one following the given string) to be drawn. Clients are informed of information asynchronously by means of events. These events can be either asynchronously generated from devices or -generated as side effects of client requests. -Events are grouped into types. +generated as side effects of client requests. +Events are grouped into types. The server never sends an event to a client unless the client has specifically asked to be informed of that type of event. -However, clients can force events to be sent to other clients. +However, clients can force events to be sent to other clients. Events are typically reported relative to a window. @@ -518,8 +518,8 @@ Events are typically reported relative to a window. Eventmask -Events are requested relative to a window. -The set of event types a client requests relative to a window is described +Events are requested relative to a window. +The set of event types a client requests relative to a window is described by using an event mask. @@ -553,8 +553,8 @@ the source of a device-related event. There are certain race conditions possible when demultiplexing device events to clients (in particular, deciding where pointer and keyboard events should be sent when in the middle of window management -operations). -The event synchronization mechanism allows synchronous processing of +operations). +The event synchronization mechanism allows synchronous processing of device events. @@ -565,7 +565,7 @@ device events. Servers do not guarantee to preserve the contents of windows when -windows are obscured or reconfigured. +windows are obscured or reconfigured. Exposure events are sent to clients to inform them when contents of regions of windows have been lost. @@ -576,7 +576,7 @@ of windows have been lost. Extension -Named extensions to the core protocol can be defined to extend the system. +Named extensions to the core protocol can be defined to extend the system. Extensions to output requests, resources, and event types are all possible and expected. @@ -587,10 +587,10 @@ and expected. Font -A font is an array of glyphs (typically characters). -The protocol does no translation or interpretation of character sets. -The client simply indicates values used to index the glyph array. -A font contains additional metric information to determine interglyph +A font is an array of glyphs (typically characters). +The protocol does no translation or interpretation of character sets. +The client simply indicates values used to index the glyph array. +A font contains additional metric information to determine interglyph and interline spacing. @@ -640,7 +640,7 @@ not bound to a codepoint. Glyph image -An image of a glyph, as obtained from a glyph representation displayed +An image of a glyph, as obtained from a glyph representation displayed on a presentation surface. (ISO/IEC/DIS 9541-1) @@ -651,9 +651,9 @@ on a presentation surface. Grab -Keyboard keys, the keyboard, pointer buttons, the pointer, -and the server can be grabbed for exclusive use by a client. -In general, +Keyboard keys, the keyboard, pointer buttons, the pointer, +and the server can be grabbed for exclusive use by a client. +In general, these facilities are not intended to be used by normal applications but are intended for various input and window managers to implement various styles of user interfaces. @@ -670,7 +670,7 @@ context (GC), such as foreground pixel, background pixel, line width, clipping region, and so on. A graphics context can only be used with drawables that have the same root and the same depth as -the graphics context. +the graphics context. @@ -692,9 +692,9 @@ See Bit gravity and GrayScale -can be viewed as a degenerate case of +can be viewed as a degenerate case of PseudoColor, -in which the red, green, and blue values in any given colormap entry +in which the red, green, and blue values in any given colormap entry are equal and thus, produce shades of gray. The gray values can be changed dynamically. @@ -730,7 +730,7 @@ cursor corresponding to the coordinates reported for the pointer. An identifier is a unique value associated with a resource -that clients use to name that resource. +that clients use to name that resource. The identifier can be used over any connection to name the resource. @@ -752,7 +752,7 @@ the children, the children's children, and so on. The input focus is usually a window defining the scope for processing of keyboard input. -If a generated keyboard event usually would be reported to this window +If a generated keyboard event usually would be reported to this window or one of its inferiors, the event is reported as usual. Otherwise, the event is reported with respect to the focus window. @@ -767,7 +767,7 @@ of whatever screen the pointer is on at each keyboard event. Inputmanager -Control over keyboard input is typically provided by an input manager +Control over keyboard input is typically provided by an input manager client, which usually is part of a window manager. @@ -779,12 +779,12 @@ client, which usually is part of a window manager. An InputOnly -window is a window that cannot be used for graphics requests. +window is a window that cannot be used for graphics requests. InputOnly windows are invisible and are used to control such things as cursors, input event generation, and grabbing. InputOnly -windows cannot have +windows cannot have InputOutput windows as inferiors. @@ -799,9 +799,9 @@ An InputOutput window is the normal kind of window that is used for both input and output. InputOutput -windows can have both +windows can have both InputOutput -and +and InputOnly windows as inferiors. @@ -814,7 +814,7 @@ windows as inferiors. The process of making software adaptable to the requirements of different native languages, local customs, and character string encodings. -Making a computer program adaptable to different locales +Making a computer program adaptable to different locales without program source modifications or recompilation. @@ -824,7 +824,7 @@ without program source modifications or recompilation. ISO2022 -ISO standard for code extension techniques for 7-bit and 8-bit coded +ISO standard for code extension techniques for 7-bit and 8-bit coded character sets. @@ -834,8 +834,8 @@ character sets. Keygrabbing -Keys on the keyboard can be passively grabbed by a client. -When the key is pressed, +Keys on the keyboard can be passively grabbed by a client. +When the key is pressed, the keyboard is then actively grabbed by the client. @@ -920,7 +920,7 @@ Encoding and decoding for inter-client text communication Locale name -The identifier used to select the desired locale for the host C library +The identifier used to select the desired locale for the host C library and X library functions. On ANSI C library compliant systems, the locale argument to the @@ -934,8 +934,8 @@ function. Localization -The process of establishing information within a computer system specific -to the operation of particular native languages, local customs +The process of establishing information within a computer system specific +to the operation of particular native languages, local customs and coded character sets. (XPG3) @@ -966,7 +966,7 @@ ShiftLock, and similar keys are called modifier keys. Monochrome -Monochrome is a special case of +Monochrome is a special case of StaticGray in which there are only two colormap entries. @@ -993,9 +993,9 @@ imply only that the strings may contain multibyte A window is obscured if some other window obscures it. A window can be partially obscured and so still have visible regions. -Window A obscures window B if both are viewable +Window A obscures window B if both are viewable InputOutput -windows, if A is higher in the global stacking order, +windows, if A is higher in the global stacking order, and if the rectangle defined by the outside edges of A intersects the rectangle defined by the outside edges of B. Note the distinction between obscures and occludes. @@ -1009,10 +1009,10 @@ Also note that window borders are included in the calculation. A window is occluded if some other window occludes it. -Window A occludes window B if both are mapped, -if A is higher in the global stacking order, -and if the rectangle defined by the outside edges of A intersects the rectangle defined -by the outside edges of B. +Window A occludes window B if both are mapped, +if A is higher in the global stacking order, +and if the rectangle defined by the outside edges of A intersects the rectangle defined +by the outside edges of B. Note the distinction between occludes and obscures. Also note that window borders are included in the calculation and that @@ -1027,7 +1027,7 @@ windows never obscure other windows but can occlude other windows. Some padding bytes are inserted in the data stream to maintain -alignment of the protocol requests on natural boundaries. +alignment of the protocol requests on natural boundaries. This increases ease of portability to some machine architectures. @@ -1046,7 +1046,7 @@ If C is a child of P, then P is the parent of C. Passive grab -Grabbing a key or button is a passive grab. +Grabbing a key or button is a passive grab. The grab activates when the key or button is actually pressed. @@ -1058,8 +1058,8 @@ The grab activates when the key or button is actually pressed. A pixel is an N-bit value, where N is the number of bit planes used in a particular window or pixmap -(that is, is the depth of the window or pixmap). -A pixel in a window indexes a colormap to derive an actual color to be +(that is, is the depth of the window or pixmap). +A pixel in a window indexes a colormap to derive an actual color to be displayed. @@ -1069,10 +1069,10 @@ displayed. Pixmap -A pixmap is a three-dimensional array of bits. -A pixmap is normally thought of as a two-dimensional array of pixels, +A pixmap is a three-dimensional array of bits. +A pixmap is normally thought of as a two-dimensional array of pixels, where each pixel can be a value from 0 to 2N-1, -and where N is the depth (z axis) of the pixmap. +and where N is the depth (z axis) of the pixmap. A pixmap can also be thought of as a stack of N bitmaps. A pixmap can only be used on the screen that it was created in. @@ -1094,7 +1094,7 @@ bitmap is called a plane or bit plane. Graphics operations can be restricted to only affect a subset of bit -planes of a destination. +planes of a destination. A plane mask is a bit mask describing which planes are to be modified. The plane mask is stored in a graphics context. @@ -1115,8 +1115,8 @@ and tracked on the screens. Pointergrabbing -A client can actively grab control of the pointer. -Then button and motion events will be sent to that client +A client can actively grab control of the pointer. +Then button and motion events will be sent to that client rather than the client the events would normally have been sent to. @@ -1127,7 +1127,7 @@ rather than the client the events would normally have been sent to. A pointing device is typically a mouse, tablet, or some other -device with effective dimensional motion. +device with effective dimensional motion. The core protocol defines only one visible cursor, which tracks whatever pointing device is attached as the pointer. @@ -1164,9 +1164,9 @@ a..z A..Z 0..9 ._- Windows can have associated properties that consist of a name, a type, -a data format, and some data. -The protocol places no interpretation on properties. -They are intended as a general-purpose naming mechanism for clients. +a data format, and some data. +The protocol places no interpretation on properties. +They are intended as a general-purpose naming mechanism for clients. For example, clients might use properties to share information such as resize hints, program names, and icon formats with a window manager. @@ -1218,8 +1218,8 @@ a single pixel would be drawn. Window managers (or client programs) may enforce window layout -policy in various ways. -When a client attempts to change the size or position of a window, +policy in various ways. +When a client attempts to change the size or position of a window, the operation may be redirected to a specified client rather than the operation actually being performed. @@ -1230,9 +1230,9 @@ rather than the operation actually being performed. Reply -Information requested by a client program using the X protocol +Information requested by a client program using the X protocol is sent back to the client with a reply. -Both events and replies are multiplexed on the same connection. +Both events and replies are multiplexed on the same connection. Most requests do not generate replies, but some requests generate multiple replies. @@ -1254,9 +1254,9 @@ It is a single block of data sent over a connection. Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are -known as resources. -They all have unique identifiers associated with them for naming purposes. -The lifetime of a resource usually is bounded by the lifetime of the +known as resources. +They all have unique identifiers associated with them for naming purposes. +The lifetime of a resource usually is bounded by the lifetime of the connection over which the resource was created. @@ -1279,8 +1279,8 @@ The X server scales these values to match the display hardware. Root -The root of a pixmap or graphics context is the same as the root -of whatever drawable was used when the pixmap or GC was created. +The root of a pixmap or graphics context is the same as the root +of whatever drawable was used when the pixmap or GC was created. The root of a window is the root window under which the window was created. @@ -1291,7 +1291,7 @@ The root of a window is the root window under which the window was created. Each screen has a root window covering it. -The root window cannot be reconfigured or unmapped, +The root window cannot be reconfigured or unmapped, but otherwise it acts as a full-fledged window. A root window has no parent. @@ -1304,7 +1304,7 @@ A root window has no parent. The save set of a client is a list of other clients' windows that, if they are inferiors of one of the client's windows at connection -close, should not be destroyed and that should be remapped +close, should not be destroyed and that should be remapped if currently unmapped. Save sets are typically used by window managers to avoid lost windows if the manager should terminate abnormally. @@ -1339,14 +1339,14 @@ increasing the y coordinate. Displaystructure -A server can provide several independent screens, -which typically have physically independent monitors. -This would be the expected configuration when there is only a single keyboard +A server can provide several independent screens, +which typically have physically independent monitors. +This would be the expected configuration when there is only a single keyboard and pointer shared among the screens. -A +A Screen structure contains the information about that screen -and is linked to the +and is linked to the Display structure. @@ -1361,8 +1361,8 @@ A selection can be thought of as an indirect property with dynamic type. That is, rather than having the property stored in the X server, it is maintained by some client (the owner). -A selection is global and is thought of as belonging to the user -and being maintained by clients, +A selection is global and is thought of as belonging to the user +and being maintained by clients, rather than being private to a particular window subhierarchy or a particular set of clients. When a client asks for the contents of @@ -1375,7 +1375,7 @@ Z format. The target type can also be used to control the class of -contents transmitted; for example, +contents transmitted; for example, asking for the ``looks'' (fonts, line spacing, indentation, and so forth) of a paragraph selection, rather than the text of the paragraph. @@ -1390,10 +1390,10 @@ The protocol does not constrain the semantics. Server -The server, which is also referred to as the X server, -provides the basic windowing mechanism. -It handles IPC connections from clients, -multiplexes graphics requests onto the screens, +The server, which is also referred to as the X server, +provides the basic windowing mechanism. +It handles IPC connections from clients, +multiplexes graphics requests onto the screens, and demultiplexes input back to the appropriate clients. @@ -1403,7 +1403,7 @@ and demultiplexes input back to the appropriate clients. Servergrabbing -The server can be grabbed by a single client for exclusive use. +The server can be grabbed by a single client for exclusive use. This prevents processing of any requests from other client connections until the grab is completed. This is typically only a transient state for such things as rubber-banding, @@ -1416,7 +1416,7 @@ pop-up menus, or executing requests indivisibly. Shift sequence -ISO2022 defines control characters and escape sequences +ISO2022 defines control characters and escape sequences which temporarily (single shift) or permanently (locking shift) cause a different character set to be in effect (``invoking'' a character set). @@ -1437,8 +1437,8 @@ Children of the same parent window are known as sibling windows. Sibling windows, similar to sheets of paper on a desk, -can stack on top of each other. -Windows above both obscure and occlude lower windows. +can stack on top of each other. +Windows above both obscure and occlude lower windows. The relationship between sibling windows is known as the stacking order. @@ -1450,8 +1450,8 @@ The relationship between sibling windows is known as the stacking order. An encoding in which an invocation of a charset can apply to multiple characters in sequence. -A state-dependent encoding begins in an ``initial state'' -and enters other ``shift states'' when specific ``shift sequences'' +A state-dependent encoding begins in an ``initial state'' +and enters other ``shift states'' when specific ``shift sequences'' are encountered in the byte sequence. In ISO2022 terms, this means use of locking shifts, not single shifts. @@ -1476,7 +1476,7 @@ this means use of at most single shifts, not locking shifts. StaticColor -can be viewed as a degenerate case of +can be viewed as a degenerate case of PseudoColor in which the RGB values are predefined and read-only. @@ -1488,7 +1488,7 @@ in which the RGB values are predefined and read-only. StaticGray -can be viewed as a degenerate case of +can be viewed as a degenerate case of GrayScale in which the gray values are predefined and read-only. The values are typically linear or near-linear increasing ramps. @@ -1548,7 +1548,7 @@ are pairwise equivalent to decimal values 246 to 254 inclusive Tile -A pixmap can be replicated in two dimensions to tile a region. +A pixmap can be replicated in two dimensions to tile a region. The pixmap itself is also known as a tile. @@ -1558,16 +1558,16 @@ The pixmap itself is also known as a tile. Timestamp -A timestamp is a time value expressed in milliseconds. +A timestamp is a time value expressed in milliseconds. It is typically the time since the last server reset. Timestamp values wrap around (after about 49.7 days). -The server, given its current time is represented by timestamp T, -always interprets timestamps from clients by treating half -of the timestamp space as being earlier in time than T +The server, given its current time is represented by timestamp T, +always interprets timestamps from clients by treating half +of the timestamp space as being earlier in time than T and half of the timestamp space as being later in time than T. -One timestamp value, represented by the constant +One timestamp value, represented by the constant CurrentTime, -is never generated by the server. +is never generated by the server. This value is reserved for use in requests to represent the current server time. @@ -1578,7 +1578,7 @@ This value is reserved for use in requests to represent the current server time. TrueColor -can be viewed as a degenerate case of +can be viewed as a degenerate case of DirectColor in which the subfields in the pixel value directly encode the corresponding RGB values. @@ -1592,9 +1592,9 @@ The values are typically linear or near-linear increasing ramps. Type -A type is an arbitrary atom used to identify the interpretation of property -data. -Types are completely uninterpreted by the server. +A type is an arbitrary atom used to identify the interpretation of property +data. +Types are completely uninterpreted by the server. They are solely for the benefit of clients. X predefines type atoms for many frequently used types, and clients also can define new types. @@ -1606,11 +1606,11 @@ and clients also can define new types. Viewable -A window is viewable if it and all of its ancestors are mapped. +A window is viewable if it and all of its ancestors are mapped. This does not imply that any portion of the window is actually visible. Graphics requests can be performed on a window when it is not viewable, but output will not be retained unless the server is maintaining -backing store. +backing store. @@ -1643,10 +1643,10 @@ returns true. Windowgravity -When windows are resized, -subwindows may be repositioned automatically relative to some position in the +When windows are resized, +subwindows may be repositioned automatically relative to some position in the window. -This attraction of a subwindow to some part of its parent is known +This attraction of a subwindow to some part of its parent is known as window gravity. diff --git a/specs/libX11/libX11.xml b/specs/libX11/libX11.xml index 4fb05758..380fff28 100644 --- a/specs/libX11/libX11.xml +++ b/specs/libX11/libX11.xml @@ -67,16 +67,16 @@ -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files -(the “Software”), to deal in the Software without restriction, -including without limitation the rights to use, copy, modify, merge, publish, -distribute, sublicense, and/or sell copies of the Software, and to permit -persons to whom the Software is furnished to do so, subject to the following +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files +(the “Software”), to deal in the Software without restriction, +including without limitation the rights to use, copy, modify, merge, publish, +distribute, sublicense, and/or sell copies of the Software, and to permit +persons to whom the Software is furnished to do so, subject to the following conditions: -The above copyright notice and this permission notice shall be included in all +The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. @@ -88,8 +88,8 @@ ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -Except as contained in this notice, the name of The Open Group shall not -be used in advertising or otherwise to promote the sale, use or other dealings +Except as contained in this notice, the name of The Open Group shall not +be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from The Open Group. diff --git a/src/XErrorDB b/src/XErrorDB index 7b6d4651..d691ad85 100644 --- a/src/XErrorDB +++ b/src/XErrorDB @@ -6,10 +6,10 @@ ! the above copyright notice appear in all copies and that both that ! copyright notice and this permission notice appear in supporting ! documentation. -! +! ! The above copyright notice and this permission notice shall be ! included in all copies or substantial portions of the Software. -! +! ! THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, ! EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF ! MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. @@ -17,7 +17,7 @@ ! OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ! ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR ! OTHER DEALINGS IN THE SOFTWARE. -! +! ! Except as contained in this notice, the name of The Open Group shall ! not be used in advertising or otherwise to promote the sale, use or ! other dealings in this Software without prior written authorization @@ -1014,9 +1014,9 @@ XRequest.DRI2.3: DRI2CreateDrawable XRequest.DRI2.4: DRI2DestroyDrawable XRequest.DRI2.5: DRI2GetBuffers XRequest.DRI2.6: DRI2CopyRegion -XRequest.DRI2.7: DRI2GetBuffersWithFormat -XRequest.DRI2.8: DRI2SwapBuffers -XRequest.DRI2.9: DRI2GetMSC -XRequest.DRI2.10: DRI2WaitMSC -XRequest.DRI2.11: DRI2WaitSBC -XRequest.DRI2.12: DRI2SwapInterval +XRequest.DRI2.7: DRI2GetBuffersWithFormat +XRequest.DRI2.8: DRI2SwapBuffers +XRequest.DRI2.9: DRI2GetMSC +XRequest.DRI2.10: DRI2WaitMSC +XRequest.DRI2.11: DRI2WaitSBC +XRequest.DRI2.12: DRI2SwapInterval diff --git a/src/util/mkks.sh b/src/util/mkks.sh index 262cc954..7baad8d1 100644 --- a/src/util/mkks.sh +++ b/src/util/mkks.sh @@ -7,5 +7,5 @@ cat $* | awk 'BEGIN { \ /^#define/ { \ len = length($2)-3; \ printf("{ \"%s\", %s },\n", substr($2,4,len), $3); \ -}' +}' diff --git a/src/xlibi18n/lcGeneric.c b/src/xlibi18n/lcGeneric.c index 1f3f60bb..e532a93e 100644 --- a/src/xlibi18n/lcGeneric.c +++ b/src/xlibi18n/lcGeneric.c @@ -1061,7 +1061,7 @@ freeConversion( /* ... */ Xfree(ctconv->convlist); ctconv->convlist = NULL; - + Xfree(ctconv); codeset->ctconv = NULL; } diff --git a/src/xlibi18n/lcUTF8.c b/src/xlibi18n/lcUTF8.c index 8169608a..f08e18a5 100644 --- a/src/xlibi18n/lcUTF8.c +++ b/src/xlibi18n/lcUTF8.c @@ -2228,7 +2228,7 @@ iconv_mbstowcs(XlcConv conv, XPointer *from, int *from_left, /* null ? */ src++; src_left--; - if (dst) + if (dst) *dst++ = L'\0'; dst_left--; } @@ -2265,20 +2265,20 @@ iconv_wcstombs(XlcConv conv, XPointer *from, int *from_left, int dst_left = *to_left; int length, unconv_num = 0; - while (src_left > 0 && dst_left >= MB_CUR_MAX) { + while (src_left > 0 && dst_left >= MB_CUR_MAX) { length = wctomb(dst, *src); /* XXX */ if (length > 0) { src++; src_left--; - if (dst) + if (dst) dst += length; dst_left -= length; } else if (length < 0) { src++; src_left--; unconv_num++; - } + } } *from = (XPointer) src; diff --git a/src/xlibi18n/lcUniConv/iso8859_9e.h b/src/xlibi18n/lcUniConv/iso8859_9e.h index a2252c0a..4f656f3b 100644 --- a/src/xlibi18n/lcUniConv/iso8859_9e.h +++ b/src/xlibi18n/lcUniConv/iso8859_9e.h @@ -73,7 +73,7 @@ static const unsigned char iso8859_9e_page01_d[24] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0xd8-0xdf */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xaa, 0xba, /* 0xe0-0xe7 */ }; - + static int iso8859_9e_wctomb (conv_t conv, unsigned char *r, ucs4_t wc, int n) {