Re: [Gtk-osx-users] menu synchronisation

[John Ralls <jralls ceridwen fremont ca us>]

On Apr 2, 2010, at 11:58 AM, Olivier Sessink wrote:

> 2010/4/2 John Ralls <jralls ceridwen fremont ca us>:
>> No. The section between 909 and 927 adjusts the index if a menu item addition or deletion has caused the index to be off by one.
>> But changing the checked state during synchronization wouldn't do what you want anyway, because you don't call ige-mac-menu-sync in the menu event handlers. You call it when you've changed the menu layout by adding, deleting, or hiding a menu item.
> 
> ok, something I misunderstood then. I also call it when I change the
> state of a check menu item.
> 
> I work on bluefish, an editor, which has a multi-document interface.
> Each document may have different options (e.g. 'wrap'). So whenever
> the user switches documents, I need to sync for example the
> Document->Wrap menu state.
> 
> How do I do this with ige-mac-integration?
> 
>> What you want is for carbon_menu_item_update_active to be called during event handling. It is, at line 530, in carbon_menu_item_notify, which is a callback function registered at line 574 in carbon_menu_item_connect. The problem is likely to be that the pspec->name received in carbon_menu_item_notify isn't "active" when your GtkCheckMenuItem is clicked, so that's the first thing to debug on.
> 
> When it is clicked it is synchronised correctly. It is not
> synchronised when the state is changed without clicking.

Make sure that you call ige_mac_menu_set_menu_bar every time you create a new menu. Among other things, it registers the window_focus function as a callback on the window's "focus-in-event" signal and switches the menus for you.

There's a pretty serious bug here, though: There's only one App menu (that's the one next to the Apple logo called in your case "Bluefish") and if you add things like "About" and "Preferences" to it in your window creation code, you'll get an entry for them for each window; on the other hand, if you do so only for one, the entries you do get will stop working when that window is closed. The quit menu item can be set only once, so when the first window that's done for is closed, it stops working too. At that point the only way to quit is to close all of the windows with the red dot.

I have a fix for that problem, but it would be a lot of work to implement for Carbon, so it will only be in the Cocoa version that I'm working on finishing up now. 

As for changing the state of GtkCheckMenuItems behind the user's back, that should fire off a "notify" signal when you change the "active" property. (You are using gtk_check_menu_item_set_active() to toggle it, right?) If it isn't, try calling gtk_check_menu_item_toggled() to force it. If that still doesn't work, you'll have to add a signal handler for the GtkCheckMenuItems "toggle" signal explicitly.

Regards,
John Ralls