Many components of gtk failing on linux (debian-etch)

gtk.link_button_set_uri_hook is referenced in revisionview.py
gtk.Action.set_tool_item_type is referenced in viz/branchwin.py

These are PyGtk 2.10 innovations. debian-etch supplies PyGtk 2.8.6-8

Both uses appear to be 'cosmetic' - they do not seem to set up or manipulate objects that the code later relies upon.

As a workaround - to prove that the remainder of the code runs successfully - simply commenting out these references seems to be effective. But I don't have enough knowledge of python, gtk or the bzr-gtk codebase to know whether there are unacceptable consequences to this.

'Proof of concept' branch proposed for merge to encourage discussion.

On Wed, 2009-12-09 at 10:56 +0000, David Roberts wrote:
> gtk.link_button_set_uri_hook is referenced in revisionview.py
> gtk.Action.set_tool_item_type is referenced in viz/branchwin.py
>
> These are PyGtk 2.10 innovations. debian-etch supplies PyGtk 2.8.6-8
>
> Both uses appear to be 'cosmetic' - they do not seem to set up or
> manipulate objects that the code later relies upon.
>
> As a workaround - to prove that the remainder of the code runs
> successfully - simply commenting out these references seems to be
> effective. But I don't have enough knowledge of python, gtk or the bzr-
> gtk codebase to know whether there are unacceptable consequences to
> this.
>
> 'Proof of concept' branch proposed for merge to encourage discussion.
To not degrade the functionality on platforms that do have newer
versions of pytgtk, we should check if those functions are present
before we call them.

David, where is your attached branch? Could you perhaps update it to
include these checks?

  status triaged
  importance low

I'm out of my depth here, in several different areas.

1. I thought I had pushed a later revison to the location linked as a merge propose branch from the LP bzr-gtk page. But LP returns an error message rather than serving the branch. Should I delete it from LP and try again?

2. re: performance on platforms with better versions of pygtk. Putting in a check to see if a function is present is clearly going to be a performance hit compared with not doing the check. At run-time I don't see a way round that - either we check even though for most people it's a time-waster, or for some people there is a run-time error. Maybe the work-around is to make it a build-time option?

3. However... noone has marked this bug 'Affects me too' or logged a duplicate. Maybe the cost of a fix outweighs the benefits? So I'm content to simply run this as a local fork for my own benefit and leave the released version alone. There can't be very many bzr users wanting to struggle with an under-supported OS on a netbook with a 7" screen!