can't reopen hamster applet after closing it: 'NoneType' object has no attribute 'show' in main

Bug #918487 reported by Martin Pool
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Project Hamster
Fix Released
Medium
hamster-applet (Ubuntu)
Fix Released
Low
Jamie Strandboge
Precise
Fix Released
Low
Jamie Strandboge

Bug Description

This seems like a new regression in Precise:

I can start Hamster from the Launcher, and use it normally. If I close the main window eg by pressing Escape, it closes, and the icon is inactive (loses the little arrow) in my Launcher. If I click it again, it does not start, I get an apport window, and I see this traceback in .xsession-errors:

Traceback (most recent call last):
  File "/usr/bin/hamster-time-tracker", line 612, in <module>
    getattr(server, window)()
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 143, in __call__
    **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 702, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/bin/hamster-time-tracker", line 562, in main
    self.app.window.show()
AttributeError: 'NoneType' object has no attribute 'show'

I can see there are still hamster processes running:

 6815 ? Sl 0:04 python /usr/bin/hamster-time-tracker
 6821 ? S 0:00 /usr/bin/python /usr/bin/hamster-service

I think this bug is something to do with connecting to them, or restarting them.

If I kill them manually then I can start Hamster again.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

I thing what may be going on is when the window is being destroyed:
    def close_window(self, *args):
        self.save_window_position()
        self.window.destroy()
        self.window = None
        self.show_in_tray()

    def on_delete_window(self, event, data):
        self.save_window_position()
        self.window.destroy()
        self.window = None
        self.show_in_tray()

The app object is not destroyed. So then on re-entrancy:
    @dbus.service.method("org.gnome.Hamster.WindowServer")
    def main(self):
        if self.app:
            self.app.window.show()
            self.app.window.present()
        else:
            self.app = ProjectHamster()

since there is an application object, it assumes there is a window object. I suspect the right fix is to test if the self.app.window is not None, and recreate the window if necessary. It may also be simply to hide self.window instead of destroy it.

Changed in hamster-applet (Ubuntu):
importance: Undecided → Low
Changed in hamster-applet (Ubuntu):
status: New → Confirmed
Changed in hamster-applet (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Jamie Strandboge (jdstrand)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thanks Rick. I agree with your assessment and have filed an upstream bug with the patch I am uploading to Precise now.

Changed in hamster-applet (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hamster-applet - 2.91.3+git20110714.9aefd7-2ubuntu2

---------------
hamster-applet (2.91.3+git20110714.9aefd7-2ubuntu2) precise; urgency=low

  * debian/patches/03-check-self-app-window.patch: verify that self.app.window
    is not None (LP: #918487)
 -- Jamie Strandboge <email address hidden> Thu, 26 Jan 2012 08:53:18 -0600

Changed in hamster-applet (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in hamster-applet:
importance: Unknown → Medium
status: Unknown → New
Changed in hamster-applet:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.