Kimbrough%dsg@ti-csl.CSNET (Kerry Kimbrough) (08/31/87)
I think this point has been addressed in a previous message to this list, but I've forgotten the answer and I can't find it anywhere in the Xv11 protocol specification. If a client selects both ButtonPress and ButtonRelease events for window W, and receives a ButtonPress event with W as the "source", is he guaranteed also to receive a ButtonRelease event with W as the "source" (regardless of the position of the pointer at the time of the button's release)? Would this occur even if the client had *not* selected ButtonRelease events for window W? In the case that the pointer is in window Y at the time of the button's release, is a ButtonRelease event with Y as the "source" also sent to interested clients?
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/01/87)
Date: Mon, 31 Aug 87 13:24:00 CDT
From: Kerry Kimbrough <Kimbrough%dsg%ti-csl.csnet@RELAY.CS.NET>
If a client selects both ButtonPress and ButtonRelease events for window W, and
receives a ButtonPress event with W as the "source", is he guaranteed also to
receive a ButtonRelease event with W as the "source" (regardless of the position
of the pointer at the time of the button's release)?
Yes (provided he doesn't release the grab in the mean time).
Would this occur even if
the client had *not* selected ButtonRelease events for window W?
Yes.
In the case
that the pointer is in window Y at the time of the button's release, is a
ButtonRelease event with Y as the "source" also sent to interested clients?
No, because the button press caused a grab.Oren%Home@ti-csl.CSNET (LaMott Oren) (09/01/87)
No, because the button press caused a grab. It sounds like all clients expecting ButtonPress events should first grab the button(s). Is this correct? The X11 protocol document says: Grab Keyboard keys, the keyboard, pointer buttons, the pointer, and the server can be "grabbed" for exclusive use by a client. In general, these facilities are not intended to be used by normal applications, but are intended for various input and window managers to implement various styles of user interfaces. Since I'm interested in implementing "various input and window managers", I'd like to understand when to grab what for various interface styles. Is there a document you could forward to me that explains this? There are several other features of X11 that the protocol document explains what they do, but not what they're good for. For example, The Selection stuff (SetSelectionOwner GetSelectionOwner and ConvertSelection) and RotateProperties. Is there a window-manager manual that explains the usage of all the pre-defined atoms? I'm also confused about the use of SetInputFocus. Does the window-manager use this (i.e. so applications can't). How would I do something like direct all the keyboard input for an application to one of its sub-windows, without locking other applications use of the keyboard? In summary, all the X11 documentation I've seen describes mechanism only. I desperately need a system perspective so I can write tools and applications that work together with other X11 window-managers and applications. I realize you don't have time to write me an X tutorial, but I'd appreciate any documentation pointers you could give me.
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/02/87)
Date: Tue, 1 Sep 87 14:54:52 CDT
From: LaMott Oren <Oren%Home%ti-csl.csnet@RELAY.CS.NET>
No, because the button press caused a grab.
It sounds like all clients expecting ButtonPress events should first
grab the button(s). Is this correct?
You don't need to explicitly grab, the grab happens automatically on a
ButtonPress. The first paragraph of Section 12 on events in the protocol doc:
When a button is pressed with the pointer in some window W, and no active
pointer grab is in progress, then the ancestors of W are searched from the
root down, looking for a passive grab to activate. If no matching passive
grab on the button exists, then an active grab is started automatically for
the client receiving the event, and the last-pointer-grab time is set to the
current server time. The effect is essentially equivalent to a GrabButton
with arguments:
event-window: the event window
event-mask: the client's selected pointer events on the event window
pointer-mode and keyboard-mode: Asynchronous
owner-events: True if the client has OwnerGrabButton selected on the
event window, else False
confine-to: None
cursor: None
The grab is terminated automatically when all buttons are released.
UngrabPointer and ChangeActiveGrab can both be used to modify the active grab.
Since I'm interested in implementing "various input and window
managers", I'd like to understand when to grab what for various
interface styles. Is there a document you could forward to me that
explains this?
"It depends" is the only answer I have time for, there is no document.
You can study the existing window managers with the V11 release.
There are several other features of X11 that the protocol document
explains what they do, but not what they're good for. For example,
The Selection stuff (SetSelectionOwner GetSelectionOwner
and ConvertSelection) and RotateProperties.
True enough. The protocol document is not a primer, it is a
specification. I believe several people are writing books on X11, and
hopefuly they will answer some of your questions. For selections, you
can go a ways by looking at Xerox systems, and probably others.
Is there a window-manager manual that explains the usage of all the
pre-defined atoms?
I believe the C Xlib manual describes much of this, and the BuiltInAtoms
file with the server sources also gives some documentation.
I'm also confused about the use of SetInputFocus.
Does the window-manager use this (i.e. so applications can't). How would
I do something like direct all the keyboard input for an application to
one of its sub-windows, without locking other applications use of
the keyboard?
There are different religions on the use of focus. The protocol
provides a mechanism. Some people believe the focus should always be
PointerRoot, others believe click to type, others believe other things.
How an application should react depends on what philosophies it wants to
remain compatible with. One answer is that a vanilla application should
never set the focus, only window managers should. Another is that an
application can set the focus within itself, but only when it already
has the focus.
In summary, all the X11 documentation I've seen describes mechanism
only.
That is pretty much correct. That will change with time.
I desperately need a system perspective so I can write tools
and applications that work together with other X11 window-managers and
applications. I realize you don't have time to write me an X tutorial,
but I'd appreciate any documentation pointers you could give me.
There is precious little documentation. What you do depends on what you
want, and not everyone wants the same thing. The protocol is a place to
start, and gives people who never bothered to argue about these issues
with each other (because of basic system incompatibilities) a reason to
do so. There is knowledge in the heads of lots of people, and ingrained
knowledge in lots of X10 users, and lots of existing user interfaces to
rebuild on top of the protocol. As time goes on, more of this will get
documented and thrashed out. Right now, we're too busy trying to get
bits out the door.