gtk-osx-users — User discussions and support for GTK+-2 on OSX

Re: [Gtk-osx-users] accelerator problem with GtkOSXApplication

[Olivier S. <oli...@gm...>]

On 02/14/2011 04:03 PM, John Ralls wrote:
>
> On Feb 14, 2011, at 4:14 AM, Olivier Sessink wrote:
>
>>> Accelerator mapping in GtkOSXApplication is handled the Gtk way, with GtkAccelMaps. This is mentioned in the GtkOSXApplication documentation.
>>>
>>> Option/Alt is handled a bit too generically in gdk-quartz, where it's used for i18n regardless of context and consequently ignored when used as an accelerator. Ideally this handling should only occur in the input method, but I haven't figured out how to do that yet and Kristian Reitveld doesn't think it's important enough to do anything about. If anyone knows enough about the simple input method to write a patch to fix this it would be most welcome. Post it to https://bugzilla.gnome.org/show_bug.cgi?id=617583.
>>>
>>
>> so what are my options if I do not know the details about input
>> methods? I can go back to ige-mac-integration and try to get my menu
>> problem solved, but that seems to be a step backwards.. Are there
>> other options? Converting the shortcuts in the application code
>> somehow?
>
> Like I said, GtkAccelMaps: http://library.gnome.org/devel/gtk/stable/gtk-Accelerator-Maps.html
>
> There's even an example in test-integration.

sorry perhaps I've not understand you correctly. GtkAccelMaps as shown 
in test-integration.c can be used to modify the accelerator for an entry 
in the menu. But from your email I understood that this will not help to 
fix the problem with the <alt> key. Is that correct or not?

Futhermore, why I really would like to get the 'magic' behavior of 
ige-mac-integration: I have about 295 menu entries in Bluefish (that's 
why I really need <alt> to maximise the number of entries that have an 
accelerator). In the old ige-mac-integration code all entries were 
automatically converted from <control> to <command>. With the new 
GtkOSXApplication code it seems I need something like 600 lines of extra 
code to replace all accelerators, and I should try to keep these in 
sync. Or is this again a misunderstanding and can I get the 'magic' 
behavior with a few lines of code?

forgive me for my ignorance on this subject, I'm not a fulltime gtk 
programmer and it's sometimes hard to keep track of all the 
possibilities in gtk.

Olivier

Re: [Gtk-osx-users] accelerator problem with GtkOSXApplication

[John R. <jr...@ce...>]

On Feb 14, 2011, at 4:14 AM, Olivier Sessink wrote:

>> Accelerator mapping in GtkOSXApplication is handled the Gtk way, with GtkAccelMaps. This is mentioned in the GtkOSXApplication documentation.
>> 
>> Option/Alt is handled a bit too generically in gdk-quartz, where it's used for i18n regardless of context and consequently ignored when used as an accelerator. Ideally this handling should only occur in the input method, but I haven't figured out how to do that yet and Kristian Reitveld doesn't think it's important enough to do anything about. If anyone knows enough about the simple input method to write a patch to fix this it would be most welcome. Post it to https://bugzilla.gnome.org/show_bug.cgi?id=617583.
>> 
> 
> so what are my options if I do not know the details about input
> methods? I can go back to ige-mac-integration and try to get my menu
> problem solved, but that seems to be a step backwards.. Are there
> other options? Converting the shortcuts in the application code
> somehow?

Like I said, GtkAccelMaps: http://library.gnome.org/devel/gtk/stable/gtk-Accelerator-Maps.html

There's even an example in test-integration.

Learn to use your tools!

Regards,
John Ralls

Re: [Gtk-osx-users] accelerator problem with GtkOSXApplication

[Olivier S. <oli...@gm...>]

> Accelerator mapping in GtkOSXApplication is handled the Gtk way, with GtkAccelMaps. This is mentioned in the GtkOSXApplication documentation.
>
> Option/Alt is handled a bit too generically in gdk-quartz, where it's used for i18n regardless of context and consequently ignored when used as an accelerator. Ideally this handling should only occur in the input method, but I haven't figured out how to do that yet and Kristian Reitveld doesn't think it's important enough to do anything about. If anyone knows enough about the simple input method to write a patch to fix this it would be most welcome. Post it to https://bugzilla.gnome.org/show_bug.cgi?id=617583.
>

