diff options
| -rw-r--r-- | xembed/ChangeLog | 5 | ||||
| -rw-r--r-- | xembed/spec/xembed-spec.xml | 36 |
2 files changed, 23 insertions, 18 deletions
diff --git a/xembed/ChangeLog b/xembed/ChangeLog index 108f280..045390c 100644 --- a/xembed/ChangeLog +++ b/xembed/ChangeLog @@ -1,3 +1,8 @@ +Sun Apr 21 15:30:21 2002 Owen Taylor <otaylor@redhat.com> + + * spec/xembed-spec.xml: Typo fixes from Matthias Clasen, + spelling checked. + Sun Apr 21 09:20:30 2002 Owen Taylor <otaylor@redhat.com> * Reorganize, add test cases in tests/ diff --git a/xembed/spec/xembed-spec.xml b/xembed/spec/xembed-spec.xml index b60a2e1..78734a5 100644 --- a/xembed/spec/xembed-spec.xml +++ b/xembed/spec/xembed-spec.xml @@ -102,7 +102,7 @@ <para> A toplevel window is <firstterm>active</firstterm> if it currently is receiving keyboard events. (The window or a - descendent has the X keyboard focus.) A widget within the + descendant has the X keyboard focus.) A widget within the toplevel is active if the toplevel is active, regardless of whether that widget has the input focus within the toplevel. @@ -188,7 +188,7 @@ these areas. Communication in XEmbed is done by forwarding slightly modified XEvents using <function>XSendEvent()</function>, - by sending special xembed messages, and by setting X properties. In addition, + by sending special XEmbed messages, and by setting X properties. In addition, standard ICCCM features like WMNormalHints are used where appropriate. </para> @@ -210,8 +210,8 @@ <para> Unfortunately, there are no such messages like WindowActivate or WindowDeactivate in the X protocol. Instead, a window knows - that it is active when it receives keyboard focus (XFocusInEvent - with certain modes) or looses it (XFocusOutEvent with certain + that it is active when it receives keyboard focus (FocusIn + event with certain modes) or looses it (FocusOut event with certain modes). This applies to embedded child windows only, when the mouse pointer points onto one of the child's subwindows in the very moment the window manager puts the X focus on the toplevel @@ -255,7 +255,7 @@ their respective embedder. In order to support multiple levels of embedding, events that stem from a SendEvent request had to be forwarded as well. While this is a possible solution, it adds both - race conditions and inefficency + race conditions and inefficiency. </para> <para> The solution proposed by XEmbed is is to beat X11 with its own @@ -281,7 +281,7 @@ <para> The trouble with this is, that you should not use <function>XSetInputFocus()</function> without a proper time stamp from the Server, to avoid race - conditions. Unfortunately, the XFocusIn even does not carry a + conditions. Unfortunately, the FocusIn event does not carry a timestamp. The solution to this is, to ask the window manager for the WM_TAKE_FOCUS window protocol. Thus, whenever the window is activated, it will receive a WM_PROTOCOLS client message with @@ -396,7 +396,7 @@ makes it possible to support embedded windows. Basically, the embedder has to operate as drag-and-drop proxy for the client. Any XDND messages like XdndEnter, Xdnd,Leave, etc. simply have to be - passed through. A toollkit's XDND implementation has to take this + passed through. A toolkit's XDND implementation has to take this situation in consideration. </para> </sect2> @@ -655,7 +655,7 @@ <title>XEMBED_REQUEST_FOCUS</title> <para> Sent from the client to the embedder when the client wants - focus. The most common ocassion is when the user clicks into one + focus. The most common occasion is when the user clicks into one of the client's child widgets, for example a line editor, in order to type something in. </para> @@ -663,7 +663,7 @@ The message is passed along to the topmost embedder that eventually responds with a XEMBED_FOCUS_IN message. The focus in message is passed all the way back until it reaches the original - focus requestor. In the end, not only the original client has + focus requester. In the end, not only the original client has focus, but also all its ancestor embedders. </para> </sect2> @@ -716,7 +716,7 @@ <title>XEMBED_FOCUS_NEXT</title> <para> Sent from the client to the embedder when it reaches the end of - its logical tab chain after the user tabbed forwards. If the + its logical tab chain after the user tabbed forward. If the embedder has siblings that accept tab focus, it will do a virtual tab forward. As a result, it will loose focus itself and consequently send an XEMBED_FOCUS_OUT message to the client @@ -727,7 +727,7 @@ <para> Sent from the client to the embedder when it reaches the beginning of its logical tab chain after the user tabbed - backwards. If the embedder has siblings that accept tab focus, it + backward. If the embedder has siblings that accept tab focus, it will do a virtual tab backward. As a result, it will loose focus itself and consequently send an XEMBED_FOCUS_OUT message to the client @@ -793,7 +793,7 @@ </note> <para> The modified bit field is a bitwise OR of values indicating - various accelerators; these indicate logical accelerator + various modifiers; these indicate logical accelerator keys rather than corresponding directly to the bits in the XKeyEvent state field. </para> @@ -840,7 +840,7 @@ </tgroup> </table> <para> - Hint to implementators: It is the responsibility of the + Hint to implementors: It is the responsibility of the embedder to keep track of all forwarded accelerators and to remove them when the client window dies. </para> @@ -957,7 +957,7 @@ untrap_errors(void) </para> <para> Key events are forwarded by changing the event's window field - to the window handle of the client and sending the modifed + to the window handle of the client and sending the modified message via <function>XSendEvent()</function> to the embedder, with no event mask and propagation turned off. </para> @@ -1071,7 +1071,7 @@ void send_xembed_message( messages qualify for that. </para> <para> - Hint to implementators: Check that the xembed time stamp + Hint to implementors: Check that the xembed time stamp is actually later than your current x time. While this cannot happen with ordinary XEvents, delayed client messages may have this effect. Be prepared that evil implementations may even @@ -1220,7 +1220,7 @@ void send_xembed_message( <para> Toolkits such as Qt and GTK+ have a concept of disabled widgets. This notion is typically hierarchical, so if - the embedder or a ancestory of the embedder becomes + the embedder or a ancestry of the embedder becomes insensitive, widgets inside the client should be displayed as, and act insensitive as well. </para> @@ -1277,7 +1277,7 @@ void send_xembed_message( <sect2> <title>Propagation of key presses</title> <para> - It's frequently useful to have keybindings that trigger on + It's frequently useful to have key bindings that trigger on a widget if the focus is on a child of that widget. For instance, <keysym>Control</keysym><keysym>PageUp</keysym> and <keysym>Control</keysym><keysym>PageUp</keysym> switch @@ -1363,7 +1363,7 @@ void send_xembed_message( <listitem> <para> Added text about the independence of FOCUS_IN/OUT and - ACTIVATE/DEACTIVE to the description of + ACTIVATE/DEACTIVATE to the description of XEMBED_WINDOW_ACTIVATE / XEMBED_WINDOW_DEACTIVATE. </para> </listitem> |