hamster-standalone crashed with Error in __init__()

Reported by Hugh Saunders on 2010-03-10
This bug affects 4 people
Affects Status Importance Assigned to Milestone
hamster-applet (Ubuntu)

Bug Description

Binary package hint: hamster-applet

Attempting to add the hamster applet to the panel didn't work (may have caused a single pixel wide vertical line on the panel), so I started hamster-standalone from terminal which produced the following output:

hugh@anni:~$ hamster-standalone

** (hamster-standalone:3488): WARNING **: Trying to register gtype 'WnckWindowState' as enum when in fact it is of type 'GFlags'

** (hamster-standalone:3488): WARNING **: Trying to register gtype 'WnckWindowActions' as enum when in fact it is of type 'GFlags'

** (hamster-standalone:3488): WARNING **: Trying to register gtype 'WnckWindowMoveResizeMask' as enum when in fact it is of type 'GFlags'
/usr/lib/pymodules/python2.6/hamster/widgets/facttree.py:95: GtkWarning: Using Cairo rendering requires the drawable argument to
have a specified colormap. All windows have a colormap,
however, pixmaps only have colormap by default if they
were created with a non-NULL window argument. Otherwise
a colormap must be set on them with gdk_drawable_set_colormap
  _test_context = pixmap.cairo_create()
Traceback (most recent call last):
  File "/usr/bin/hamster-standalone", line 500, in <module>
    app = ProjectHamster()
  File "/usr/bin/hamster-standalone", line 76, in __init__
    self.treeview = widgets.FactTree()
  File "/usr/lib/pymodules/python2.6/hamster/widgets/facttree.py", line 95, in __init__
    _test_context = pixmap.cairo_create()
cairo.Error: NULL pointer

ProblemType: Crash
Architecture: i386
Date: Wed Mar 10 22:13:19 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/hamster-standalone
InterpreterPath: /usr/bin/python2.6
Package: hamster-applet 2.29.90-0ubuntu1
ProcCmdline: python /usr/bin/hamster-standalone
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
PythonArgs: ['/usr/bin/hamster-standalone']
SourcePackage: hamster-applet
Title: hamster-standalone crashed with Error in __init__()
Uname: Linux 2.6.32-16-generic i686
UserGroups: adm admin cdrom dialout disk lpadmin plugdev sambashare sudo

Hugh Saunders (hughsaunders) wrote :
visibility: private → public
tags: removed: need-duplicate-check
Endre Czirbesz (endre) on 2010-08-29
tags: added: amd64
donquixote (lemon-head-bw) wrote :

So. Here we have a very naive patch, which seems to work, but probably just hides the problem.

/usr/lib/python2.6/dist-packages/hamster/widgets/facttree.py, lines 98 ff (on my version)
class FactTree(gtk.TreeView): def __init__(self):

        pixmap = gtk.gdk.Pixmap(None, 10, 10, 24)
        _test_context = pixmap.cairo_create()
        self._test_layout = _test_context.create_layout()

        pixmap = gtk.gdk.Pixmap(None, 10, 10, 24)
        """ patch """
        try :
          _test_context = pixmap.cairo_create()
        except :
        self._test_layout = _test_context.create_layout()

donquixote (lemon-head-bw) wrote :

ok, so i would not have needed that <code> and </code>. We've learned something today!

donquixote (lemon-head-bw) wrote :

The above is definitely not the solution.
After some time i can't stop the hamster anymore. And this is the new error I get with "hamster-standalone":
(after a few warnings, which I don't even report)

  File "/usr/lib/python2.6/dist-packages/hamster/widgets/facttree.py", line 125, in update_longest_dimensions
AttributeError: 'FactTree' object has no attribute '_test_layout'

donquixote (lemon-head-bw) wrote :

Maybe I should add that I'm on TwinView with nvidia, and hamster used to work before I fixed my second monitor.
So, could be that hamster is trying to do something on each of the monitors, but on one of them there is something missing.

donquixote (lemon-head-bw) wrote :

Hey, we can get even better!!

class FactTree(gtk.TreeView):
    def __init__(self):
        try :
          _test_context = pixmap.cairo_create()
          self._test_layout = _test_context.create_layout()
          font = pango.FontDescription(gtk.Style().font_desc.to_string())
        except :


    def update_longest_dimensions(self, fact):
        interval = "%s -" % fact["start_time"].strftime("%H:%M")
        if fact["end_time"]:
            interval = "%s %s" % (interval, fact["end_time"].strftime("%H:%M"))

        try :
          w, h = self._test_layout.get_pixel_size()
          self.longest_interval = max(self.longest_interval, w + 20)

          self._test_layout.set_markup("%s - <small>%s</small> " % (stuff.escape_pango(fact["name"]), stuff.escape_pango(fact["category"])))
          w, h = self._test_layout.get_pixel_size()
          self.longest_activity_category = max(self.longest_activity_category, w + 10)

          self._test_layout.set_markup("%s" % stuff.format_duration(fact["delta"]))
          w, h = self._test_layout.get_pixel_size()
          self.longest_duration = max(self.longest_duration, w)

        except :
          w = 0
          h = 0
          self.longest_interval = max(self.longest_interval, w + 120)
          self.longest_activity_category = max(self.longest_activity_category, w + 70)
          self.longest_duration = max(self.longest_duration, w)

donquixote (lemon-head-bw) wrote :

If I understand correctly, hamster does a "_test_layout" to find ideal values for pixel widths for some display elements.
The above code provides fallback values in case that the _test_layout stuff doesn't work.

You can play around with the fallback values, and restart hamster-standalone after each change. You will see the difference (except for the place where I put 70, I have no idea what that does).

I think the concept of fallback values is a reasonable thing, and should be kept even if the real problem can finally be fixed. Who knows what else will break the _test_layout stuff in the future.

donquixote (lemon-head-bw) wrote :

Here is my modified facttree.py.
Probably this needs work, but it does solve the problem in my case.
Maybe a more targeted if/else instead of the try/except?

donquixote (lemon-head-bw) wrote :

Could someone with more python skill look into this?
The solution I suggested is only a workaround, but I think something in this direction should go into the next stable, until a real solution is found.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers