Kip,
Am 04.03.2013 um 02:18 schrieb Kip Shaffer:
So when a user selects File-Quit, a SIGTERM should be generated?
You mean in Axis? In a gladevcp application?
please share a bit more more detail about your setup - depending on the answer,
different things happen, which is probably part of
On Mon, Mar 4, 2013 at 4:20 AM, Michael Haberler mai...@mah.priv.at wrote:
So when a user selects File-Quit, a SIGTERM should be generated?
You mean in Axis? In a gladevcp application?
please share a bit more more detail about your setup - depending on the
answer, different things happen,
On 3 March 2013 07:39, Michael Haberler mai...@mah.priv.at wrote:
I have looked into the issue in the past, more with an eye towards fast
estop, and the gist was: if it is too work fast, the shutdown sequence must
be aware of the hardware it is using; for instance, the fastest,
Am 03.03.2013 um 13:45 schrieb andy pugh:
On 3 March 2013 07:39, Michael Haberler mai...@mah.priv.at wrote:
I have looked into the issue in the past, more with an eye towards fast
estop, and the gist was: if it is too work fast, the shutdown sequence must
be aware of the hardware it is
So when a user selects File-Quit, a SIGTERM should be generated? It
doesn't trigger the on_unix_signal(), whereas hitting Control-C does.
I think for now, I am going to regard auto-saving widget states as
unreliable. Instead, I will keep anything that ought to be saved in
vars, which don't
Anybody using GladeVCP with Persistence? Did you have trouble getting
it to save settings?
It seems to me as though it is very sensitive to what widget the
'on_destroy' signal is attached.
The documentation does warn against attaching it to the 'window1'
object. But I had terrible luck getting
Am 03.03.2013 um 03:46 schrieb Kip Shaffer:
Anybody using GladeVCP with Persistence? Did you have trouble getting
it to save settings?
It seems to me as though it is very sensitive to what widget the
'on_destroy' signal is attached.
The documentation does warn against attaching it to
following up to myself:
The issue goes down a bit deeper, and it's about the notion of controlled
shutdown
This is a dark corner of LinuxCNC, especially with respect to time-to-estop for
connected hardware, and it warrants some thought and work. Unfortunately I dont
have a quick answer for
