Re: Broken enter-exit focus behavior in 1.5.3



Am Mon, 30 Nov 2009 21:11:47 -0800
schrieb sand blarg net:

> Timo Korvola writes:
> > On Monday 30 November 2009 03:39:39 sand blarg net wrote:
> > > I first noticed this with the raise-lower-window-and-transients
> > > command, which I have bound to Mouse2 in titlebars.  The lowered
> > > window maintains the focus, when the new top window should get
> > > focus.
> > 
> > I cannot reproduce this.  If lowering causes the topmost window
> > under the pointer to change, the new window gets focus.  If
> > lowering does not cause the pointer to change window, focus remains
> > in the lowered window as it should.  Have you bound the command to
> > Button2-Click instead of Button2-Off?  Generally only menus should
> > be bound to Click actions.
> 
> Switching the command from Button2-Click to Button2-Off fixes that
> problem for me.  The documentation needs a note on when to use Click
> vs. Off.
> 
> > > I also found by accident that it screws up restoring focus
> > > after a (select-window) call.
> > 
> > Please elaborate.
> 
> Make sure you're using the enter-exit policy.  Bring up a terminal and
> run sawfish-client.  Evaluate (select-window).  The cursor changes to
> the selection cursor, and the terminal window loses focus.  Click on
> any window to do the selection.  The cursor turns back to normal, but
> no window has focus anywhere on the screen.
> 
> I have also just now found another, similar problem.  I have "A-F8"
> bound to resize-window-automatically (it's an old SGI window manager
> binding).
> 
>   (bind-keys window-keymap
>              "A-F8" 'resize-window-interactively)
> 
> When I hit A-F8, the window loses focus, I resize it normally, and
> when I click to exit the resize, no window gets focus.  This also
> happens sometimes (but not always) when I use "A-F7", bound to
> move-window-interactively.
> 
> > Ignoring grab-related events fixes some errors where focus is
> > directed to the window under pointer when it should be directed
> > somewhere else, typically to the parent of a transient window that
> > has closed.  It causes some errors where focus should be directed
> > to the window under pointer but is instead directed elsewhere.  It
> > is difficult to tell the two cases apart automatically, but the
> > latter type of errors is easier to deal with manually if you use
> > enter-click focus.
> 
> I have found that the following suits my purposes:
> 
>   (require 'sawfish.wm.focus)
>   (define (focus-enter-refocus-fun w mode)
>     (focus-revert))
>   (add-hook 'enter-notify-hook focus-enter-refocus-fun t)

Indeed. Thanks for catching this one. This should go in, but perhaps
there's a "better" way, than just hooking focus-revert (which should be
already called by the focus-mode) -- Timo?

> When processing an EnterNotify event, it focuses on a reasonable
> window based on the current pointer position.  It may break focus for
> deleted transient windows, but I have never noticed that in the past,
> and I'm noticing the new problems all the time.
> 
> Derek
> 

Chris



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]