On Sat, Aug 20, 2011 at 08:33:44PM +0200, Christopher Roy Bratusek wrote: >> yes, it persists, for the click to focus event, there >> is an alternative which passes through the events but >> for the move-window-interactively there doesn't seem >> to be one ... anyway I worked around that (for now) >> by changing the move-window-interactively to a different >> key/button combination ...
>> best, >> Herbert > Well, there's a difference between a B1Click and Alt-B1Click: > Alt-B1Click is bound to a command, while B1Click is only "focus > that window". Thus Sawfish will pass the event through (if > choosen) for the later, but not for the former. So this is > actually not a bug, it's just an conflicting keybinding. > Ways to solve the issue > - (as you did): change Alt-B1Click to something else > - change the application's binding > - use keymap-trans. keymap-trans is a window-rule, which > sends a different event to the given window, as the one > you typed. Example: > press C-n but let window receive C-S-t (this way I make > konsole act like Editors when I'm about adding a new > Terminal-Tab). > This works pretty simple: > ( add-window-matcher '( (WM_CLASS . "^Konsole/konsole$" ) ) > ( keymap-trans . ( ( "C-n" "C-S-t" ) ) ) ) > should be straight forward. well, I agree that there are many workarounds, but I still do not understand why they are necessary, for example the same Alt-Button1-Move gesture to move windows works just fine in metacity, but the application still receives the Alt/Button1 down/up events, and thus, can react on them I understand that there is no sane way to handle the Move part (i.e. to pass it to the application) but that's not what I'm talking about .... HTC, Herbert > Chris > --- > -- > Sawfish ML --- -- Sawfish ML
