Mercurial > hg > xemacs-beta
view man/external-widget.texi @ 4690:257b468bf2ca
Move the #'query-coding-region implementation to C.
This is necessary because there is no reasonable way to access the
corresponding mswindows-multibyte functionality from Lisp, and we need such
functionality if we're going to have a reliable and portable
#'query-coding-region implementation. However, this change doesn't yet
provide #'query-coding-region for the mswindow-multibyte coding systems,
there should be no functional differences between an XEmacs with this change
and one without it.
src/ChangeLog addition:
2009-09-19 Aidan Kehoe <kehoea@parhasard.net>
Move the #'query-coding-region implementation to C.
This is necessary because there is no reasonable way to access the
corresponding mswindows-multibyte functionality from Lisp, and we
need such functionality if we're going to have a reliable and
portable #'query-coding-region implementation. However, this
change doesn't yet provide #'query-coding-region for the
mswindow-multibyte coding systems, there should be no functional
differences between an XEmacs with this change and one without it.
* mule-coding.c (struct fixed_width_coding_system):
Add a new coding system type, fixed_width, and implement it. It
uses the CCL infrastructure but has a much simpler creation API,
and its own query_method, formerly in lisp/mule/mule-coding.el.
* unicode.c:
Move the Unicode query method implementation here from
unicode.el.
* lisp.h: Declare Fmake_coding_system_internal, Fcopy_range_table
here.
* intl-win32.c (complex_vars_of_intl_win32):
Use Fmake_coding_system_internal, not Fmake_coding_system.
* general-slots.h: Add Qsucceeded, Qunencodable, Qinvalid_sequence
here.
* file-coding.h (enum coding_system_variant):
Add fixed_width_coding_system here.
(struct coding_system_methods):
Add query_method and query_lstream_method to the coding system
methods.
Provide flags for the query methods.
Declare the default query method; initialise it correctly in
INITIALIZE_CODING_SYSTEM_TYPE.
* file-coding.c (default_query_method):
New function, the default query method for coding systems that do
not set it. Moved from coding.el.
(make_coding_system_1):
Accept new elements in PROPS in #'make-coding-system; aliases, a
list of aliases; safe-chars and safe-charsets (these were
previously accepted but not saved); and category.
(Fmake_coding_system_internal):
New function, what used to be #'make-coding-system--on Mule
builds, we've now moved some of the functionality of this to
Lisp.
(Fcoding_system_canonical_name_p):
Move this earlier in the file, since it's now called from within
make_coding_system_1.
(Fquery_coding_region):
Move the implementation of this here, from coding.el.
(complex_vars_of_file_coding):
Call Fmake_coding_system_internal, not Fmake_coding_system;
specify safe-charsets properties when we're a mule build.
* extents.h (mouse_highlight_priority, Fset_extent_priority,
Fset_extent_face, Fmap_extents):
Make these available to other C files.
lisp/ChangeLog addition:
2009-09-19 Aidan Kehoe <kehoea@parhasard.net>
Move the #'query-coding-region implementation to C.
* coding.el:
Consolidate code that depends on the presence or absence of Mule
at the end of this file.
(default-query-coding-region, query-coding-region):
Move these functions to C.
(default-query-coding-region-safe-charset-skip-chars-map):
Remove this variable, the corresponding C variable is
Vdefault_query_coding_region_chartab_cache in file-coding.c.
(query-coding-string): Update docstring to reflect actual multiple
values, be more careful about not modifying a range table that
we're currently mapping over.
(encode-coding-char): Make the implementation of this simpler.
(featurep 'mule): Autoload #'make-coding-system from
mule/make-coding-system.el if we're a mule build; provide an
appropriate compiler macro.
Do various non-mule compatibility things if we're not a mule
build.
* update-elc.el (additional-dump-dependencies):
Add mule/make-coding-system as a dump time dependency if we're a
mule build.
* unicode.el (ccl-encode-to-ucs-2):
(decode-char):
(encode-char):
Move these earlier in the file, for the sake of some byte compile
warnings.
(unicode-query-coding-region):
Move this to unicode.c
* mule/make-coding-system.el:
New file, not dumped. Contains the functionality to rework the
arguments necessary for fixed-width coding systems, and contains
the implementation of #'make-coding-system, which now calls
#'make-coding-system-internal.
* mule/vietnamese.el (viscii):
* mule/latin.el (iso-8859-2):
(windows-1250):
(iso-8859-3):
(iso-8859-4):
(iso-8859-14):
(iso-8859-15):
(iso-8859-16):
(iso-8859-9):
(macintosh):
(windows-1252):
* mule/hebrew.el (iso-8859-8):
* mule/greek.el (iso-8859-7):
(windows-1253):
* mule/cyrillic.el (iso-8859-5):
(koi8-r):
(koi8-u):
(windows-1251):
(alternativnyj):
(koi8-ru):
(koi8-t):
(koi8-c):
(koi8-o):
* mule/arabic.el (iso-8859-6):
(windows-1256):
Move all these coding systems to being of type fixed-width, not of
type CCL. This allows the distinct query-coding-region for them to
be in C, something which will eventually allow us to implement
query-coding-region for the mswindows-multibyte coding systems.
* mule/general-late.el (posix-charset-to-coding-system-hash):
Document why we're pre-emptively persuading the byte compiler that
the ELC for this file needs to be written using escape-quoted.
Call #'set-unicode-query-skip-chars-args, now the Unicode
query-coding-region implementation is in C.
* mule/thai-xtis.el (tis-620):
Don't bother checking whether we're XEmacs or not here.
* mule/mule-coding.el:
Move the eight bit fixed-width functionality from this file to
make-coding-system.el.
tests/ChangeLog addition:
2009-09-19 Aidan Kehoe <kehoea@parhasard.net>
* automated/mule-tests.el:
Check a coding system's type, not an 8-bit-fixed property, for
whether that coding system should be treated as a fixed-width
coding system.
* automated/query-coding-tests.el:
Don't test the query coding functionality for mswindows-multibyte
coding systems, it's not yet implemented.
author | Aidan Kehoe <kehoea@parhasard.net> |
---|---|
date | Sat, 19 Sep 2009 22:53:13 +0100 |
parents | 42375619fa45 |
children | 03ab78e48ef6 |
line wrap: on
line source
\input texinfo @c -*-texinfo-*- @setfilename ../info/external-widget.info @settitle The External Client Widget @ifinfo @dircategory XEmacs Editor @direntry * External Widget: (external-widget). External Client Widget. @end direntry @end ifinfo @node Top, Using an External Client Widget,, (dir) An @dfn{external client widget} is a widget that is part of another program but functions as an Emacs frame. This is intended to be a more powerful replacement for standard text widgets. @menu * Using an External Client Widget:: * External Client Widget Resource Settings:: * Motif-Specific Info About the External Client Widget:: * External Client Widget Internals:: @end menu @node Using an External Client Widget, External Client Widget Resource Settings, Top, Top @chapter Using an External Client Widget There are three different implementations of the external client widget. One is designed for use in Motif applications and is linked with the option @code{-lextcli_Xm}. Another is designed for non-Motif applications that still use the X toolkit; it is linked with the option @code{-lextcli_Xt}. The third is designed for applications that do not use the X toolkit; it is linked with the option @code{-lextcli_Xlib}. In order to use an external client widget in a client program that uses the X toolkit (i.e. either of the first two options described above), simply create an instance of widget type ExternalClient and link your program with the appropriate library. The corresponding header file is called @file{ExternalClient.h}. Documentation still needs to be provided for using the raw Xlib version of the external client widget. The external client widget will not do anything until an instance of Emacs is told about this particular widget. To do that, call the function @code{make-frame}, specifying a value for the frame parameter @code{window-id}. This value should be a string containing the decimal representation of the widget's X window ID number (this can be obtained by the Xt function @code{XtWindow()}). In order for the client program to communicate this information to Emacs, a method such as sending a ToolTalk message needs to be used. Once @code{make-frame} has been called, Emacs will create a frame that occupies the client widget's window. This frame can be used just like any other frame in Emacs. @node External Client Widget Resource Settings, Motif-Specific Info About the External Client Widget, Using an External Client Widget, Top @chapter External Client Widget Resource Settings The external client widget is a subclass of the Motif widget XmPrimitive and thus inherits all its resources. In addition, the following new resources are defined: @table @samp @item deadShell (class DeadShell) A boolean resource indicating whether the last request to the ExternalShell widget that contains the frame corresponding to this widget timed out. If true, no further requests will be made (all requests will automatically fail) until a response to the last request is received. This resource should normally not be set by the user. @item shellTimeout (class ShellTimeout) A value specifying how long (in milliseconds) the client should wait for a response when making a request to the corresponding ExternalShell widget. If this timeout is exceeded, the client will assume that the shell is dead and will fail the request and all subsequent requests until a response to the request is received. Default value is 5000, or 5 seconds. @end table The shell that contains the frame corresponding to an external client widget is of type ExternalShell, as opposed to standard frames, whose shell is of type TopLevelShell. The ExternalShell widget is a direct subclass of Shell and thus inherits its resources. In addition, the following new resources are defined: @table @samp @item window (class Window) The X window ID of the widget to use for this Emacs frame. This is normally set by the call to @code{x-create-frame} and should not be modified by the user. @item deadClient (class DeadClient) A boolean resource indicating whether the last request to the corresponding ExternalClient widget timed out. If true, no further requests will be made (all requests will automatically fail) until a response to the last request is received. This resource should normally not be set by the user. @item ClientTimeout (class ClientTimeout) A value specifying how long (in milliseconds) the shell should wait for a response when making a request to the corresponding ExternalClient widget. If this timeout is exceeded, the shell will assume that the client is dead and will fail the request and all subsequent requests until a response to the request is received. Default value is 5000, or 5 seconds. @end table Note that the requests that are made between the client and the shell are primarily for handling query-geometry and geometry-manager requests made by parent or child widgets. @node Motif-Specific Info About the External Client Widget, External Client Widget Internals, External Client Widget Resource Settings, Top @chapter Motif-Specific Info About the External Client Widget By default, the external client widget has navigation type @samp{XmTAB_GROUP}. The widget traversal keystrokes are modified slightly from the standard XmPrimitive keystrokes. In particular, @kbd{@key{TAB}} alone does not traverse to the next widget (@kbd{Ctrl-@key{TAB}} must be used instead), but functions like a normal @key{TAB} in Emacs. This follows the semantics of the Motif text widget. The traversal keystrokes @kbd{Ctrl-@key{TAB}} and @kbd{Shift-@key{TAB}} are silently filtered by the external client widget and are not seen by Emacs. @node External Client Widget Internals, , Motif-Specific Info About the External Client Widget, Top @chapter External Client Widget Internals The following text is lifted verbatim from Ben Wing's comments in @file{ExternalShell.c}. This is a special Shell that is designed to use an externally- provided window created by someone else (possibly another process). That other window should have an associated widget of class ExternalClient. The two widgets communicate with each other using ClientMessage events and properties on the external window. Ideally this feature should be independent of Emacs. Unfortunately there are lots and lots of specifics that need to be dealt with for this to work properly, and some of them can't conveniently be handled within the widget's methods. Some day the code may be rewritten so that the embedded-widget feature can be used by any application, with appropriate entry points that are called at specific points within the application. This feature is similar to the OLE (Object Linking & Embedding) feature provided by MS Windows. Communication between this shell and the client widget: Communication is through ClientMessage events with message_type EXTW_NOTIFY and format 32. Both the shell and the client widget communicate with each other by sending the message to the same window (the "external window" below), and the data.l[0] value is used to determine who sent the message. The data is formatted as follows: data.l[0] = who sent this message: external_shell_send (0) or external_client_send (1) data.l[1] = message type (see enum en_extw_notify below) data.l[2-4] = data associated with this message EventHandler() handles messages from the other side. extw_send_notify_3() sends a message to the other side. extw_send_geometry_value() is used when an XtWidgetGeometry structure needs to be sent. This is too much data to fit into a ClientMessage, so the data is stored in a property and then extw_send_notify_3() is called. extw_get_geometry_value() receives an XtWidgetGeometry structure from a property. extw_wait_for_response() is used when a response to a sent message is expected. It looks for a matching event within a particular timeout. The particular message types are as follows: 1) extw_notify_init (event_window, event_mask) This is sent from the shell to the client after the shell realizes its EmacsFrame widget on the client's "external window". This tells the client that it should start passing along events of the types specified in event_mask. event_window specifies the window of the EmacsFrame widget, which is a child of the client's external window. extw_notify_init (client_type) When the client receives an extw_notify_init message from the shell, it sends back a message of the same sort specifying the type of the toolkit used by the client (Motif, generic Xt, or Xlib). 2) extw_notify_end () This is sent from the shell to the client when the shell's EmacsFrame widget is destroyed, and tells the client to stop passing events along. 3) extw_notify_qg (result) This is sent from the client to the shell when a QueryGeometry request is received on the client. The XtWidgetGeometry structure specified in the QueryGeometry request is passed on in the EXTW_QUERY_GEOMETRY property (of type EXTW_WIDGET_GEOMETRY) on the external window. result is unused. In response, the shell passes the QueryGeometry request down the widget tree, and when a response is received, sends a message of type extw_notify_qg back to the client, with result specifying the GeometryResult value. If this value is XtGeometryAlmost, the returned XtWidgetGeometry structure is stored into the same property as above. [BPW is there a possible race condition here?] 4) extw_notify_gm (result) A very similar procedure to that for extw_notify_qg is followed when the shell's RootGeometryManager method is called, indicating that a child widget wishes to change the shell's geometry. The XtWidgetGeometry structure is stored in the EXTW_GEOMETRY_MANAGER property. 5) extw_notify_focus_in (), extw_notify_focus_out () These are sent from the client to the shell when the client gains or loses the keyboard focus. It is done this way because Xt maintains its own concept of keyboard focus and only the client knows this information. @summarycontents @contents @bye