Kip came up with the issue below, and before I 'fix' it, let's think through how to do this right.
-- GladeVCP 'persistence' means: HAL widgets can remember their state across runs, and set values of pins on startup to their last value I added this to GladeVCP in a 'wouldnt it be nice if it could do that' moment, and it uses yet another ini-like file format just to be 'simple'. The question I'm asking myself: is a UI actually the right place to save HAL state across runs? One of the consequences of doing it in the UI is: it works _only_ for that UI. So pyVCP is still out there without persistence, and likely others. I would think the better place would actually be HAL per se, in the context of a firmed-up session concept, and with the capability to tag pins as 'persistent' - just as you can to a 'save' now; although AFAICT the current 'save' command doesnt save pin settings. I would think the right place is always the closest distance to where the driving datastructure lives. In the case of interpreter, persistent parameters are saved and restored by the interpreter itself (right), the case of HAL pins it is currently done by a GUI (wrong place under that criterium). Therefore, I think the better solution to make halcmd, and maybe hal_lib/ULAP capabable of saving/restoring pin values if they are tagged as 'persistent' (which boils down to an attribute in the pin structure). Plus, maybe a Python HAL component which can do that, or just simply call 'halcmd save pins filename' and 'halcmd source filename'. x) makes total sense x) BS, this is why ..., do it like so: ... please fill in Michael Anfang der weitergeleiteten E-Mail: > Von: Kip Shaffer <k...@shafferhouse.org> > Betreff: [Emc-users] GladeVCP Persistence On_Destroy sensitivity > Datum: 03. März 2013 03:46:39 MEZ > An: "Enhanced Machine Controller (EMC)" <emc-us...@lists.sourceforge.net> > Antwort an: "Enhanced Machine Controller \(EMC\)" > <emc-us...@lists.sourceforge.net> > > 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 it to save_state when > LinuxCNC was shutting down. > > I was able to figure out what it was trying to do by putting print > statements into > /usr/lib/pymodules/python2.6/gladevcp/persistence.py > > What I found was that the getter() returned by get_value() would fail > when the window was being destroyed. > > I resolved the problem by putting the 'on_destroy' signal on the same > widget that was being read first. There is no way to determine which > widget will be first, other than by putting in print statements. > > Has anyone else seen this behavior? > > -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-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
