;;; 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.
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.
(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))
(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)
"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
[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
;;