Re: Actions for custom widgets in PyGTK



Sascha Silbe <silbe activitycentral com> writes:

> Is there a way of using AtkObject subclasses with GTK subclasses other
> than duplicating the entire set of custom widgets (and probably quite a
> few stock ones as well) and registering an AtkObject factory for each of
> them?

The minor detail I missed was that I need to override
do_get_accessible() rather than get_accessible(). Thanks to Mike Gorse
(on #a11y) for digging out a couple of references for me.

It also seems do_get_accessible() needs to have been overridden at class
definition time, rather than being able to override it on an individual,
already initialised instance. That means adding code to each widget
class (including creating subclasses for stock GTK widgets that we're
using). Not sure yet if that's feasible; at the very least it's a major
PITA.

There's still some race condition affecting my code. One symptom is a
segfault, the other is do_get_n_actions() getting invoked on the widget,
rather than the AtkObject subclass. Both are happening at the same
location in the Python code.

Python backtrace for do_get_n_actions() invoked on the wrong class:

[...]
  File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/desktop/favoritesview.py", line 636, in __init__
    BuddyIcon.__init__(self, buddy=get_owner_instance(), pixel_size=size)
  File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/view/buddyicon.py", line 38, in __init__
    self._update_color()
  File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/view/buddyicon.py", line 53, in _update_color
    self.props.xo_color = self._buddy.get_color()
  File "<string>", line 2, in do_get_n_actions
  File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/sugar/logger.py", line 208, in _trace
    res = f(*args, **kwargs)
  File "/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/view/eventicon.py", line 293, in do_get_n_actions
    traceback.print_stack()


gdb backtrace for the segfault (sorry about the missing debug symbols,
will have to rebuild the glib Debian package first):

#1  0x00007ffff4db4724 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x00007ffff4dc57b0 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x00007ffff4dcd72c in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x00007ffff4dcd8c2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x00007ffff4db90e5 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x00007ffff4db8b2e in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x00007ffff4dbc759 in g_object_set_property () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x00007ffff3e38e03 in set_property_from_pspec (obj=0xd572f0, attr_name=0x10df054 "xo_color", pspec=<optimized out>, pvalue=<optimized out>)
    at /home/martin/debian/pkg-gnome/build-area/pygobject-2-2.28.6/gobject/pygobject.c:357
Python Exception <class 'gdb.error'> There is no member named in_class.: 
#9  0x00007ffff3e39690 in PyGProps_setattro (self=0x1a76550, attr='xo_color', pvalue=) at /home/martin/debian/pkg-gnome/build-area/pygobject-2-2.28.6/gobject/pygobject.c:406
[...]

Just to make sure, there's only a single thread:

  Id   Target Id         Frame 
* 1    Thread 0x7ffff7fda700 (LWP 18084) "python" 0x00007fffedeb820c in ?? () from /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libgail.so

Does this ring a bell for anyone? Do I need to do anything special for
memory management? Maybe for the ref_*() methods I had to override to
wrap the "original" AtkObject instance?

Sascha

[1] https://bugzilla.gnome.org/show_bug.cgi?id=647482
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/

Attachment: pgpGCqu7Sua5u.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]