Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: bigpcman on September 20, 2009, 07:56:02 PM
-
Robert I noticed you changed flwm_restart to :
#!/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:
#!/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?
-
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.
-
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
-
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 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.