Back
[15:10:09] <mhaberler> hi psha, back on net?
[15:11:01] <psha> yea
[15:11:03] <psha> for a day :)
[15:11:21] <psha> and here with full repo i've finally fetched your repo :0
[15:11:22] <psha> :)
[15:14:05] <psha> btw it's useless to save HAL_OUT pins...
[15:14:38] <psha> their value is updated from widget state
[15:14:49] <psha> so you really need to save/restore widget state
[15:17:42] <mhaberler> psha: already figured that, working on it
[15:18:24] <psha> i think it's better to make small branching on gtk base classes
[15:18:37] <mhaberler> do you think saving all pins in HAL_PINS class attr makes sense? I was looking for the set of pins needed for restore only
[15:18:40] <psha> so you'd be able to do more general save/restore then simple hal pins
[15:19:25] <psha> saveing OUT pin states is useless...
[15:19:27] <psha> saving
[15:19:42] <psha> so i don't see any need in HAL_PINS list...
[15:20:07] <psha> either save/restore function of HalBaseWidget
[15:20:13] <psha> or branching on hal type
[15:20:18] <mhaberler> yea, got that
[15:20:19] <psha> widget type i meen
[15:20:20] <mhaberler> well how do save the state? a save/restore method would help
[15:20:26] <mhaberler> same thing,yes
[15:21:31] <mhaberler> as for restoring widget state - do you see the need for more than one value? I currently dont
[15:21:33] <psha> what 'active' widgets we have? scales, buttons, and what?
[15:21:46] <mhaberler> spin, combo
[15:22:32] <mhaberler> re button - it is conceivable to save in the button pressed state, unsure wether that makes sense
[15:23:12] <psha> no sense
[15:23:26] <psha> it will be unpressed immidiately
[15:23:32] <psha> for toggle - yes
[15:23:33] <mhaberler> with togglebutton its valid though
[15:23:39] <mhaberler> ok
[15:25:42] <psha> so we need get/set_value for scale, spin and combo(?), and set_active for toggle/check/radio
[15:25:56] <mhaberler> yes
[15:27:24] <psha> why i think that branching is better for save/restore - you'll get saving/restoring other, non-hal, widgets at no additional cost
[15:27:48] <mhaberler> I see, that's useful, yes!
[15:28:44] <mhaberler> the whole typed saving/load ini stuff works, it's really just that part which is missing, guess then we're done with this iteration of feature add
[15:30:35] <psha> would be nice
[15:31:02] <psha> i think that save/restore may be merged to gladevcp submodule and then i'll hook it into camview-emc :)
[15:31:17] <mhaberler> man..
[15:32:02] <mhaberler> do you have the time today to do a save/restore subclass example I can start from? I'm your average OO idiot
[15:32:36] <psha> it may be done in one of two ways -- check for get/set_active function or for base class
[15:33:13] <psha> if hasattr(w, 'get_value'): x = w.get_value(); save(w.name, x); elif hasattr(w, 'get_active"): ....
[15:33:47] <psha> if isinstance(w, (gtk.Range, gtk.SpinButton)): x = w.get_value(); ....
[15:35:15] <mhaberler> thats for doing it outside gtk.*/HalWidgetsBase, right? like in my code?
[15:35:40] <psha> yes
[15:36:02] <mhaberler> I see, my ticket ;-)
[15:36:04] <psha> since it won't be possible to add it to gtk.ToggleButton :)
[15:36:14] <psha> only with monkeypatching...
[15:36:46] <psha> but i think gtk.ToggleButton will reject it
[15:36:50] <mhaberler> ok, fair enough, I'll give it a stab
[18:10:59] <mhaberler> psha: ok to pull - persistence seems to work ok - need to cleanup comments still.
[18:11:29] <psha> updating
[18:12:01] <mhaberler> man, you are the fastest pull in the west ;-)
[18:12:33] <psha> mhaberler: you've added only hal_restore
[18:12:38] <psha> hal_save is not needed?
[18:13:02] <mhaberler> none of it, I think you can revert hal_widgets to clean psha state
[18:13:25] <psha> ok
[18:14:09] <mhaberler> I lost interest in hal_save ;-)
[18:18:23] <psha> no save/restore? :)
[18:18:26] <psha> only userhooks?
[18:19:39] <mhaberler> does it work with old hal_widgets? didnt try
[18:22:38] <psha> i'll check in a minute
[18:23:08] <mhaberler> I just reverted to your state and it seems OK
[18:31:08] <psha> nice
[18:31:22] <mhaberler> ;-)
[18:32:11] <mhaberler> unsure about structure - would you want to pull the inifile stugg into gladevcp?
[18:32:22] <mhaberler> s/gg/ff
[18:32:51] <psha> +print "KLUDGE!!"
[18:32:51] <psha> +sys.path.insert(0,"/home/mah/emc2-dev/lib/python")
[18:32:51] <psha> +print "KLUDGE!!"
[18:32:51] <psha> +sys.path.insert(0,"/home/mah/emc2-dev/lib/python")
[18:32:53] <psha> aaaa
[18:33:00] <mhaberler> ahem
[18:33:01] <psha> kill that, kill that!!11
[18:33:02] <psha> :)
[18:33:28] <psha> you'd either export PYTONPATH... or just use run-in-place
[18:34:01] <mhaberler> I know, its a misfeature of eclipse pydev plugin which forces me to do this
[18:36:22] <psha> so save/restore is in inifile.py?
[18:36:34] <mhaberler> yes
[18:36:55] <psha> in gladevcp only userfuncs are needed?
[18:37:13] <mhaberler> yes, no special aids for that
[18:37:48] <mhaberler> note I added -U <string> to be passed via get_handlers - see example exec at bottom of gladevcp_work.py
[18:38:28] <psha> btw usage function is not used now at all
[18:38:40] <mhaberler> yes, has to go
[18:39:05] <psha> so i'll polish userfuncs once more and push it to gladevcp branch
[18:39:16] <mhaberler> fair enough
[18:40:34] <mhaberler> I need a directory for gladevcp examples - propose share/gladevcp - ok?
[18:41:32] <mhaberler> inifile.py -> lib/python/gladevcp ?
[18:41:37] <psha> yes
[18:42:03] <psha> i think that most part of gladevcp.py have to go to module too
[18:43:06] <mhaberler> different one I guess
[18:43:17] <psha> sure :)
[18:49:21] <psha> btw there is better way to check if function is callable
[18:49:32] <mhaberler> I am all ears
[18:49:56] <psha> callable
[18:49:57] <psha> :)
[18:50:10] <psha> it was dropped in py3k but will return in 3.2
[18:51:00] <psha> may you remind correct test command for userfuncs?
[18:51:26] <mhaberler> sure, go ahead, fix and restructure as you like
[18:56:31] <psha> heh
[18:56:53] <psha> but i've lost in ton's of your files in configs/sim-mah :) what's correct command line to load all needed stuff?
[18:57:24] <mhaberler> gladevcp -u gladevcp_work.py -U debug=1 -H gladevcp_work.hal gladevcp_work.ui
[18:57:49] <psha> ok
[19:16:58] <mhaberler> I've pushed some touchups, infile now in lib/python/gladevcp ; hope you can merge ;-)
[19:29:41] <mhaberler> psha: bbl
[19:30:00] <psha> ok
[19:30:38] <psha> mhaberler: i think i have to revert gladevcp main function split
[19:30:55] <mhaberler> whatever lights your candle ;-)
[19:32:06] <psha> it's too intrusive...
[19:32:23] <mhaberler> what's the problem?
[19:32:46] <mhaberler> do we need hal_init() again?
[19:35:10] <psha> no
[19:35:23] <psha> just some code reorganization
[19:35:49] <psha> so in stock gladevcp only getopt/optparse changes will be visible
[19:36:41] <mhaberler> harmless
[19:37:01] <psha> yes
[19:37:06] <psha> and not intrusive
[21:53:25] <mhaberler> psha: will work on examples and doc - any changes you're doing which will affect me?
[21:56:07] <psha> no
[21:56:17] <psha> i'll just cleanup gladevcp.py
[21:56:30] <psha> btw you'd dropped userfuncs without get_handlers?
[21:56:46] <psha> i think it's important usecase
[21:57:06] <psha> just place 1(one) function in a file and be happy if you need only one callback
[22:11:29] <psha> i'll continue tomorrw :)
[22:11:31] <psha> bb
[22:11:33] <mhaberler> what do you mean by 'userfuncs without get_handlers'?
[22:12:17] <mhaberler> oh, I see - the trivial case! will look into it