alan@APPLE.COM (Alan Mimms) (04/14/89)
Does it make sense to say that the server grabbing and ungrabbing requests CAN'T be nested? The sample server seems to implement this functionality in a way that will NOT properly handle nesting of grabs and ungrabs (where "properly" is defined as "in a way that works when the user wishes ONLY the most recent grab to be ungrabbed, leaving 'outer nested' grabs active until they, in turn, are ungrabbed"). I note with interest that "twm" does nested grabs quite a lot. When it is adding a window to is managed list, it grabs the server and then calls alot of other routines which eventually result in several grab/ungrab combinations. Finally, it does an ungrab -- ostensibly to release the original server grab. Does anyone have any comments? Am I completely out to lunch? Alan Mimms My opinions are generally Communications Product Development Group pretty worthless, but Apple Computer they *are* my own... "The company has new jobs and Jobs has a new company" -- Harry Anderson
fisher@decwin.DEC.COM (VMS DECwindows Engineering, 381-1466) (04/14/89)
I was about to tell you that grabs don't nest, and that the client should look at the "Already Grabbed" status that comes back and not do the ungrab if they come back. Alas, a quick check proves that this status is only returned for grabbing keys and mice. Bummer. The protocol says nothing about nesting grabs; therefore they don't nest. Therefore, the sample server is doing it right. You can argue that this is a bug in the protocol, but I don't think you can argue that it is a bug in the server. Of course, one can always implement the nesting functionality at the client level quite easily by keeping a ref count and only sending the grab to the server when the count is 0 and only sending the ungrab when the count is one. (You don't have to worry about other clients horning in when the count is non-zero, obviously). Burns
fisher@decwin.DEC.COM (VMS DECwindows Engineering, 381-1466) (04/15/89)
Well, I agree with your sentiments, and if this were 2 years ago, I would push for the change. Now, however, there may well be applications which depend on the existing behavior. I don't think we can just change the protocol out from under everyone. I think that now, the right solution is to add an Xlib call XGrabServerNested or some such which does the ref counting as I suggested before. One would have to define how it works with the normal old XGrabServer, and whether there is an XUngrabServerNested, or whether the existing one will suffice. This solution fits much better into the X philosophy: Let the client do any work that it can. Note that most if not all of the hair that is in the protocol relates to inter-client issues. There is little if any help for individual clients. (Note, for example, the lack of a GetGC). Burns
alan@APPLE.COM (Alan Mimms) (04/15/89)
The problem is that the client is calling several levels of internal routine -- some of which might be supplied by outside parties -- any of which might be grabbing the server and then ungrabbing it. This (In My [sometimes] Humble Opinion) is a pretty strong argument for a (slight) change to the protocol to permit nesting of server grabs. Implementation of the changes necessary to do this nesting is about three or four lines added to dix/dispatch.c in the ProcGrabServer and ProcUngrabServer routines, I think. Alan Mimms My opinions are generally Communications Product Development Group pretty worthless, but Apple Computer they *are* my own... "The company has new jobs and Jobs has a new company" -- Harry Anderson
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/17/89)
It's not entirely obvious to me whether nesting is Right or Wrong. But, by now, there are almost certainly applications written according to the current non-nested semantics. Changing the protocol would be a Mistake, particularly since, as Burns points out, the nesting could be handled on the client side.