Bill, did you miss this? I posted it in a message to Kirill. It's in one of my
workspaces.
DEFUN ("popup-dialog-box", Fpopup_dialog_box, 1, 1, 0, /*
Pop up a dialog box.
There are numerous ways to specify how a dialog box will look.
They are indicated by symbols, which are:
'built-in'
Indicates a window-system-specific, built-in fully-formed dialog box
(such as the "common dialog boxes" under MS Windows, which include file
dialog boxes, print setup boxes, etc.).
'standard'
Indicates that XEmacs creates the dialog box by making a frame and
populating it with a single layout glyph, containing subglyphs, etc.
and the result looks like a dialog box.
'peer'
Indicates that XEmacs creates the dialog box on the "peer" side, i.e.
using the standard widgets/controls and layout mechanisms available
in the graphics API's we're dealing with.
`peer' support and `built-in' support is obviously highly window-system
and window-toolkit dependent. `standard' support is less dependent;
although it does make use of basic controls/widgets supplied by the
window system and window toolkit, the layout and all higher-level input
and output is controlled by XEmacs in an architecture-independent fashion.
NOTE: Standard support is not implemented yet (the glyphs that correspond
to controls/widgets have been implemented), we just haven't yet gotten them
to go into a frame by themselves.
Normally, a dialog box description is a cons of a symbol indicating
the format of the dialog box description, which is followed by the description
itself.
For backward compatibility: If the first element of the dialog box
description is a string, then it is assumed that this is the start of a
`peer'-type description.
For a built-in type description:
--------------------------------
The description is a list. The first element is the particular dialog box
to be displayed; this can be one of
color
find
font
open A file dialog box.
print
page-setup
replace
save-as
The rest of the description becomes the descriptor for the particular type
of built-in dialog box. They are:
open and save-as:
(INITIAL-FILENAME CALLBACK :keyword value ...)
INITIAL-FILENAME holds the initial filename to be placed in the dialog box.
CALLBACK is code that will be called when the dialog box is closed down
normally; it is called with one argument, the filename selected by the user.
The keywords are
:initial-directory dir
:filter-list (filter-desc filter ...)
:title string
:allow-multi-select t or nil
:create-prompt-on-nonexistent t or nil
:overwrite-prompt t or nil
:file-must-exist t or nil
:no-network-button t or nil
:no-read-only-return t or nil
#### unfinished
For a peer type description:
----------------------------
The first element of a description must be a string, which is the title or
question.
The rest of the elements are descriptions of the dialog box's buttons.
Each of these is a vector, the syntax of which is essentially the same as
that of popup menu items. They may have any of the following forms:
[ "name" callback <active-p> ]
[ "name" callback <active-p> "suffix" ]
[ "name" callback :<keyword> <value> :<keyword>
<value> ... ]
The name is the string to display on the button; it is filtered through the
resource database, so it is possible for resources to override what string
is actually displayed.
Accelerators can be indicated in the string by putting the sequence
"%_" before the character corresponding to the key that will invoke
the button. Uppercase and lowercase accelerators are equivalent. The
sequence "%%" is also special, and is translated into a single %.
If the `callback' of a button is a symbol, then it must name a command.
It will be invoked with `call-interactively'. If it is a list, then it is
evaluated with `eval'.
One (and only one) of the buttons may be `nil'. This marker means that all
following buttons should be flushright instead of flushleft.
Though the keyword/value syntax is supported for dialog boxes just as in
popup menus, the only keyword which is both meaningful and fully implemented
for dialog box buttons is `:active'. */
(dbox_desc))
"William M. Perry" wrote:
What do people think the best way to allow access to built-in dialogs
like
file dialogs, font-selection, etc, etc, should work? I don't like the idea
of just writing one using the new gtk/glyph support. This would be an
interface onto GetOpenFileName() / GtkFileSelection.
Should popup-dialog-box be extended, or does a new function need to be
written?
You could extend the syntax that popup-dialog-box expects by substituting a
symbol as the first item in the list (as opposed to a string). The rest of
the list would be a property list modifying the default behaviour of the
system dialog (is the file for opening or saving? font choice restrions?
blah blah blah).
-Bill P.
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also
http://www.666.com/ben/typing.html.