jdanner@oracle.com (John Danner) (12/13/90)
I have an application with multiple documents, and I need some way of determining which document is "current". Users make documents current by clicking on them on the Mac. The X equivalent seems to be FocusIn events, but under my current configuration of twm, I get these events whenever the cursor passes over a window. I know I can configure twm to set focus only when the user clicks, but other users may have their window managers set to give focus to windows when the cursor passes into them. I can't find anywhere in the ICCCM spec that dictates when a window manager should give focus to a window. If I can't differentiate between the user clicking on the title bar of the window and the cursor passing through the window, I can't see how to use focus events to indicate "current". Can anyone shed some light on this for me? Please reply directly, I don't read comp.windows.x regularly. Thanks John jdanner@oracle.com
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/13/90)
Focus is just so horrible you don't want to mess with it. But if you insist, there is a property called TAKE_FOCUS that is part of WM_PROTOCOLS. Look at it in the ICCCM manual. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
mouse@LARRY.MCRCIM.MCGILL.EDU (12/19/90)
> I have an application with multiple documents, and I need some way of > determining which document is "current". Users make documents > current by clicking on them on the Mac. The X equivalent seems to be > FocusIn events, Depending on precisely what you want, the equivalent is either ButtonPress or FocusIn. If you want to choose among multiple top-level windows, I would recommend FocusIn. > but under my current configuration of twm, I get these events > whenever the cursor passes over a window. I know I can configure twm > to set focus only when the user clicks, but other users may have > their window managers set to give focus to windows when the cursor > passes into them. Yes. I'm glad to see you're considering other configurations than the one you use. (No smiley; I'm serious. I've seen too many programs that break in one way or another when run under unconventional setups; the commonest problem is programs that ignore typein when the mouse isn't in their window, even if they've been given focus by the wm. If these had been tested by anyone but the developer(s)...grumble.) > I can't find anywhere in the ICCCM spec that dictates when a window > manager should give focus to a window. This is as it should be. Different window managers have different policies, and it is not the ICCCM's place to dictate which ones are or aren't acceptable (if it tried, it would be ignored instead of accepted...). > If I can't differentiate between the user clicking on the title bar > of the window and the cursor passing through the window, I can't see > how to use focus events to indicate "current". I don't see why not - if the focus is due to a transient passage over the window, you will get a FocusOut shortly, indicating that the window in question is no longer "current". If you get a FocusIn on some other one of your windows, then that one becomes current; if not, then it doesn't matter because you aren't going to get keystrokes anyway. Or so it seems to me...but I don't know all the details of your app. Is this not workable for some reason? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
carroll@cs.uiuc.edu (Alan M. Carroll) (12/20/90)
In article <9012190749.AA03861@Larry.McRCIM.McGill.EDU>, mouse@LARRY.MCRCIM.MCGILL.EDU writes: > > I have an application with multiple documents, and I need some way of > > determining which document is "current". Users make documents > > current by clicking on them on the Mac. The X equivalent seems to be > > FocusIn events, > > Depending on precisely what you want, the equivalent is either > ButtonPress or FocusIn. If you want to choose among multiple top-level > windows, I would recommend FocusIn. > I don't think that that's sufficient. Epoch faces this problem also, and in order for things to work (mostly) right, it is necessary to track both focus events and window transition events. I think that this is a serious problem that is simply not addressed under the current X windows conventions. -- Alan M. Carroll "It's psychosomatic. You need a lobotomy. Epoch Development Team I'll get a saw." CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll
mouse@larry.mcrcim.mcgill.EDU (01/06/91)
>>> I have an application with multiple documents, and I need some way >>> of determining which document is "current". Users make documents >>> current by clicking on them on the Mac. The X equivalent seems to >>> be FocusIn events, >> Depending on precisely what you want, the equivalent is either >> ButtonPress or FocusIn. If you want to choose among multiple >> top-level windows, I would recommend FocusIn. > I don't think that that's sufficient. Epoch faces this problem also, > and in order for things to work (mostly) right, it is necessary to > track both focus events and window transition events. Yes, you are of course correct. I apologize; I should have thought about it before posting. I even know this; when writing mterm's code to determine whether it has keyboard focus I had to go to some length to get it right. (I think it is sufficient to track FocusChangeMask, EnterWindowMask, and LeaveWindowMask on your top-level window and FocusChangeMask on the root of the screen you're on. The decision of what to do on each event received requires a couple of state variables, but I *think* I have it working. The table describing what actions to take in what circumstances is long enough that I'm reluctant to include it here; anyone who wants a copy can send me mail, and in the unlikely event that I get a great flood of requests, I'll post it. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu