On Mon, Aug 22, 2011 at 05:49:46PM +0900, Teika Kazura wrote: > Oops, I'm sorry for my last reply which misunderstood your issue.
> First the theory: In general, when an input event is "consumed", > then it's not propagated any more, so in this case, not sent to the > underlying window. If metacity always sends events, it's a bug, > too, in the opposite direction. I agree, but isn't the event defined as Alt-Button1-Move? as I said before, I'm totally fine that you cannot use Alt-Button-Move events inside a window, because those are handled by the window manager, but IMHO Alt-Button1 isn't Alt-Button-Move (because I still can decide to release the button without moving, no?) so, IMHO the events should work like this: Alt -> Alt down passed to app Alt-Button1 -> Button1 passed to app Alt-Button1-Move -> nothing passed, sawfish handles that Alt (Button Released) -> Button1 released passed to app (Alt Released) -> Alt released passed to app of course, if I define Alt-Button1 to have some meaning for sawfish, the only event the app will see by default is the Alt down/up > Sorry that it's not configurable in Sawfish, but there's a better > workaround; put the following in your ~/.sawfish/rc: > ------------------------------------------------------------------------ > (define (move-win-int-send w) > (require 'move-resize) > (move-window-interactively w) > (synthesize-event "Alt-Button1-Click" w)) this kind of flexibility is why I'm using sawfish :) > (define-command 'move-win-int-send move-win-int-send > #:spec "%W") > (bind-keys window-keymap "Alt-Button1-Move" 'move-win-int-send) > ------------------------------------------------------------------------ > Then Alt-Button1-click and release are always sent to the client. thanks for the quick reply, Herbert > Teika (Teika kazura) > --- > -- > Sawfish ML --- -- Sawfish ML