so what are my options if I do not know the details about input
methods? I can go back to ige-mac-integration and try to get my menu
problem solved, but that seems to be a step backwards.. Are there
other options? Converting the shortcuts in the application code
somehow?

Olivier

Re: [Gtk-osx-users] accelerator problem with GtkOSXApplication

[John R. <jr...@ce...>]

On Feb 13, 2011, at 1:32 PM, Olivier Sessink wrote:

> Hi all,
> 
> after I moved to GtkOSXApplication I have an issue with the menu accelerators.
> 
> issue 1) menu accelerators use <control> instead of <command>, with
> ige-mac-integration everything was automatically converted to
> <command>. I did not set
> gtk_osxapplication_set_use_quartz_accelerators() (since that is
> enabled by default, right?)
> 
> issue 2) <alt><control>X and <control>X are mapped to the same
> accelerator <control>X (e.g. <control><alt>c is now activated with
> <control>c, and both menu items show <control>c as accelerator)
> 
> any ideas?

Accelerator mapping in GtkOSXApplication is handled the Gtk way, with GtkAccelMaps. This is mentioned in the GtkOSXApplication documentation.

Option/Alt is handled a bit too generically in gdk-quartz, where it's used for i18n regardless of context and consequently ignored when used as an accelerator. Ideally this handling should only occur in the input method, but I haven't figured out how to do that yet and Kristian Reitveld doesn't think it's important enough to do anything about. If anyone knows enough about the simple input method to write a patch to fix this it would be most welcome. Post it to https://bugzilla.gnome.org/show_bug.cgi?id=617583.

Regards,
John Ralls

[Gtk-osx-users] accelerator problem with GtkOSXApplication

[Olivier S. <oli...@gm...>]

Hi all,

after I moved to GtkOSXApplication I have an issue with the menu accelerators.

issue 1) menu accelerators use <control> instead of <command>, with
ige-mac-integration everything was automatically converted to
<command>. I did not set
gtk_osxapplication_set_use_quartz_accelerators() (since that is
enabled by default, right?)

issue 2) <alt><control>X and <control>X are mapped to the same
accelerator <control>X (e.g. <control><alt>c is now activated with
<control>c, and both menu items show <control>c as accelerator)

any ideas?

Olivier

Re: [Gtk-osx-users] GTK 3

[John R. <jr...@ce...>]

On Feb 13, 2011, at 10:32 AM, David Lowe wrote:

> 	What does the new release mean to us?
> 

Depends on what value of "us". Gtk-OSX builds gtk3. Ige-mac-integration works with gtk3 in C, but not Python because I haven't yet learnt to use pygobject instead of pygtk. 

The rest is up to application developers. Stable is now using Gtk2-2.24.0, the last of version 2 which still has all of the deprecated functions and stuff as well as the new stuff. It's up to application developers to port their apps to Gtk3. They (you?) probably have a year before users of the faster-moving distros like Ubuntu start complaining that they have to back-install Gtk2 to use an application. On the other hand, the slower-moving distros (Debian and RHEL) just shipped new releases without it, and their cycle time is about 3 years, so application developers are going to have to decide how to support both Gtk2 and Gtk3 for at least that long.

I'll add a stable Gtk3 (the module will be called gtk+-3.0, just as it is in unstable) soon. At some point, perhaps a year or so, the module names will swap and gtk+ will be for 3.0 and to build gtk2 you'll use gtk+-2.0; at that point Gtk3 will be the default when you build meta-gtk-osx-core.

GObject-introspection is still a bit troublesome on OSX, but works most of the time for both 2 and 3.

Regards,
John Ralls

[Gtk-osx-users] GTK 3

[David L. <doc...@ve...>]

	What does the new release mean to us?

Sent from my MacBookPro

Don't be hesitant.  Digital electronics can smell fear.

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

[Olivier S. <oli...@gm...>]

On 02/12/2011 12:57 AM, John Ralls wrote:

>> I found that get_menu_label_text() returns a NULL label once in a
>> while, and that is why g_object_get warns that NULL is not an object.
>
> Good job.
>
> They're probably separators. Anyway, it's an easy thing to fix, pushed to github.

