Mercurial > hg > xemacs-beta
diff lisp/glyphs.el @ 412:697ef44129c6 r21-2-14
Import from CVS: tag r21-2-14
author | cvs |
---|---|
date | Mon, 13 Aug 2007 11:20:41 +0200 |
parents | 501cfd01ee6d |
children |
line wrap: on
line diff
--- a/lisp/glyphs.el Mon Aug 13 11:19:22 2007 +0200 +++ b/lisp/glyphs.el Mon Aug 13 11:20:41 2007 +0200 @@ -1,7 +1,7 @@ ;;; glyphs.el --- Lisp interface to C glyphs ;; Copyright (C) 1994, 1997 Free Software Foundation, Inc. -;; Copyright (C) 1995, 1996, 2000 Ben Wing. +;; Copyright (C) 1995, 1996 Ben Wing. ;; Author: Chuck Thompson <cthomp@cs.uiuc.edu>, Ben Wing <ben@xemacs.org> ;; Maintainer: XEmacs Development Team @@ -26,287 +26,27 @@ ;;; 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: -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; image specifiers +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; font 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. - -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). -" +specifiers." (make-specifier-and-init 'image spec-list)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; glyphs (defconst built-in-glyph-specifiers '(image contrib-p baseline) - "A list of the built-in glyph properties that are specifiers.") + "A list of the built-in face properties that are specifiers.") (defun glyph-property (glyph property &optional locale) "Return GLYPH's value of PROPERTY in LOCALE. @@ -547,7 +287,7 @@ "Change the image of GLYPH in LOCALE. SPEC should be an instantiator (a string or vector; see - `make-image-specifier' for a description of possible values here), + `image-specifier-p' 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. @@ -640,162 +380,20 @@ (set-glyph-property glyph 'baseline spec locale tag-set how-to-add)) (defun make-glyph (&optional spec-list type) - "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'. + "Return a new `glyph' object of type TYPE. -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.) +TYPE 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'. --- 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 instace, 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'. 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'." +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." (let ((glyph (make-glyph-internal type))) (and spec-list (set-glyph-image glyph spec-list)) glyph)) @@ -814,22 +412,38 @@ (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. -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'." +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'." (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. -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'." +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'." (make-glyph spec-list 'icon)) (defun nothing-image-instance-p (object) @@ -854,12 +468,9 @@ "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'." + "Return t if OBJECT is an image instance of type `subwindow'. +Subwindows are not implemented in this version of XEmacs." (and (image-instance-p object) (eq 'subwindow (image-instance-type object)))) ;;;;;;;;;; the built-in glyphs