On Mon, Nov 24, 2008 at 06:47:09PM +0100, Harald Dunkel wrote: > I am running the snapshot of yesterday (2008/11/23) on 2 screens. The second > screen gets its own fvwm. Both share the same .fvwm2rc file, AFAICS. > > Problem: If I click on [Restart] on the first screen, then its fvwm exits > instead. Twm is started as a fallback. The error log file says > > [fvwm.0][SetupICCCM2]: <<ERROR>> another ICCCM 2.0 compliant WM is running, > try -replace > > The fvwm on the second screen is still running.
How do you start fvwm (what does the command line look like). > In a new session: > If I click in [Restart] on the second screen, then its fvwm is restarted. The > first fvwm doesn't notice. Both window managers are running independent from > each other after this. Both can be restarted without being kicked out. Hm, the code in fvwm.c:main(), fvwmc:Dome() and icccm2.c:SetupICCCM2() doesn't seem to handle multi screen restarts at all. TO mee it looks like a random fvwm instance gets ownership of the _XA_WM_SX atom via the call of XSetSelectionOwner(). Only this instance can be restarted, and the instance on the first screen can *never* be restarted because it tries to start on every screen. To fix this, we would have to write code so that: * Only the master instance calls XSetSelectionOwner(). * If the master is restarted, it has to shut down the copies on the other screens by sending some signal and wait until all other instances have exited. This might take a long time. We can *not* simply wait for all children to exit, because the modules are children too. * If some other instance is restarted, the restart command and all its arguments would have to be communicated to the master instance. The master instance would then restart as described above. I think this involves opening some command pipe to the fvwm copies. * All of this also applies to shutting down. I don't think I'll have the time to do this, but I'd accept and proof read patches. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