I use tearoff items in the menu, they are not very often used anymore, 
so I guess these might be the problem.

Olivier

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

[John R. <jr...@ce...>]

On Feb 11, 2011, at 2:32 PM, Olivier Sessink wrote:

> 2011/2/10 Richard Procter <ric...@gm...>:
> 
>> "--g-fatal-warnings.  Make GTK+ abort on all warnings. This is useful to stop on the first warning in a debugger, if your application is printing multiple warnings. It's almost always best to start debugging with the first warning that occurs."
> 
> great suggestion!!!
> 
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   libglib-2.0.0.dylib           	0x00e4a903 g_logv + 1342
> 1   libglib-2.0.0.dylib           	0x00e4aa08 g_log + 44
> 2   libglib-2.0.0.dylib           	0x00e4aa42 g_return_if_fail_warning + 56
> 3   libgobject-2.0.0.dylib        	0x00db16cc g_object_get + 139
> 4   libigemacintegration.0.dylib  	0x00234afc
> cocoa_menu_item_update_accelerator + 161
> 5   libigemacintegration.0.dylib  	0x00234fed
> cocoa_menu_item_update_accel_closure + 353
> 6   libigemacintegration.0.dylib  	0x00235471 cocoa_menu_item_sync + 248
> 7   libigemacintegration.0.dylib  	0x00235783 cocoa_menu_item_add_item + 734
> 8   libigemacintegration.0.dylib  	0x00235bae cocoa_menu_item_add_submenu + 1060
> 9   libigemacintegration.0.dylib  	0x0023494a
> cocoa_menu_item_update_submenu + 720
> 10  libigemacintegration.0.dylib  	0x002354a3 cocoa_menu_item_sync + 298
> 11  libigemacintegration.0.dylib  	0x00235783 cocoa_menu_item_add_item + 734
> 12  libigemacintegration.0.dylib  	0x00235bae cocoa_menu_item_add_submenu + 1060
> 13  libigemacintegration.0.dylib  	0x002388cf
> gtk_osxapplication_set_menu_bar + 688
> 
> I found that get_menu_label_text() returns a NULL label once in a
> while, and that is why g_object_get warns that NULL is not an object.

Good job.

They're probably separators. Anyway, it's an easy thing to fix, pushed to github.

Regards,
John Ralls

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

[Olivier S. <oli...@gm...>]

2011/2/10 Richard Procter <ric...@gm...>:

> "--g-fatal-warnings.  Make GTK+ abort on all warnings. This is useful to stop on the first warning in a debugger, if your application is printing multiple warnings. It's almost always best to start debugging with the first warning that occurs."

great suggestion!!!

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libglib-2.0.0.dylib           	0x00e4a903 g_logv + 1342
1   libglib-2.0.0.dylib           	0x00e4aa08 g_log + 44
2   libglib-2.0.0.dylib           	0x00e4aa42 g_return_if_fail_warning + 56
3   libgobject-2.0.0.dylib        	0x00db16cc g_object_get + 139
4   libigemacintegration.0.dylib  	0x00234afc
cocoa_menu_item_update_accelerator + 161
5   libigemacintegration.0.dylib  	0x00234fed
cocoa_menu_item_update_accel_closure + 353
6   libigemacintegration.0.dylib  	0x00235471 cocoa_menu_item_sync + 248
7   libigemacintegration.0.dylib  	0x00235783 cocoa_menu_item_add_item + 734
8   libigemacintegration.0.dylib  	0x00235bae cocoa_menu_item_add_submenu + 1060
9   libigemacintegration.0.dylib  	0x0023494a
cocoa_menu_item_update_submenu + 720
10  libigemacintegration.0.dylib  	0x002354a3 cocoa_menu_item_sync + 298
11  libigemacintegration.0.dylib  	0x00235783 cocoa_menu_item_add_item + 734
12  libigemacintegration.0.dylib  	0x00235bae cocoa_menu_item_add_submenu + 1060
13  libigemacintegration.0.dylib  	0x002388cf
gtk_osxapplication_set_menu_bar + 688

I found that get_menu_label_text() returns a NULL label once in a
while, and that is why g_object_get warns that NULL is not an object.

Olivier

Re: [Gtk-osx-users] how does "NSApplicationOpenFile" work?

