Hi Dominik, > Well, it has all been discussed in that old thread.
Many of the issues surrounding how _FVWM_ might detect if a function needs to grab or not have been discussed, & I agree with you - it's going to be very, very difficult ... at best. However, I feel that Dan's idea (to allow the _user_ to specify if a function needn't grab) didn't receive the discussion it merited. Maybe because the "discussion" had deteriorated quite a bit by the time he suggested it ...? > The fact that fvwm needs to grab the pointer in some cases is > mostly unrelated to the action's type. Some complex functions > need to grab the pointer to make sure the user or other > applications does not interfere with function execution: Agreed. > * The user might push or release a mouse button which causes > EnterNotify/LeaveNotify events that can confuse (immediate) > complex functions that raise or lower windows or fiddle with > the focus (or do other things that I can not think of). > > We once tried to remove the grab, and functions using > Raise/Lower + WarpPointer + Focus could not do their job > anymore. > > * What would commands like Move or Resize be good for without a > grab? Fvwm would freeze until the grab ends. > > * The PointerWindow command could have very undesirable results > without a grab. For example, I have something like this in my > config: > > Key d A SCM my_close > AddToFunc my_close > + I Silent PointerWindow Close > > If the pointer can be warped by an application during function > execution, a random window might be closed. > > * You can not even know which commands need to run in case of > Read or PipeRead. I agree with all of that. > I agree that a failed grab can cause lots of problems. Hopefully > it's clear that many immediate functions may need the grab too. Yes. > But I have no idea how to decide if a certain function needs it or > not. Me neither. My question about what to do with a non-immediate condition in a NoGrab function was about whether such a case was a blatant error. I've no intention of writing code to catch all abuses of NoGrab. If we could somehow miraculously implement the black-list you mention there'd be no need for a NoGrab option in the first place, because FVWM could determine all by itself whether a grab was required. I accept that it is too difficult to do this, which is why I think allowing the user to specify "NoGrab" when it's needed would be an acceptable compromise. > I would agree to a "nograb" patch if it > > 1) *enforces* proper operation, i.e. refuses to define > "nograb" functions that are potentially unsafe. > > AND > > 2) adds useful functionality (doubtful, considering the length of > the blacklist above). By this metric, I openly admit that the DefineFunc patch fails on requirement 1). IMHO, other posts already show that (even if we were to restrict the available functions) a NoGrab option will still be useful. Having said that, I feel that requirement 1) is a little draconian. I share your concern for restricting _anything_ unsafe in FVWM. However, I don't think the DefineFunc patch is particularly unsafe. The default behaviour is always to grab; it doesn't break any existing configs; users will never notice a difference in behaviour unless they _explicitly_ use NoGrab. (A minority of users?) Then, the onus is upon the user to use NoGrab in a valid way - it's only here that there is scope for misuse. With a properly documented entry in the man page, I hope this will be rare. Before I end this post I just want to repeat my main point: By using the "NoGrab" option, the decision not to grab the pointer is made by the _user_, not _FVWM_. SCoTT.
