hi psha, back on net?
for a day :)
and here with full repo i've finally fetched your repo :0
btw it's useless to save HAL_OUT pins...
their value is updated from widget state
so you really need to save/restore widget state
psha: already figured that, working on it
i think it's better to make small branching on gtk base classes
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
so you'd be able to do more general save/restore then simple hal pins
saveing OUT pin states is useless...
so i don't see any need in HAL_PINS list...
either save/restore function of HalBaseWidget
or branching on hal type
yea, got that
widget type i meen
well how do save the state? a save/restore method would help
as for restoring widget state - do you see the need for more than one value? I currently dont
what 'active' widgets we have? scales, buttons, and what?
re button - it is conceivable to save in the button pressed state, unsure wether that makes sense
it will be unpressed immidiately
for toggle - yes
with togglebutton its valid though
so we need get/set_value for scale, spin and combo(?), and set_active for toggle/check/radio
why i think that branching is better for save/restore - you'll get saving/restoring other, non-hal, widgets at no additional cost
I see, that's useful, yes!
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
would be nice
i think that save/restore may be merged to gladevcp submodule and then i'll hook it into camview-emc :)
do you have the time today to do a save/restore subclass example I can start from? I'm your average OO idiot
it may be done in one of two ways -- check for get/set_active function or for base class
if hasattr(w, 'get_value'): x = w.get_value(); save(w.name, x); elif hasattr(w, 'get_active"): ....
if isinstance(w, (gtk.Range, gtk.SpinButton)): x = w.get_value(); ....
thats for doing it outside gtk.*/HalWidgetsBase, right? like in my code?
I see, my ticket ;-)
since it won't be possible to add it to gtk.ToggleButton :)
only with monkeypatching...
but i think gtk.ToggleButton will reject it
ok, fair enough, I'll give it a stab
psha: ok to pull - persistence seems to work ok - need to cleanup comments still.
man, you are the fastest pull in the west ;-)
mhaberler: you've added only hal_restore
hal_save is not needed?
none of it, I think you can revert hal_widgets to clean psha state
I lost interest in hal_save ;-)
no save/restore? :)
does it work with old hal_widgets? didnt try
i'll check in a minute
I just reverted to your state and it seems OK
unsure about structure - would you want to pull the inifile stugg into gladevcp?
kill that, kill that!!11
you'd either export PYTONPATH... or just use run-in-place
I know, its a misfeature of eclipse pydev plugin which forces me to do this
so save/restore is in inifile.py?
in gladevcp only userfuncs are needed?
yes, no special aids for that
note I added -U <string> to be passed via get_handlers - see example exec at bottom of gladevcp_work.py
btw usage function is not used now at all
yes, has to go
so i'll polish userfuncs once more and push it to gladevcp branch
I need a directory for gladevcp examples - propose share/gladevcp - ok?
inifile.py -> lib/python/gladevcp ?
i think that most part of gladevcp.py have to go to module too
different one I guess
btw there is better way to check if function is callable
I am all ears
it was dropped in py3k but will return in 3.2
may you remind correct test command for userfuncs?
sure, go ahead, fix and restructure as you like
but i've lost in ton's of your files in configs/sim-mah :) what's correct command line to load all needed stuff?
gladevcp -u gladevcp_work.py -U debug=1 -H gladevcp_work.hal gladevcp_work.ui
I've pushed some touchups, infile now in lib/python/gladevcp ; hope you can merge ;-)
mhaberler: i think i have to revert gladevcp main function split
whatever lights your candle ;-)
it's too intrusive...
what's the problem?
do we need hal_init() again?
just some code reorganization
so in stock gladevcp only getopt/optparse changes will be visible
and not intrusive
psha: will work on examples and doc - any changes you're doing which will affect me?
i'll just cleanup gladevcp.py
btw you'd dropped userfuncs without get_handlers?
i think it's important usecase
just place 1(one) function in a file and be happy if you need only one callback
i'll continue tomorrw :)
what do you mean by 'userfuncs without get_handlers'?
oh, I see - the trivial case! will look into it