[pygtk] Callbacks

Peyman paskari007 at yahoo.ca
Tue Jul 28 00:37:15 WST 2009


On 27 Jul 2009, at 17:20, Timo wrote:

> Peyman schreef:
>> Hi, a while back I inquired about blocking signals, and we came to  
>> the  conclusion that via glade there is no way to get a hold of the  
>> handler  IDs, so we had to use handler_block_by_func(). At the  
>> time  handler_block_by_func() didn't even work for me under python.  
>> I have  switched over to C, and handler_block_by_func() finally  
>> works.  Unfortunately, handler_unblock_by_func() does not work. I  
>> don't know  if this is because it is corrupted, or b/c I am using  
>> it incorrectly.  Quite frankly, I'm starting to lose my patience  
>> since there is very  little help on the internet wrt blocking  
>> functions.
>>
> I'm using Glade too, and to block a function I use the following.
>
>
> def checkbox_toggled(self, widget):
>   if self.blockCheckboxCallback: return
>
>   print "Checkbox toggled"
>   # More code
>
>
> self.blockCheckboxCallback = True
> # Do your thing here
> self.blockCheckboxCallback = False
Hi Timo

The good ol' brute force approach. I realize that it's possible to do  
it that way, but I don't want to have x amount global variables lying  
around. Mind you, that is how I was doing it in python

My point is that there exists a block/unblock function, and that this  
is, at the very least, somewhat useful. However, it is impossible to  
use with glade, and I'm even having problems with it in libglade. On  
the one hand I don't know how to get the handler ids (w/o manually  
connecting every callback), on the other, block_by_func() doesn't seem  
to work for me either

Cheers


Peyman Askari

>
>
>> I also can't seem to find a way to autoconnect signals AND save  
>> their  handler IDs. This would seem like a very important option.
>>
>> It's getting to the point where I might start using brute force,  
>> and  connecting every signal manually, but I hope someone informs  
>> me of an  easier approach
>>
>> Thank You
>>
>>
>> Peyman Askari
>>
>> On 11 Mar 2009, at 13:31, Walter Leibbrandt wrote:
>>
>>
>>> Hi,
>>>
>>> Maybe I should just let some code do the talking. See attached  
>>> script.
>>>
>>> The button's "clicked" handler adds an "x" to the entry. The  
>>> toggle  button uses handler_(un)block_by_func() on addx_clicked so  
>>> that it  is only enabled if the toggle button is active. Note  
>>> that  handler_(un)block_by_func() was called on btn, seeing as  
>>> that is the  widget to which the handler is connected.
>>>
>>> This is quite an exciting discovery for myself too. Seeing as its  
>>> in  GObject and not in Glade, I can use this with my custom  
>>> widgets too  and need not keep signal dictionaries anymore! :)
>>>
>>> P.S. In this context "handler" means the function/method  
>>> connected  to a signal.
>>>
>>> Peyman wrote:
>>>
>>>> Hi Walter
>>>>
>>>> I am running into problems using it. To use   
>>>> handler_bloc_by_func(callable) you have to pass callable: a   
>>>> callable python object. I have tried using the widget itself,  
>>>> and  it's callback functions, but neither is working. What  
>>>> exactly do i  have to pass as a parameter. You made reference to  
>>>> passing the  "handler" to it.
>>>>
>>>> Cheers
>>>>
>>>>
>>>>
>>>> Peyman Askari
>>>>
>>>> On 11 Mar 2009, at 12:53, Walter Leibbrandt wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems that this has been asked before: http://osdir.com/ml/gnome.gtk+.python/2003-04/msg00089.html
>>>>>
>>>>> Short answer: no, it doesn't seem like you can. I have,  
>>>>> however,  found the handler_block_by_func() and  
>>>>> handler_unblock_by_func()  methods of gobject.GObject. Although  
>>>>> I haven't tested this yet, it  seems from the docs (http://library.gnome.org/devel/pygobject/stable/class-gobject.html#method-gobject--handler-block-by-func 
>>>>>  ) that you can simply pass your handler to it to (un)block it  
>>>>> from  being called.
>>>>>
>>>>> Let me know how/if it works.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Peyman wrote:
>>>>>
>>>>>> I realize that once you call connect() it returns the  
>>>>>> handle_id.  But if glade is doing this for me, are the handle  
>>>>>> id's stored  somewhere? Surely there has to be a   
>>>>>> widget.get_handle_id('callback_function') method. I can't seem  
>>>>>> to  find anything on this over the net though.
>>>>>>
>>>>> -- 
>>>>> Walter Leibbrandt                  http://translate.org.za/blogs/walter
>>>>> Software Developer                                  +27 12 460   
>>>>> 1095 (w)
>>>>> Translate.org.za
>>>>>
>>>>> Recent blogs:
>>>>> * Firefox-style button with a pop-up menu
>>>>> http://www.translate.org.za/blogs/walter/en/content/firefox-style-button-pop-menu
>>>>> * Virtaal's MVCisation
>>>>> * Things that changed the way I code
>>>>>
>>>>>
>>>>>
>>> -- 
>>> Walter Leibbrandt                  http://translate.org.za/blogs/  
>>> walter
>>> Software Developer                                  +27 12 460  
>>> 1095  (w)
>>> Translate.org.za
>>>
>>> Recent blogs:
>>> * Firefox-style button with a pop-up menu
>>> http://www.translate.org.za/blogs/walter/en/content/firefox-style-button-pop-menu
>>> * Virtaal's MVCisation
>>> * Things that changed the way I code
>>>
>>>
>>> #!/usr/bin/env python
>>>
>>> import gtk
>>> import gtk.glade
>>>
>>> xml = gtk.glade.XML('gui.glade')
>>> win = xml.get_widget('window')
>>> btn = xml.get_widget('button')
>>> entry = xml.get_widget('entry')
>>>
>>> def addx_clicked(*args):
>>>   entry.props.text += 'x'
>>>
>>> def enable_toggled(togglebtn):
>>>   if togglebtn.get_active():
>>>       btn.handler_unblock_by_func(addx_clicked)
>>>   else:
>>>       btn.handler_block_by_func(addx_clicked)
>>>
>>> win.connect('destroy', lambda *args: gtk.main_quit())
>>> btn.connect('clicked', addx_clicked)
>>> xml.get_widget('togglebutton').connect('toggled', enable_toggled)
>>>
>>> win.show_all()
>>> gtk.main()
>>> <gui.glade>
>>>
>>
>> _______________________________________________
>> pygtk mailing list   pygtk at daa.com.au
>> http://www.daa.com.au/mailman/listinfo/pygtk
>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>
>



More information about the pygtk mailing list