Thomas Adam wrote: > On 18 April 2012 19:04, Christian Weisgerber <na...@mips.inka.de> wrote: >> Alexei Malinin <alexei.mali...@mail.ru> wrote: >>> At a time when I listen to music on the xmms >>> and simultaneously begin to move any X window, >>> the sound stops. The sound resumes after finishing >>> of moving of the window . >> Yes. For some window operations like moving or resizing windows, >> window managers (at least twm, fvwm, mwm) cause all window updates >> to stop, in turn causing applications to stop. This is very >> noticeable with xterm and programs running in xterm. As you have >> noticed, xmms also stops. > > Window managers like twm and FVWM which hail from the days when moving > windows which were still mapped fully caused problems, would often > draw a window outline instead to represent the window. During the > move/resize operation (leading to a huge round-trip of ConfigureNotify > events) these could be effectively ignored until the actual placement > of the window had been made, and then the window would redraw > correctly. > > During the entire time the window is being moved though, the XServer > is grabbed. This has the effect that all applications "stop" -- and > for most applications -- XMMS included -- this often means they're > interrupted since the events destined for the windows are queued > pending the eventual XServer ungrab. > > To this end, FVWM solves this with OpaqueMove, as does TWM. > > So I would say to the OP that he looks at the following TWM options: > > NoGrabServer > OpaqueMove
Thank you for explanation, Thomas. I have "NoGrabServer" option in my .twmrc, I'll try "OpaqueMove" option next week... -- Alexei Malinin
