GTG

Crash with hamster plugin enabled

Bug #490747 reported by Lionel Dricot
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GTG
Fix Released
High
Unassigned

Bug Description

After opening multiple tasks, I've got :

** (gtg:3190): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed
/home/ploum/gtg.local/GTG/core/plugins/api.py:178: GtkWarning: Can't set a parent on widget which has a parent

  wi.insert(item, i)
**
Gtk:ERROR:/build/buildd/gtk+2.0-2.18.3/gtk/gtkcontainer.c:2717:IA__gtk_container_propagate_expose: assertion failed: (child->parent == GTK_WIDGET (container))
zsh: abort ./gtg

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

/home/ploum/gtg.local/GTG/plugins/hamster/hamster.py:115: GtkWarning: attempt to add a child to an GtkSeparatorToolItem
  self.taskbutton.set_label("Start")
/home/ploum/gtg.local/GTG/plugins/hamster/hamster.py:115: GtkWarning: gtk_button_set_relief: assertion `GTK_IS_BUTTON (button)' failed
  self.taskbutton.set_label("Start")
/home/ploum/gtg.local/GTG/plugins/hamster/hamster.py:116: GtkWarning: attempt to add a child to an GtkSeparatorToolItem
  self.taskbutton.set_icon_name('hamster-applet')
/home/ploum/gtg.local/GTG/plugins/hamster/hamster.py:116: GtkWarning: gtk_button_set_relief: assertion `GTK_IS_BUTTON (button)' failed
  self.taskbutton.set_icon_name('hamster-applet')
/home/ploum/gtg.local/GTG/core/plugins/api.py:178: GtkWarning: attempt to add a child to an GtkSeparatorToolItem
  wi.insert(item, i)
/home/ploum/gtg.local/GTG/core/plugins/api.py:178: GtkWarning: gtk_button_set_relief: assertion `GTK_IS_BUTTON (button)' failed
  wi.insert(item, i)
/home/ploum/gtg.local/GTG/taskbrowser/browser.py:1558: GtkWarning: attempt to add a child to an GtkSeparatorToolItem
  gtk.main()
/home/ploum/gtg.local/GTG/taskbrowser/browser.py:1558: GtkWarning: gtk_button_set_relief: assertion `GTK_IS_BUTTON (button)' failed
  gtk.main()

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed

** (gtg:3436): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed
/home/ploum/gtg.local/GTG/taskeditor/editor.py:564: GtkWarning: attempt to add a child to an GtkSeparatorToolItem
  self.window.destroy()
/home/ploum/gtg.local/GTG/taskeditor/editor.py:564: GtkWarning: gtk_button_set_relief: assertion `GTK_IS_BUTTON (button)' failed
  self.window.destroy()

Changed in gtg:
status: New → Confirmed
Revision history for this message
Kevin Mehall (kevin-mehall) wrote :

This was introduced in r369. It looks like Bertrand added code to store the GTK widgets in the plugin's instance variables so that the button could be removed from editor windows if the plugin is disabled. Before, the plugin would instantiate a new set of widgets for each editor window. Now, when a 2nd window is opened, it tries to add the existing widgets to the new window, and PyGTK isn't very happy when the same widget instance is added to multiple containers. This also affects the other plugins, since they had similar edits.

Somehow, there needs to be a way to store these task editor widgets while avoiding re-using them. Maybe the editor window part of plugins should be separated out into its own class that is instantiated once per editor window. That way, a plugin can maintain window-specific state (including widgets) that is kept separate from the global state. That might also clean up some of the messiness in the plugin API. Right now there are major differences in the PluginAPI object given to the plugin depending on whether the callback comes from the browser vs. an editor window. If the editor window part of the plugin is a separate class, it could be passed an EditorPluginAPI or something at creation, so the plugin wouldn't have to be passed a new PluginAPI at each callback.

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

I did this change. Indeed, EditorPluginAPI seems needed.

By the way, I remember seeing a hamster button in the bottom of the task editor. Was it removed ? I find that it was a really nice idea.

Changed in gtg:
importance: Undecided → High
assignee: nobody → Lionel Dricot (ploum)
milestone: none → 0.2
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Fixed in rev. 394

Instead of refactorizing the whole stuff, I only added dictionnaries for widgets in the PluginAPI. Refactorization will be needed for 0.3.

Changed in gtg:
status: Confirmed → Fix Committed
Changed in gtg:
status: Fix Committed → 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.