Rename `chinese-cns11643-6' to `=cns11643-6'.
[chise/xemacs-chise.git.1] / lisp / glyphs.el
index 6594006..c150670 100644 (file)
@@ -1,7 +1,7 @@
 ;;; glyphs.el --- Lisp interface to C glyphs
 
 ;; Copyright (C) 1994, 1997 Free Software Foundation, Inc.
-;; Copyright (C) 1995, 1996 Ben Wing.
+;; Copyright (C) 1995, 1996, 2000 Ben Wing.
 
 ;; Author: Chuck Thompson <cthomp@cs.uiuc.edu>, Ben Wing <ben@xemacs.org>
 ;; Maintainer: XEmacs Development Team
 
 ;;; Synched up with: Not in FSF.
 
+;;; Authorship:
+
+;; Prototype created 1995 by Chuck Thompson.
+;; Completely rewritten by Ben Wing, 1995.
+;; Various cleanups (esp. doc strings) by Ben Wing, May 2000.
+
 ;;; Commentary:
 
 ;; This file is dumped with XEmacs.
 
 ;;; Code:
 
-;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; font specifiers
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; image specifiers
 
 (defun make-image-specifier (spec-list)
   "Return a new `image' specifier object with the specification list SPEC-LIST.
 SPEC-LIST can be a list of specifications (each of which is a cons of a
 locale and a list of instantiators), a single instantiator, or a list
 of instantiators.  See `make-specifier' for more information about
-specifiers."
+specifiers.
+
+An image specifier is used for images (pixmaps, widgets and the like).
+It is used to describe the actual image in a glyph.  It is instanced
+as an image-instance.  Note that \"image\" as used in XEmacs does not
+actually refer to what the term \"image\" normally means (a picture,
+e.g. in .GIF or .JPG format, and called a \"pixmap\" in XEmacs), but
+includes all types of graphical elements, including pixmaps, widgets
+\(buttons, sliders, text fields, etc.) and even strings of text.
+
+Note that, in practice, you rarely, if ever, need to actually create
+an image specifier! (The function `make-image-specifier' exists mainly
+for completeness.) Pretty much the only use for image specifiers is to
+control how glyphs are displayed, and the image specifier associated
+with a glyph (the `image' property of a glyph) is created
+automatically when a glyph is created (see `make-glyph') and need not
+\(and cannot, for that matter) ever be changed.  In fact, the design
+decision to create a separate image specifier type, rather than make
+glyphs themselves be specifiers, is debatable -- the other properties
+of glyphs are rarely used and could conceivably have been incorporated
+into the glyph's instantiator.  The rarely used glyph types (buffer,
+pointer, icon) could also have been incorporated into the instantiator.
+
+Image instantiators come in many formats: `xbm', `xpm', `gif', `jpeg',
+etc.  This describes the format of the data describing the image.  The
+resulting image instances also come in many types -- `mono-pixmap',
+`color-pixmap', `text', `pointer', etc.  This refers to the behavior of
+the image and the sorts of places it can appear. (For example, a
+color-pixmap image has fixed colors specified for it, while a
+mono-pixmap image comes in two unspecified shades \"foreground\" and
+\"background\" that are determined from the face of the glyph or
+surrounding text; a text image appears as a string of text and has an
+unspecified foreground, background, and font; a pointer image behaves
+like a mono-pixmap image but can only be used as a mouse pointer
+\[mono-pixmap images cannot be used as mouse pointers]; etc.) It is
+important to keep the distinction between image instantiator format and
+image instance type in mind.  Typically, a given image instantiator
+format can result in many different image instance types (for example,
+`xpm' can be instanced as `color-pixmap', `mono-pixmap', or `pointer';
+whereas `cursor-font' can be instanced only as `pointer'), and a
+particular image instance type can be generated by many different
+image instantiator formats (e.g.  `color-pixmap' can be generated by `xpm',
+`gif', `jpeg', etc.).
+
+See `make-image-instance' for a more detailed discussion of image
+instance types.
+
+An image instantiator should be a string or a vector of the form
+
+ [FORMAT :KEYWORD VALUE ...]
+
+i.e. a format symbol followed by zero or more alternating keyword-value
+pairs.  FORMAT should be one of
+
+'nothing
+   Don't display anything; no keywords are valid for this.
+   Can only be instanced as `nothing'.
+'string
+   Display this image as a text string.  Can only be instanced
+   as `text', although support for instancing as `mono-pixmap'
+   and `color-pixmap' should be added.
+'formatted-string
+   Display this image as a text string, with replaceable fields;
+   not currently implemented. (It is, instead, equivalent to `string'.)
+'xbm
+   An X bitmap; only if X or MS Windows support was compiled into this
+   XEmacs.  Can be instanced as `mono-pixmap', `color-pixmap', or `pointer'.
+'xpm
+   An XPM pixmap; only if XPM support was compiled into this XEmacs.
+   Can be instanced as `color-pixmap', `mono-pixmap', or `pointer'.
+'xface
+   An X-Face bitmap, used to encode people's faces in e-mail messages;
+   only if X-Face support was compiled into this XEmacs.  Can be
+   instanced as `mono-pixmap', `color-pixmap', or `pointer'.
+'gif
+   A GIF87 or GIF89 image; only if GIF support was compiled into this
+   XEmacs.  NOTE: only the first frame of animated gifs will be displayed.
+   Can be instanced as `color-pixmap'.
+'jpeg
+   A JPEG image; only if JPEG support was compiled into this XEmacs.
+   Can be instanced as `color-pixmap'.
+'png
+   A PNG image; only if PNG support was compiled into this XEmacs.
+   Can be instanced as `color-pixmap'.
+'tiff
+   A TIFF image; only if TIFF support was compiled into this XEmacs.
+   Can be instanced as `color-pixmap'.
+'bmp
+   A MS Windows BMP image; only if MS Windows support was compiled into
+   this XEmacs.  Can be instanced as `color-pixmap'.
+'cursor-font
+   One of the standard cursor-font names, such as \"watch\" or
+   \"right_ptr\" under X.  Under X, this is, more specifically, any
+   of the standard cursor names from appendix B of the Xlib manual
+   [also known as the file <X11/cursorfont.h>] minus the XC_ prefix.
+   On other window systems, the valid names will be specific to the
+   type of window system.  Can only be instanced as `pointer'.
+'mswindows-resource
+   An MS Windows pointer resource.  Specifies a resource to retrieve
+   directly from the system (an OEM resource) or from a file, particularly
+   an executable file.  If the resource is to be retrieved from a file, use
+   :file and optionally :resource-id.  Otherwise use :resource-id.  Always
+   specify :resource-type to specify the type (cursor, bitmap or icon) of
+   the resource.  Possible values for :resource-id are listed below.  Can
+   be instanced as `pointer' or `color-pixmap'.
+'font
+   A glyph from a font; i.e. the name of a font, and glyph index into it
+   of the form \"FONT fontname index [[mask-font] mask-index]\".
+   Currently can only be instanced as `pointer', although this should
+   probably be fixed.
+'subwindow
+   An embedded windowing system window.  Can only be instanced as
+   `subwindow'.
+'button
+   A button widget; either a push button, radio button or toggle button.
+   Can only be instanced as `widget'.
+'combo-box
+   A drop list of selectable items in a widget, for editing text.
+   Can only be instanced as `widget'.
+'edit-field
+   A text editing widget.  Can only be instanced as `widget'.
+'label
+   A static, text-only, widget; for displaying text.  Can only be instanced
+   as `widget'.
+'layout
+   A widget for controlling the positioning of children underneath it.
+   Through the use of nested layouts, a widget hierarchy can be created
+   which can have the appearance of any standard dialog box or similar
+   arrangement; all of this is counted as one \"glyph\" and could appear
+   in many of the places that expect a single glyph.  Can only be instanced
+   as `widget'.
+'native-layout
+   The native version of a layout widget.  #### Document me better!
+   Can only be instanced as `widget'.
+'progress-gauge
+   A sliding widget, for showing progress.  Can only be instanced as
+   `widget'.
+'tab-control
+   A tab widget; a series of user selectable tabs.  Can only be instanced
+   as `widget'.
+'tree-view
+   A folding widget.  Can only be instanced as `widget'.
+'scrollbar
+   A scrollbar widget.  Can only be instanced as `widget'.
+'autodetect
+   XEmacs tries to guess what format the data is in.  If X support
+   exists, the data string will be checked to see if it names a filename.
+   If so, and this filename contains XBM or XPM data, the appropriate
+   sort of pixmap or pointer will be created. [This includes picking up
+   any specified hotspot or associated mask file.] Otherwise, if `pointer'
+   is one of the allowable image-instance types and the string names a
+   valid cursor-font name, the image will be created as a pointer.
+   Otherwise, the image will be displayed as text.  If no X support
+   exists, the image will always be displayed as text.  Can be instanced as
+   `mono-pixmap', `color-pixmap', `pointer', or `text'.
+'inherit
+   Inherit from the background-pixmap property of a face.  Can only be
+   instanced as `mono-pixmap'.
+
+The valid keywords are:
+
+:data
+   Inline data.  For most formats above, this should be a string.  For
+   XBM images, this should be a list of three elements: width, height, and
+   a string of bit data.  This keyword is valid for all of the bitmap/pixmap
+   formats, as well as `string', `formatted-string', `font', `cursor-font',
+   and `autodetect'.
+:file
+   Data is contained in a file.  The value is the name of this file.
+   If both :data and :file are specified, the image is created from
+   what is specified in :data and the string in :file becomes the
+   value of the `image-instance-file-name' function when applied to
+   the resulting image-instance.  This keyword is valid for all of the
+   bitmap/pixmap formats as well as `mswindows-resource'.
+:foreground
+:background
+   For `xbm', `xface', `cursor-font', `widget' and `font'.  These keywords
+   allow you to explicitly specify foreground and background colors.
+   The argument should be anything acceptable to `make-color-instance'.
+   This will cause what would be a `mono-pixmap' to instead be colorized
+   as a two-color color-pixmap, and specifies the foreground and/or
+   background colors for a pointer instead of black and white.
+:mask-data
+   For `xbm' and `xface'.  This specifies a mask to be used with the
+   bitmap.  The format is a list of width, height, and bits, like for
+   :data.
+:mask-file
+   For `xbm' and `xface'.  This specifies a file containing the mask data.
+   If neither a mask file nor inline mask data is given for an XBM image,
+   and the XBM image comes from a file, XEmacs will look for a mask file
+   with the same name as the image file but with \"Mask\" or \"msk\"
+   appended.  For example, if you specify the XBM file \"left_ptr\"
+   [usually located in \"/usr/include/X11/bitmaps\"], the associated
+   mask file \"left_ptrmsk\" will automatically be picked up.
+:hotspot-x
+:hotspot-y
+   For `xbm' and `xface'.  These keywords specify a hotspot if the image
+   is instantiated as a `pointer'.  Note that if the XBM image file
+   specifies a hotspot, it will automatically be picked up if no
+   explicit hotspot is given.
+:color-symbols
+   Only for `xpm'.  This specifies an alist that maps strings
+   that specify symbolic color names to the actual color to be used
+   for that symbolic color (in the form of a string or a color-specifier
+   object).  If this is not specified, the contents of `xpm-color-symbols'
+   are used to generate the alist.
+:resource-id
+   Only for `mswindows-resource'.  This must be either an integer (which
+   directly specifies a resource number) or a string.  Valid strings are
+
+   -- For bitmaps:
+
+   \"close\", \"uparrow\", \"dnarrow\", \"rgarrow\", \"lfarrow\",
+   \"reduce\", \"zoom\", \"restore\", \"reduced\", \"zoomd\",
+   \"restored\", \"uparrowd\", \"dnarrowd\", \"rgarrowd\", \"lfarrowd\",
+   \"mnarrow\", \"combo\", \"uparrowi\", \"dnarrowi\", \"rgarrowi\",
+   \"lfarrowi\", \"size\", \"btsize\", \"check\", \"checkboxes\", and
+   \"btncorners\".
+
+   -- For cursors:
+
+   \"normal\", \"ibeam\", \"wait\", \"cross\", \"up\", \"sizenwse\",
+   \"sizenesw\", \"sizewe\", \"sizens\", \"sizeall\", and \"no\".
+
+   -- For icons:
+
+   \"sample\", \"hand\", \"ques\", \"bang\", \"note\", and \"winlogo\".
+:resource-type
+   Only for `mswindows-resource'.  This must be a symbol, either `cursor',
+   `icon', or `bitmap', specifying the type of resource to be retrieved.
+:face
+   Only for `inherit'.  This specifies the face to inherit from.
+   For widgets this also specifies the face to use for display. It defaults
+   to gui-element-face.
+
+Keywords accepted as menu item specs are also accepted by widgets.
+These are `:selected', `:active', `:suffix', `:keys', `:style',
+`:filter', `:config', `:included', `:key-sequence', `:accelerator',
+`:label' and `:callback'.
+
+If instead of a vector, the instantiator is a string, it will be
+converted into a vector by looking it up according to the specs in the
+`console-type-image-conversion-list' (q.v.) for the console type of
+the domain (usually a window; sometimes a frame or device) over which
+the image is being instantiated.
+
+If the instantiator specifies data from a file, the data will be read
+in at the time that the instantiator is added to the image (which may
+be well before when the image is actually displayed), and the
+instantiator will be converted into one of the inline-data forms, with
+the filename retained using a :file keyword.  This implies that the
+file must exist when the instantiator is added to the image, but does
+not need to exist at any other time (e.g. it may safely be a temporary
+file).
+"
   (make-specifier-and-init 'image spec-list))
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; glyphs
 
 (defconst built-in-glyph-specifiers
   '(image contrib-p baseline)
-  "A list of the built-in face properties that are specifiers.")
+  "A list of the built-in glyph properties that are specifiers.")
 
 (defun glyph-property (glyph property &optional locale)
   "Return GLYPH's value of PROPERTY in LOCALE.
@@ -283,11 +543,19 @@ Normally DOMAIN will be a window or nil (meaning the selected window),
 See `glyph-property-instance' for more information."
   (glyph-property-instance glyph 'image domain default no-fallback))
 
+(defun glyph-image-property (glyph prop &optional domain default no-fallback)
+  "Return property PROP of the instance of GLYPH's image in DOMAIN.
+
+Normally DOMAIN will be a window or nil (meaning the selected window).
+The value returned is dependent on the image instance type."
+  (image-instance-property
+   (glyph-image-instance glyph domain default no-fallback) prop))
+
 (defun set-glyph-image (glyph spec &optional locale tag-set how-to-add)
   "Change the image of GLYPH in LOCALE.
 
 SPEC should be an instantiator (a string or vector; see
-  `image-specifier-p' for a description of possible values here),
+  `make-image-specifier' for a description of possible values here),
   a list of (possibly tagged) instantiators, an alist of specifications
   (each mapping a locale to an instantiator list), or an image specifier
   object.
@@ -380,20 +648,162 @@ See `set-glyph-property' for more information."
   (set-glyph-property glyph 'baseline spec locale tag-set how-to-add))
 
 (defun make-glyph (&optional spec-list type)
-  "Return a new `glyph' object of type TYPE.
-
-TYPE should be one of `buffer' (used for glyphs in an extent, the modeline,
+  "Create a new glyph of type TYPE.
+
+A glyph in XEmacs does NOT refer to a single unit of textual display (the
+XEmacs term for this is \"rune\"), but rather is an object encapsulating
+a graphical element, such as an image or widget (an element such as a
+button or text field; \"widget\" is the term for this under X Windows,
+and it's called a \"control\" under MS Windows).  This graphical element
+could appear in a buffer, a margin, a gutter, or a toolbar, or as a mouse
+pointer or an icon, for example.
+
+Creating a glyph using `make-glyph' does not specify *where* the glyph
+will be used, but it does specify *what* the glyph will look like.  In
+particular, SPEC-LIST is used to specify this, and it's used to
+initialize the glyph's `image' property, which is an image
+specifier. (Note that \"image\" as used in the context of a glyph's
+`image' property or in the terms \"image specifier\", \"image
+instantiator\", or \"image instance\" does not refer to what people
+normally think of as an image (which in XEmacs is called a
+\"pixmap\"), but to any graphical element -- a pixmap, a widget, or
+even a block of text, when used in the places that call for a glyph.)
+The format of the SPEC-LIST is typically an image instantiator (a
+string or a vector; see `make-image-specifier' for a detailed description
+of the valid image instantiators), but can also be a list of such
+instantiators (each one in turn is tried until an image is
+successfully produced), a cons of a locale (frame, buffer, etc.)  and
+an instantiator, a list of such conses, or any other form accepted by
+`canonicalize-spec-list'.
+
+If you're not familiar with specifiers, you should be in order to
+understand how glyphs work.  The clearest introduction to specifiers
+is in the Lispref manual, available under Info. (Choose
+Help->Info->Info Contents on the menubar or type \\[info].) You can
+also see `make-specifier' for a capsule summary.  What's important to
+keep in mind is that a specifier lets you set a different value for
+any particular buffer, window, frame, device, or console.  This allows
+for a great deal of flexibility; in particular, only one global glyph
+needs to exist for a particular purpose (e.g. the icon used to represent
+an iconified frame, the mouse pointer used over particular areas of a
+frame, etc.), and in these cases you do not create your own glyph, but
+rather modify the existing one.
+
+As well as using SPEC-LIST to initialize the glyph, you can set
+specifications using `set-glyph-image'.  Note that, due to a possibly
+questionable historical design decision, a glyph itself is not
+actually a specifier, but rather is an object containing an image
+specifier (as well as other, seldom-used properties).  Therefore, you
+cannot set or access specifications for the glyph's image by directly
+using `set-specifier', `specifier-instance' or the like on the glyph;
+instead use them on `(glyph-image GLYPH)' or use the convenience
+functions `set-glyph-image', `glyph-image-instance', and
+`glyph-image'.
+
+Once you have created a glyph, you specify where it will be used as follows:
+
+-- To insert a glyph into a buffer, create an extent in the buffer and then
+   use `set-extent-begin-glyph' or `set-extent-end-glyph' to set a glyph
+   to be displayed at the corresponding edge of the extent. (It is common
+   to create zero-width extents for this purpose.)
+
+-- To insert a glyph into the left or right margin of a buffer, first
+   make sure the margin is visible by setting a value for the specifiers
+   `left-margin-width' or `right-margin-width'. (Not strictly necessary
+   when using margin glyphs with layout policy `whitespace'.) Then follow
+   the same procedure above for inserting a glyph in a buffer, and then
+   set a non-default layout policy for the glyph using
+   `set-extent-begin-glyph-layout' or `set-extent-end-glyph-layout'.
+   Alternatively, use the high-level annotations API (see
+   `make-annotation'). (In point of fact, you can also use the annotations
+   API for glyphs in a buffer, by setting a layout policy of `text'.)
+
+-- To insert a glyph into the modeline, just put the glyph directly as
+   one of the modeline elements. (Unfortunately you can't currently
+   put a begin glyph or end glyph on one of the modeline extents --
+   they're ignored.)
+
+-- To insert a glyph into a toolbar, specify it as part of a toolbar
+   instantiator (typically set on the specifier `default-toolbar').
+   See `default-toolbar' for more information. (Note that it is standard
+   practice to use a symbol in place of the glyph list in the toolbar
+   instantiator; the symbol is evalled to get the glyph list.  This
+   facilitates both creating the toolbar instantiator and modifying
+   individual glyphs in a toolbar later on.  For example, you can
+   change the way that the Mail toolbar button looks by modifying the
+   value of the variable `toolbar-mail-icon' (in general, `toolbar-*-icon')
+   and then calling `(set-specifier-dirty-flag default-toolbar)'.
+   (#### Unfortunately this doesn't quite work the way it should; the
+   change will appear in new frames, but not existing ones.
+
+-- To insert a glyph into a gutter, create or modify a gutter instantiator
+   (typically set on the specifier `default-gutter').  Gutter instantiators
+   consist of strings or lists of strings, so to insert a glyph, create an
+   extent over the string, and use `set-extent-begin-glyph' or
+   `set-extent-end-glyph' to set a glyph to be displayed at the corresponding
+   edge of the extent, just like for glyphs in a buffer.
+
+-- To use a glyph as the icon for a frame, you do not actually create a new
+   glyph; rather, you change the specifications for the existing glyph
+   `frame-icon-glyph'. (Remember that, because of the specifier nature of
+   glyphs, you can set different values for any particular buffer or frame.)
+
+-- To use a glyph as the mouse pointer, in general you do not create a
+   new glyph, but rather you change the specifications of various existing
+   glyphs, such as `text-pointer-glyph' for the pointer used over text,
+   `modeline-pointer-glyph' for the pointer used over the modeline, etc.
+   Do an apropos over `*-pointer-glyph' to find all of them. (Note also
+   that you can temporarily set the mouse pointer to some specific shape
+   by using `set-frame-pointer', which takes an image instance, as obtained
+   from calling `glyph-image-instance' on a glyph of type `pointer' --
+   either one of the above-mentioned variables or one you created yourself.
+   (See below for what it means to create a glyph of type `pointer'.)
+   This pointer will last only until the next mouse motion event is
+   processed or certain other things happen, such as creating or deleting
+   a window. (In fact, the above-mentioned pointer glyph variables are
+   implemented as part of the default handler for mouse motion events.
+   If you want to customize this behavior, take a look at `mode-motion-hook',
+   or `mouse-motion-handler' if you really want to get low-level.)
+
+-- To use a glyph to control the shape of miscellaneous redisplay effects
+   such as the truncation and continuation markers, set the appropriate
+   existing glyph variables, as for icons and pointers above.  See
+   `continuation-glyph', `control-arrow-glyph', `hscroll-glyph',
+   `invisible-text-glyph', `octal-escape-glyph', and `truncation-glyph'.
+   See also `overlay-arrow-string', an odd redisplay leftover which can
+   be set to a glyph you created, and will cause the glyph to be displayed
+   on top of the text position specified in the marker stored in
+   `overlay-arrow-position'.
+
+-- To use a glyph in a display table (i.e. to control the appearance of
+   any individual character), create the appropriate character glyphs
+   and then set a specification for the specifier `current-display-table',
+   which controls the appearance of characters.  You can also set an
+   overriding display table for use with text displayed in a particular
+   face; see `set-face-display-table' and `make-display-table'.
+   #### Note: Display tables do not currently support general Mule
+   characters.  They will be overhauled at some point to support this
+   and to provide other features required under Mule.
+
+-- To use a glyph as the background pixmap of a face: Note that the
+   background pixmap of a face is actually an image specifier -- probably
+   the only place in XEmacs where an image specifier occurs outside of
+   a glyph.  Similarly to how the glyph's image specifier works, you
+   don't create your own image specifier, but rather add specifications
+   to the existing one (using `set-face-background-pixmap').  Note that
+   the image instance that is generated in order to actually display the
+   background pixmap is of type `mono-pixmap', meaning that it's a two-color
+   image and the foreground and background of the image get filled in with
+   the corresponding colors from the face.
+
+It is extremely rare that you will ever have to specify a value for TYPE,
+which should be one of `buffer' (used for glyphs in an extent, the modeline,
 the toolbar, or elsewhere in a buffer), `pointer' (used for the mouse-pointer),
-or `icon' (used for a frame's icon), and defaults to `buffer'.
-
-SPEC-LIST is used to initialize the glyph's image.  It is typically an
-image instantiator (a string or a vector; see `image-specifier-p' for
-a detailed description of the valid image instantiators), but can also
-be a list of such instantiators (each one in turn is tried until an
-image is successfully produced), a cons of a locale (frame, buffer, etc.)
-and an instantiator, a list of such conses, or any other form accepted
-by `canonicalize-spec-list'.  See `make-specifier' for more information
-about specifiers."
+or `icon' (used for a frame's icon), and defaults to `buffer'.  The only cases
+where it needs to be specified is when creating icon or pointer glyphs, and
+in both cases the necessary glyphs have already been created at startup and
+are accessed through the appropriate variables, e.g. `text-pointer-glyph'
+(or in general, `*-pointer-glyph') and `frame-icon-glyph'."
   (let ((glyph (make-glyph-internal type)))
     (and spec-list (set-glyph-image glyph spec-list))
     glyph))
@@ -412,38 +822,22 @@ about specifiers."
 
 (defun make-pointer-glyph (&optional spec-list)
   "Return a new `pointer-glyph' object with the specification list SPEC-LIST.
-
 This is equivalent to calling `make-glyph', specifying a type of `pointer'.
+See `make-glyph' for more information.
 
-SPEC-LIST is used to initialize the glyph's image.  It is typically an
-image instantiator (a string or a vector; see `image-specifier-p' for
-a detailed description of the valid image instantiators), but can also
-be a list of such instantiators (each one in turn is tried until an
-image is successfully produced), a cons of a locale (frame, buffer, etc.)
-and an instantiator, a list of such conses, or any other form accepted
-by `canonicalize-spec-list'.  See `make-specifier' for more information
-about specifiers.
-
-You can also create a glyph with an empty SPEC-LIST and add image
-instantiators afterwards using `set-glyph-image'."
+It is extremely unlikely that you will ever need to create a pointer glyph.
+Instead, you probably want to be calling `set-glyph-image' on an existing
+glyph, e.g. `text-pointer-glyph'."
   (make-glyph spec-list 'pointer))
 
 (defun make-icon-glyph (&optional spec-list)
   "Return a new `icon-glyph' object with the specification list SPEC-LIST.
-
 This is equivalent to calling `make-glyph', specifying a type of `icon'.
+See `make-glyph' for more information.
 
-SPEC-LIST is used to initialize the glyph's image.  It is typically an
-image instantiator (a string or a vector; see `image-specifier-p' for
-a detailed description of the valid image instantiators), but can also
-be a list of such instantiators (each one in turn is tried until an
-image is successfully produced), a cons of a locale (frame, buffer, etc.)
-and an instantiator, a list of such conses, or any other form accepted
-by `canonicalize-spec-list'.  See `make-specifier' for more information
-about specifiers.
-
-You can also create a glyph with an empty SPEC-LIST and add image
-instantiators afterwards using `set-glyph-image'."
+It is extremely unlikely that you will ever need to create a icon glyph.
+Instead, you probably want to be calling `set-glyph-image' on
+`frame-icon-glyph'."
   (make-glyph spec-list 'icon))
 
 (defun nothing-image-instance-p (object)
@@ -468,9 +862,12 @@ instantiators afterwards using `set-glyph-image'."
   "Return t if OBJECT is an image instance of type `pointer'."
   (and (image-instance-p object) (eq 'pointer (image-instance-type object))))
 
+(defun widget-image-instance-p (object)
+  "Return t if OBJECT is an image instance of type `widget'."
+  (and (image-instance-p object) (eq 'widget (image-instance-type object))))
+
 (defun subwindow-image-instance-p (object)
-  "Return t if OBJECT is an image instance of type `subwindow'.
-Subwindows are not implemented in this version of XEmacs."
+  "Return t if OBJECT is an image instance of type `subwindow'."
   (and (image-instance-p object) (eq 'subwindow (image-instance-type object))))
 
 ;;;;;;;;;; the built-in glyphs
@@ -603,6 +1000,10 @@ If unspecified in a particular domain, `nontext-pointer-glyph' is used.")
 ;;; (defvar x-toolbar-pointer-shape nil)
 (define-obsolete-pointer-glyph 'x-toolbar-pointer-shape 'toolbar-pointer-glyph)
 
+;; for subwindows
+(defalias 'subwindow-xid 'image-instance-subwindow-id)
+(defalias 'subwindow-width 'image-instance-width)
+(defalias 'subwindow-height 'image-instance-height)
 ;;;;;;;;;; initialization
 
 (defun init-glyphs ()
@@ -622,7 +1023,8 @@ If unspecified in a particular domain, `nontext-pointer-glyph' is used.")
                                 [jpeg :data nil] 2)))
        ,@(if (featurep 'png) '(("\\.png\\'" [png :file nil] 2)))
        ,@(if (featurep 'png) '(("\\`\211PNG" [png :data nil] 2)))
-       ("" [autodetect :data nil] 2))))
+       ("" [string :data nil] 2)
+       ("" [nothing]))))
   ;; #### this should really be formatted-string, not string but we
   ;; don't have it implemented yet
   ;;