Re: [Gtk-osx-users] weird menu problem
Status: Beta
Brought to you by:
jralls
From: John R. <jr...@ce...> - 2011-02-10 21:37:10
|
On Feb 10, 2011, at 12:23 PM, Olivier Sessink wrote: > 2011/2/10 John Ralls <jr...@ce...>: >> >> On Feb 10, 2011, at 10:04 AM, Olivier Sessink wrote: >> >>> 2011/2/10 John Ralls <jr...@ce...>: >>>> You're passing objects to Gtk which aren't GObjects, obviously. If GtkItemFactory somehow produces Gtk widgets which aren't GObjects, yes, that could be it. >>> >>> I doubt that, because you can alter menu's created by GtkItemFactory >>> just if they were created as GtkMenu / GtkMenuItem >>> >>> I'm quite sure that the warnings are shown during _sync() calls. Every >>> sync produces the same number of warnings. >>> >>>> If you're going to have to redo your UI, you should probably look into doing so with pygobject and the gobject-introspection interface instead of PyGtk... though I haven't yet done so for GtkOSXApplication. >>> >>> Bluefish is written in C, so that's not really a problem. However, the >>> menu is quite large so there is lots of code and lots of translations >>> involved. We're planning to move to the uimanager API in the next >>> major release. >> >> >> Sorry, for some reason I thought that Bluefish was a Python app. >> >> Anyway, the best way to track it down is to set a breakpoint on the G_IS_OBJECT macro and see what's getting passed where that trips is. >> > > you can't break on a macro, can you? I tried a breakpoint on > g_object_get, but there are thousands of calls like that. Do you have > any idea where in the GtkOSXApplication library this could be called? No, you can't break on a macro by name, but you can break on the code inside it. That said, I was thinking that the assert was inside the G_IS_OBJECT macro, and it isn't. It's a g_return_val_if_fail in g_object_get() (gobject/gobject.c line 1847 in the gobject-2-26 branch). But setting a breakpoint on that will hit a bazillion times, so change it to g_assert(G_IS_OBJECT(object)); rebuild (don't for get to build glib with debugging!), run in the debugger, and your program will stop at the first hit. Regards, John Ralls |