Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: bigpcman on May 21, 2009, 11:21:45 PM
-
I've been breaking my pick the last few days trying to figure out how to maintain two instantiations of wbar one for DISPLAY=0.0 and one for DISPLAY=1.0. The only problem I have left is that when an update occurs all wbar processes are killed off but only one is restarted. Is there a way to restart wbar for both displays?
#!/bin/sh
cd "$HOME"
if [ $(awk '/icons:/{print $2}' "$HOME"/.desktop) == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
wbar -bpress -config /usr/local/tce.wbar > /dev/null &
fi
~
-
I don't have a setup such as yours to try...
But does a pidof wbar on each separate display return only one and the correct one for that display?
If so then killall could be replaced with a kill of the specific returned pid.
-
I don't have a setup such as yours to try...
But does a pidof wbar on each separate display return only one and the correct one for that display?
If so then killall could be replaced with a kill of the specific returned pid.
Thanks for the response. The pidof command does report both display wbars. However, since I start the display 1.0 wabr using /usr/bin/wbar I can differentiate the two instantiations in the ps output.
What I would prefer to do is restart both the wbars in the script so they are in sync using the DISPLAY command:
DISPLAY=:0.0 wbar
DISPLAY=:1.0 wbar
Would this work?
-
If that works then modify /usr/bin/wbar.sh and then make the modified file a .tce, perhaps wbar_multi.tce to overwrite the standard with your custom one.
-
If that works then modify /usr/bin/wbar.sh and then make the modified file a .tce, perhaps wbar_multi.tce to overwrite the standard with your custom one.
I have changed the wbar script as shown below and it does fix the wbar restart problems. Both displays 0.0 and 1.0 are restarted and are in sync when new applications are added. Good news!
Now then I suppose there should be a test before restarting display 1.0 wbar to make sure it was active in the first place. Is there a way to start wbar such that ps can identify it was started for display 1.0?
#!/bin/sh
cd "$HOME"
if [ $(awk '/icons:/{print $2}' "$HOME"/.desktop) == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
DISPLAY=:0.0 wbar -bpress -config /usr/local/tce.wbar > /dev/null &
DISPLAY=:1.0 wbar -bpress -config /usr/local/tce.wbar > /dev/null &
fi
-
Often I check if X is running by checking the existence of /tmp/.X11-unix/X0
Perhaps you can check to see if you have a /tmp/.X11-unix/X1
-
A simpler solution might be to make a symlink to wbar with a unique name. In that case the command name used by killall is the name of the symlink.
EDIT: I see Lee has already mentioned that in this thread:
http://forum.tinycorelinux.net/index.php?topic=1637.0
-
Yes indeed /tmp/.X11-unix/X1 exists when display 1.0 is active and yes I was thinking about the symlink idea as well. I'll try the X1 test out.
-
I have added the test for x11 on display 1.0 to the wbar.sh script and it now restarts the display1.0 wbar on updates.
#!/bin/sh
cd "$HOME"
if [ $(awk '/icons:/{print $2}' "$HOME"/.desktop) == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
DISPLAY=:0.0 wbar -bpress -config /usr/local/tce.wbar > /dev/null &
[ -e /tmp/.X11-unix/X1 ] && DISPLAY=:1.0 wbar -bpress -config /usr/local/tce.wbar > /dev/null &
fi
Now I need the same arrangement for flwm so when updates happen they too will be synced up and restarted. I was hoping the refresh button in the menu would be good enough but it's not.