I sent the below request to the sawfish developer group and got a couple of responses. They seem to think it's a mistake to handle your own dragging. I have noticed some strange artifacts (large delays in actual window motion) as well in just normal operation that could be attributed to self-handled window dragging. Anybody have any ideas or comments how to solve this one? 1. Pass events back to the window manager. 2. Add hooks for each window manager (uggh). 3. Let the window managers to the moving. > kristian kvilekval writes: > |I've noticed that some programs that draw their own > |non-client areas (example xmms and freeamp) > |cannot be dragged from one viewport to another. > |Is this a bug in xmms and freeamp or a bug in sawfish? > > Neither really. Xmms implements it's own window dragging, and since it > doesn't understand viewports it doesn't know when to switch to the > adjacent one (and while xmms is dragging the window, sawfish doesn't > see the pointer events that it uses to trigger switching viewport) > > John > Neither, really, though it's maybe a misfeature for those applications > to try to do their own window management. If you have a binding for > move-selected-window or move-window-interactively, you can get sawfish > to move your xmms window; if you do this, then you can drag it from > one viewport or workspace to another. > > -- > +----------------------------------------------------------------+ > | Jason F. McBrayer [EMAIL PROTECTED] | > | The scalloped tatters of the King in Yellow must hide Yhtill | > | forever. R.W. Chambers _The King in Yellow_ | > -- Kristian G. Kvilekval email:[EMAIL PROTECTED] office:(805)893-4178 http://www.cs.ucsb.edu/~kris _______________________________________________ [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/freeamp-dev
