What you are describing is the operation of File Alteration Monitor .
First, your existing incrontab solution is a good starting point, given that you are running things from the shell. The fact that incrontab is inotify (7) is a huge plus. This means that you are not polling, which saves the processor.
You are asking for shell and system level solutions, and I am not a Flash programmer, so I will stick to your question, although I think the best solution would be to create a Flash wrapper, which probably uses the AS3 Loader class to suck in an existing SWF and get notifications from something launched by incrontab. Flash programming is beyond the scope of this answer, although it may provide a more elegant solution.
So...
Your current method consists of running a script that first kills any existing gtk-gnash process and then starts a new one. It restarts from scratch when incrontab sees a file change. This is a viable solution if you trust that your flash application will never fail or go away, and if you always have the perfect timing. One problem is that you have an unknown delay between the death of one process and the start of the next. Your killall sends a signal that gtk-gnash can respond immediately or after a pause. With a short pause, you can start SWF before the old one completely disappears. With a longer pause, you can briefly show your desktop.
A better solution might just be to start SWF in a loop:
#!/bin/sh while true; do date '+[%Y-%m-%d %T] myfile.swf relaunched' >> /var/log/swf.log gtk-gnash /home/my_username/path/myfile.swf done
Then incrontab just kills the existing process:
/home/my_username/path/myfile.swf IN_MODIFY killall gtk-gnash
By separating killall from startup, you will see that the new gtk-gnash instance does not start until the old user stops working and returns control to the shell script, assuring it.
Of course, instead of using incrontab, you can also install the inotify-tools package and leave the loop running:
#!/bin/sh while inotifywait -e modify /home/my_username/path/myfile.swf; do killall gtk-gnash done
The same system calls, the same effect, different interfaces.
If you want to be careful about which process you are killing, you can also save pid gtk-gnash in a temporary file. Here is another example of the cover of a flash player:
#!/bin/sh while true; do date '+[%Y-%m-%d %T] myfile.swf relaunched' >> /var/log/swf.log gtk-gnash /home/my_username/path/myfile.swf & echo $! > /var/run/gtk-gnash.pid wait done
And the incrontab line:
/home/my_username/path/myfile.swf IN_MODIFY xargs kill < /var/run/gtk-gnash.pid
Another strategy you can use to reduce the visible kill / restart effect is to take a screenshot of myfile.swf when it works with minimal or missing content, and then use it as a desktop wallpaper on the player. (Or the equivalent, I don’t know how you are configured.) I did something similar for the digital signage solution that I created several years ago - from time to time we needed to kill and restart the standalone player, so we only made a "frame "the first page that appears. When we killed the flashplayer process, the system seemed to reset without content in its blocks ... and then, after a second, the content would appear. (Yes, it's a hack.)
One more tip: I have always considered the stand-alone Adobe Flash Player ("Projector") to be more reliable and compatible with gtk-gnash. You can find the standalone Adobe player on the Adobe Support Center download page , which is different from the standard Flash Player download page.