tc2.4rc1 flwm restart - how to display=:1.0 support?

[bigpcman]

Robert I noticed you changed flwm_restart to :

Code: [Select]

#!/bin/sh
kill -s USR2 $WM_PID

It looks like this does a kill but not a start.

In order to get tightvnc to work I had to in previous releases change the restart to include display 1 as follows:

Code: [Select]

#!/bin/sh

restart() {
 sudo killall flwm
 DISPLAY=:0.0 flwm &
 [ -e /tmp/.X11-unix/X1 ] && DISPLAY=:1.0 flwm &
 }

 FLWMPID=$(pidof flwm)
 [ -n "$FLWMPID" ] && restart

Where would I put the "start" part now?

edit: I had to make similar changes in ".wmx/Refresh Menu in the past. I assume I will have to again?

[roberts]

That does not kill the window manager.
I asked Mike to accept a signal SIGUSR2 as I did for the old fluxbox in my former project.
The signal is processed by the running instance of flwm to rebuild the menu.
It makes for a smoother update of the dynamic menus.

As I am not familiar with your requirements, I can only suggest to be sure that such signal is sent to the current instance of flwm.

[bigpcman]

That does not kill the window manager.
I asked Mike to accept a signal SIGUSR2 as I did for the old fluxbox in my former project.
The signal is processed by the running instance of flwm to rebuild the menu.
It makes for a smoother update of the dynamic menus.

As I am not familiar with your requirements, I can only suggest to be sure that such signal is sent to the current instance of flwm.

OK, then that probably means I have to do something like:

DISPLAY=:0.0 kill -s USR2 $WM_PID
[ -e /tmp/.X11-unix/X1 ] && DISPLAY=:1.0 kill -s USR2 $WM_PID

[MikeLockmoore]

All that the signal USR2 does in the new flwm is cause flwm to rescan the content of the WM desktop menu.  If you are trying to force a restart flwm, perhaps you can use kill with no signal specified (default quit signal) or a signal other than USR2.

It's a bit misleading that "kill" is just a signal-sender.  It's up to each application to decide how to respond to each signal.  There are some default responses and conventions so that "kill" is usually doing what the name implies, but it's not always the case.  

EDIT: Would this work?

     kill `pidof flwm` ; DISPLAY=:1.0 flwm &
--
Mike L.

[bigpcman]

All that the signal USR2 does in the new flwm is cause flwm to rescan the content of the WM desktop menu.  If you are trying to force a restart flwm, perhaps you can use kill with no signal specified (default quit signal) or a signal other than USR2.

It's a bit misleading that "kill" is just a signal-sender.  It's up to each application to decide how to respond to each signal.  There are some default responses and conventions so that "kill" is usually doing what the name implies, but it's not always the case.  

EDIT: Would this work?

     kill `pidof flwm` ; DISPLAY=:1.0 flwm &
--
Mike L.

All I need is for the remote display to be the same as the local. So I guess as long as both the display 0 & 1 flwm instantiations rescan the menu and display changes that have been made my posted approach should work. I'll experiment over the next couple of days.