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, which is probably part of your problem:
>
> - if Axis is exited, the linuxcnc script notices and starts sending a
> SIGTERM and eventuall SIGKILL to all running process, so yes, gladevcp
> should receive a SIGTERM and that can be handled
>
Apologies, I should should have described my setup a bit more. I _am_
talking about a GladeVCP panel embedded in Axis, and from the previous
discussion, I was hoping SIGTERM would have triggered my on_unix_signal()
in the same way that pressing Control-C does. It may be that there are
other issues that prevent it from responding appropriately.
It would help if we could isolate the issue a bit more, namely a) are those
> signals generated b) how are they reacted to
>
> habe a look at the gladevcp source code to see how the signal handlers are
> installed, you can do that 'custom' easily:
>
> if handlers.has_key(signal_func):
> dbg("Register callback '%s' for SIGINT and SIGTERM" %(signal_func))
> signal.signal(signal.SIGTERM, handlers[signal_func])
> signal.signal(signal.SIGINT, handlers[signal_func])
>
> I will trace through the source and look for this section. I'll follow
the execution to see where it's failing.
> > 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 disappear on me.
>
> hey, lets apply a bit more rigor here. This _must_ work reliably
> eventually, period.
>
> Please help with it.
>
I will happily help with it. Part of the miracle that is open-source
software is the result of the collaborations that occur. This philosophy
resonates deeply with me.
I was simply responding to your earlier comments that coming up with a
robust solution must be done carefully and deliberately. I wanted you to
know that in my particular situation, namely saving 1 or 2 variables, is
not being delayed by any of the issues we have discussed, so my problem is
solved.
I am not a software engineer, barely know any Python, and first looked at
Glade about 15 days ago. But I might question the strategy of storing
information in volatile objects like widgets. In the Model-View-Controller
architecture, there is a distinct separation between Data (Model) and
View/Controller. The GladeVCP.persistence vars have this separation,
whereas the data stored in the widgets do not. Since there are many ways
for widgets to be destroyed, IMHO the likelihood that we can intercept
their destruction 100% of the time seems low. Thus storing any persistent
information in a less volatile location is attractive.
Maybe we could expose functionality to the users to update the data model
directly:
def on_change:
self.ini.setvalue(objectname, objectvalue)
-Kip
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
