dsr@luke.mitre.org (Douglas S. Rand) (10/11/90)
Why is it unacceptable to use CurrentTime in XtOwnSelection but not the base Xlib routine XSetSelectionOwner? I would like to handle the selection set in one place in my application but the one place will not usually have an event timestamp to work with. Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again... Amateur Radio: KC1KJ
keith@EXPO.LCS.MIT.EDU (Keith Packard) (10/11/90)
> Why is it unacceptable to use CurrentTime in XtOwnSelection but not > the base Xlib routine XSetSelectionOwner? It is unacceptable because Xt is attempting to provide ICCCM compliant interfaces. ICCCM specifies that CurrentTime is never an acceptable timestamp to use in selection interfaces. This convention (for it is unenforceable) avoids many race conditions between applications which will occur when using CurrentTime > I would like to handle > the selection set in one place in my application but the one place > will not usually have an event timestamp to work with. How can you talk about using selections without also talk about user-directed events which trigger them? Selections are a user-interface abstraction which provides applications a mechansim for communicating information relating to the current loci of user activities. They are not meant for general interprocess communication. Design your interfaces so that the user activity which eventually causes the selection to be owned passes the timestamp of that event through the various portions of the code so that you can comply with the ICCCM. Hard, but not impossible. If you are using selections for something other than the user-interface (like a print spooler), you're probably doing the wrong thing.