[Olivier S. <oli...@gm...>]

2011/2/11 John Ralls <jr...@ce...>:
>
> On Feb 11, 2011, at 4:22 AM, Olivier Sessink wrote:
>
>> Hi all,
>>
>> I'm playing with the "NSApplicationOpenFile" signal. However, if I try
>> to open a file form the finder right now a new process is started by
>> the finder, but the signal is not trigerred. Is there a piece of
>> example code somewhere that shows how this signal works?
>
> If I remember correctly, the Delegate doesn't get set up quickly enough for the signal to be emitted if the app is opened by launchd on the File Open Apple Event, so the open event is handled only when the app is already active.

even if the app is running I get a new process starting, and with that
new process it seems that the finder doesn't pass any file name as
arguments.... I don't know how this is supposed to work on a mac, so
perhaps I'm looking at the wrong thing.

Olivier

Re: [Gtk-osx-users] how does "NSApplicationOpenFile" work?

[John R. <jr...@ce...>]

On Feb 11, 2011, at 4:22 AM, Olivier Sessink wrote:

> Hi all,
> 
> I'm playing with the "NSApplicationOpenFile" signal. However, if I try
> to open a file form the finder right now a new process is started by
> the finder, but the signal is not trigerred. Is there a piece of
> example code somewhere that shows how this signal works?

If I remember correctly, the Delegate doesn't get set up quickly enough for the signal to be emitted if the app is opened by launchd on the File Open Apple Event, so the open event is handled only when the app is already active.

Regards,
John Ralls

Re: [Gtk-osx-users] how does "NSApplicationOpenFile" work?

[Richard P. <ric...@gm...>]

Hi Olivier, 

You may find my notes in a previous thread on this list helpful: 
Re: [Gtk-osx-users] Notes on handling Apple events with gtk_osxapplication and PyGTK

and also
[Gtk-osx-users] Notes on native OS X save/open dialogs in PyGTK using PyObjC
if you are going down that path.

Here's my code for connecting to NSApplicationOpenFile:

    # ige-mac-integration: render menubar as a normal apple menubar
    if sys.platform == 'darwin':

        import gtk_osxapplication
        macapp = gtk_osxapplication.OSXApplication()

        # Note that on at least gtk 2.18.2, AppleEvents, of which
        # OpenFile is one, are processed on the GTK event queue.
        # Consequently, we will lose OpenFile events if we call
        # utils.flush_gtk_events() before connecting this callback to
        # the "NSApplicationOpenFile" signal.
        def handle_OSX_OpenFile_event(macapp, filename):
            # Note! A limitation of the current GTK-OSX code
            # (2.18) is that we cannot perform any operations
            # involving the GTK run-loop within this handler,
            # therefore we schedule the load to occur afterwards.
            # See gdk/quartz/gdkeventloop-quartz.c in the GTK+ source. 
            
            def callback():
                ui.load_handler(world_model, main_window, filename)
            gobject.idle_add(callback) 

            # Significant! We must indicate we handled this or crash
            # when the NSApp fallsback to open it via our NSDocument,
            # which is just a front to support native open/save dialogs.
            return True 

        if constants.osxbundle_environment():
            # When run via python outside of a bundle, we receive a request to open our toplevel sourcecode! 
            macapp.connect("NSApplicationOpenFile", handle_OSX_OpenFile_event)


def utils.flush_gtk_events(): 
    while gtk.events_pending():
        gtk.main_iteration()

def constants.osxbundle_environment(_cache=[]):
    if not _cache:
        result = False 

        if sys.platform == 'darwin': 
            import gtk_osxapplication
            bid = gtk_osxapplication.quartz_application_get_bundle_id() 
	    # the later occurs when running outside a bundle 
            # under the system python framework. 
 	    result = not (bid is None or bid == 'org.python.pythonapp')

        _cache.append(result) 

    return _cache[0] 

warm regards, 
Richard. 

On 12/02/2011, at 1:22 AM, Olivier Sessink wrote:

> Hi all,
> 
> I'm playing with the "NSApplicationOpenFile" signal. However, if I try
> to open a file form the finder right now a new process is started by
> the finder, but the signal is not trigerred. Is there a piece of
> example code somewhere that shows how this signal works?
> 
> Olivier
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users

