On Fri, Apr 13, 2012 at 01:25:33PM +0200, JUNG, Christian wrote: > Thomas Adam wrote: > > > > > > > > DestroyFunc foo > > > > AddToFunc foo > > > > + I PipeRead `echo Move` > > > > + I PipeReaad `[ $[w.x] -lt $SOME_VALUE ] && echo "Move > > somewhere else"` > > > > > It can, but note that this hypothetical "foo" function _explicitly_ > > indicates moving the window. Listening for ConfigureNotify events via > > FvwmEvent as you're proposing also has the added (dis)advantage that > > *resizing* the window, be it deliberately or through program-specified > > reasons, is then taken in to consideration. > > > > You probably don't want that in all cases, I'd have thought. > > > You're right. Resizing a window should be handled differently (the window > should be resized to the working area for example and not moved after > resizing it). > > The explicit "Move" in your example works only for click-and-move and not > drag-move operations or am I wrong?
I am not sure of the difference, and it makes no odds -- it depends how the Move command is invoked, and with what options. But it will be more useful for interactive moves; manual moves using the mouse more than it will just issuing a Move command to a specific area of the screen. As I said before -- Move honours the EWMH working area by default when used non-interactively. Confer the following: EwmhBaseStruts 100 100 100 100 Pick Move 0 0 [ Move the window else, somewhere randomly ] Pick Move 0 0 ewmhiwa In the case of limiting windows to the EWMH working area interactively, this isn't happening yet, hence my hack from a previous reply in this thread. -- Thomas Adam
