Re: [Gtk-osx-users] weird menu problem

[John Ralls <jralls ceridwen us>]

On Feb 10, 2011, at 12:23 PM, Olivier Sessink wrote:

> 2011/2/10 John Ralls <jralls ceridwen us>:
>> 
>> On Feb 10, 2011, at 10:04 AM, Olivier Sessink wrote:
>> 
>>> 2011/2/10 John Ralls <jralls ceridwen us>:
>>>> 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