[Gtk-osx-users] how does "NSApplicationOpenFile" work?

[Olivier S. <oli...@gm...>]

Hi all,

I'm playing with the "NSApplicationOpenFile" signal. However, if I try
to open a file form the finder right now a new process is started by
the finder, but the signal is not trigerred. Is there a piece of
example code somewhere that shows how this signal works?

Olivier

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

[Richard P. <ric...@gm...>]

On 11/02/2011, at 8:21 AM, John Ralls wrote:
[...]
> 
> 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. 

I've been wondering how to do this for ages, and this exchange pipped my curiosity. According to http://library.gnome.org/devel/gtk/2.21/gtk-running.html:

"--g-fatal-warnings.  Make GTK+ abort on all warnings. This is useful to stop on the first warning in a debugger, if your application is printing multiple warnings. It's almost always best to start debugging with the first warning that occurs."

I haven't used it yet; it might be an overly blunt instrument. 

regards, 
Richard. 

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

[John R. <jr...@ce...>]

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

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

[Olivier S. <oli...@gm...>]

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?

Olivier

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

[John R. <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. 

Regards,
John Ralls

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

[Olivier S. <oli...@gm...>]

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.

Olivier

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

[John R. <jr...@ce...>]

On Feb 10, 2011, at 4:17 AM, Olivier Sessink wrote:

> I just noticed that test_integration is default built with
> gtkosxapplication, and not with ige-mac-integration.
> 
> however, changing the define on top doesn't help, because it doesn't build:
> 
> test-integration.c: In function ‘view_menu_cb’:
> test-integration.c:424: error: ‘GtkOSXApplication’ undeclared (first
> use in this function)
> 
> I'll see if I can fix that myself.
> 
and 
> I ported bluefish to the new GtkOSXApplication API. The menu now
> works, but I get loads of GLib-GObject-CRITICAL **: g_object_get:
> assertion `G_IS_OBJECT (object)' failed warnings in the terminal. Any
> idea what could cause this?
> 
> Bluefish still uses GtkItemFactory menu's, could that be related?
> 
> 2011/2/7 John Ralls <jr...@ce...>:
>> 
>> Interesting, and I'm puzzled. I tested this on ige-mac-integration's src/test-integration and it appears to work as it should.
>> 
>> Would each of you please do the same?
>> 
>> If you can get it to fail, try debugging to see why it fails.
>> 

There was a problem with building with IGE_MAC_INTEGRATION and QUARTZ_HANDLERS defined, and I just pushed a fix to github. 

But view_menu_cb is because you've left BUILT_UI defined, and that only works with the GTK_OSXAPPLICATION code; I'll move that declaration into an #ifdef GTK_OSXAPPLICATION block to bulletproof it.

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.

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.

Regards,
John Ralls

[Gtk-osx-users] lots of GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed

[Olivier S. <oli...@gm...>]

I ported bluefish to the new GtkOSXApplication API. The menu now
works, but I get loads of GLib-GObject-CRITICAL **: g_object_get:
assertion `G_IS_OBJECT (object)' failed warnings in the terminal. Any
idea what could cause this?

Bluefish still uses GtkItemFactory menu's, could that be related?

Olivier

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

[Olivier S. <oli...@gm...>]

I just noticed that test_integration is default built with
gtkosxapplication, and not with ige-mac-integration.

however, changing the define on top doesn't help, because it doesn't build:

test-integration.c: In function ‘view_menu_cb’:
test-integration.c:424: error: ‘GtkOSXApplication’ undeclared (first
use in this function)

I'll see if I can fix that myself.

Olivier

2011/2/7 John Ralls <jr...@ce...>:
>
> Interesting, and I'm puzzled. I tested this on ige-mac-integration's src/test-integration and it appears to work as it should.
>
> Would each of you please do the same?
>
> If you can get it to fail, try debugging to see why it fails.
>
> Regards,
> John Ralls
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>

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

[Olivier S. <oli...@gm...>]

I just has the chance to test on a mac again. The test-integration
code works as expected.

Should I try any older version of ige-mac-integration? (or should I
just move to the new library now?)

Olivier

2011/2/7 John Ralls <jr...@ce...>:
>
> On Feb 7, 2011, at 3:47 AM, Antoine Martin wrote:
>
>> Hi Olivier,
>>
>> I have the same problem! Until you mentioned it here I thought that I
>> had broken something (or that my code was causing problems by constantly
>> rebuilding the menus). I've been igoring the issue since the menus are
>> not essential for using my application.
>>
>> Cheers
>> Antoine
>>
>> On 02/07/2011 05:44 AM, Olivier Sessink wrote:
>>> I removed the complete gtk directory today, downloaded the latest
>>> gtk-osx-build-setup.sh, etc., so it's all the latest versions.
>>>
>>> The menu is not visible at all if I remove the widget_hide(), which
>>> looks weird to me.
>>>
>>> Olivier
>>>
>>> 2011/2/6 John Ralls <jr...@ce...>:
>>>>
>>>> On Feb 6, 2011, at 12:30 PM, Olivier Sessink wrote:
>>>>
>>>>> no difference at all. If I remove the call
>>>>> ige_mac_menu_set_menu_bar(GTK_MENU_SHELL(bfwin->menubar));
>>>>> the menu (now a regular gtk menu) works.
>>>>>
>>>>> the application seems correctly linked:
>>>>> /Users/olivier/gtk/inst/lib/libigemacintegration.0.dylib
>>>>> (compatibility version 1.0.0, current version 1.0.0)
>>>>>
>>>>> Olivier
>>>>>
>>>>> 2011/2/6 John Ralls <jr...@ce...>:
>>>>>>
>>>>>> On Feb 6, 2011, at 7:49 AM, Olivier Sessink wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've rebuild my complete gtk environment for osx 10.5/i386 and now I
>>>>>>> have a weird problem: the menu's are created but I cannot activate
>>>>>>> them (no submenu pops down). I'm still using the ige-mac-integration
>>>>>>> library. Any hints where to look for the cause?
>>>>>>
>>>>>> If you don't hide the gtk menubar, do the gtk menus work?
>>>>>>
>>>>
>>>> When you say "no difference at all", does that mean that the gtk menus are displayed on the window but don't work either? Or that no gtk menus are displayed on the window?
>>>>
>>>> Does the test application (you'll need to change the defines at the top so that IGE_MAC_INTEGRATION is defined and the other two are commented out, then rebuild it) work?
>>>>
>>>> What version of ige-mac-integration do you have? When did you rebuild, and did you start from scratch (i.e, blow everything away, retrieve the latest gtk-osx-build-setup.sh, run that, run jhbuild bootstrap and jhbuild build)?
>
>
> Interesting, and I'm puzzled. I tested this on ige-mac-integration's src/test-integration and it appears to work as it should.
>
> Would each of you please do the same?
>
> If you can get it to fail, try debugging to see why it fails.
>
> Regards,
> John Ralls
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users
>

Re: [Gtk-osx-users] unable to build on 10.6.6

[Anthony D. <ad...@gm...>]

On Mon, 07 Feb 2011 16:34:12 -0500, John Ralls <jr...@ce...> wrote:

>
> On Feb 7, 2011, at 11:55 AM, Anthony Dardis wrote:
>
>> Dear GTK+-2 OSX Users,
>>
>> On a MacBook Pro, Intel Core 2, OS X 10.6.6,
>>
>> jhbuild bootstrap
>>
>> fails; the last few lines of the output are
>>
>> /usr/bin/gcc-4.0 -std=gnu99 -I. -I/Users/prog/gtk/inst/include  
>> -I/Developer/\ SDKs/MacOSX10.6.sdk/usr/include  
>> -I/Developer/SDKs/MacOSX10.4.sdk/usr/include -\ arch i386  
>> -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -arch i386 -I/Developer/\  
>> SDKs/MacOSX10.4.sdk/usr/include -arch x86_64 -mmacosx-version-min=10.6  
>> -isysroo\ t /Developer/SDKs/MacOSX10.4.sdk -mmacosx-version-min=10.4  
>> -isysroot /Developer\ /SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6  
>> -MT gl_avltree_oset.o -MD -MP -M\ F .deps/gl_avltree_oset.Tpo -c -o  
>> gl_avltree_oset.o gl_avltree_oset.c gcc-4.0: -E, -S, -save-temps and -M  
>> options are not allowed with multiple -arch\ flags
>> make[3]: *** [gl_avltree_oset.o] Error 1
>> make[2]: *** [all] Error 2
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2 *** Error during phase build of m4: ##########  
>> Error running make *** [2/10]
>>
>> I started out by clearing everything out of the account; then
>>
>> sh gtk-osx-build-setup.sh
>>
>> then edited .jhbuildrc-custom and put the following 3 lines at the end:
>>
>> moduleset =  
>> "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules"
>> setup_sdk(target="10.4", sdk_version="10.4", architectures=["i386"])
>> setup_sdk("10.6", "10.6", ["i386"])
>>
>> (following the two sets of instructions for building on Snow Leopard),  
>> then did
>>
>> jhbuild boostrap
>>
>> I tried the same process but without the line
>>
>> setup_sdk(target="10.4", sdk_version="10.4", architectures=["i386"])
>>
>> (guessing here about "multiple -arch flags") but got the same result.
>>
>> I have Python 2.6.1, svn 1.6.5, and git 1.7.3.5 installed, and the  
>> developer tools from Xcode from the install DVD (for example,  
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
>>
>
> Do it again, making sure that you call setup_sdk() exactly once in your  
> jhbuildrc-custom, and post the actual output from that run. If there are  
> two sets of CFLAGS, especially if they have different SDKs, then you've  
> either got two calls to setup_sdk() or you're trying to build from  
> inside a jhbuild shell.
>

Thanks, John, that did it: I commented out the setup_sdk() call that  
.jhbuildrc-custom initially supplies, put in this one:

setup_sdk("10.6", "10.6", ["i386"])

along with the 'moduleset =', etc., to get the stable modulesets, and the  
whole build succeeded (that is, the three steps

jhbuild bootstrap
jhbuild build meta-gtk-osx-bootstrap
jhbuild build meta-gtk-osx-core

all succeeded).

Re: [Gtk-osx-users] unable to build on 10.6.6

[John R. <jr...@ce...>]

On Feb 7, 2011, at 11:55 AM, Anthony Dardis wrote:

> Dear GTK+-2 OSX Users,
> 
> On a MacBook Pro, Intel Core 2, OS X 10.6.6, 
> 
> jhbuild bootstrap
> 
> fails; the last few lines of the output are
> 
> /usr/bin/gcc-4.0 -std=gnu99 -I. -I/Users/prog/gtk/inst/include -I/Developer/\ SDKs/MacOSX10.6.sdk/usr/include -I/Developer/SDKs/MacOSX10.4.sdk/usr/include -\ arch i386 -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -arch i386 -I/Developer/\ SDKs/MacOSX10.4.sdk/usr/include -arch x86_64 -mmacosx-version-min=10.6 -isysroo\ t /Developer/SDKs/MacOSX10.4.sdk -mmacosx-version-min=10.4 -isysroot /Developer\ /SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -MT gl_avltree_oset.o -MD -MP -M\ F .deps/gl_avltree_oset.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c gcc-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch\ flags
> make[3]: *** [gl_avltree_oset.o] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2 *** Error during phase build of m4: ########## Error running make *** [2/10] 
> 
> I started out by clearing everything out of the account; then
> 
> sh gtk-osx-build-setup.sh
> 
> then edited .jhbuildrc-custom and put the following 3 lines at the end:
> 
> moduleset = "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules"
> setup_sdk(target="10.4", sdk_version="10.4", architectures=["i386"])
> setup_sdk("10.6", "10.6", ["i386"]) 
> 
> (following the two sets of instructions for building on Snow Leopard), then did 
> 
> jhbuild boostrap
> 
> I tried the same process but without the line 
> 
> setup_sdk(target="10.4", sdk_version="10.4", architectures=["i386"])
> 
> (guessing here about "multiple -arch flags") but got the same result.
> 
> I have Python 2.6.1, svn 1.6.5, and git 1.7.3.5 installed, and the developer tools from Xcode from the install DVD (for example, i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
> 

Do it again, making sure that you call setup_sdk() exactly once in your jhbuildrc-custom, and post the actual output from that run. If there are two sets of CFLAGS, especially if they have different SDKs, then you've either got two calls to setup_sdk() or you're trying to build from inside a jhbuild shell.

Regards,
John Ralls