Re: [Gtk-osx-users] menu synchronisation

[John Ralls <jralls ceridwen fremont ca us>]

On Apr 2, 2010, at 2:17 PM, Olivier Sessink wrote:

> 2010/4/2 John Ralls <jralls ceridwen fremont ca us>:
>>> 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.
> 
> sorry I didn't explain that correctly. They all share the same menu. I
> just change the states of the menu. When the user switches to a
> different document I disconnect the notify signal, set the state of
> the check menu item, and connect the signal handler again.
> 
> 
>> 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.
> 
> I guess we found the problem here: I don't want to call the signal
> handler, because it will actually toggle the setting. I just want to
> update the menu item to represent the correct state. That's why I
> disconnect, set and connect again. Currently in my code I call
> ige_mac_menu_sync() after that, but as we discussed before, this
> doesn't sync the toggle state.
> 
> Would it be a problem to add this functionality to the _sync() function?

OK, I get it.

You can try moving
    if (GTK_IS_CHECK_MENU_ITEM (menu_item))
	carbon_menu_item_update_active (carbon_item, menu_item);

 from 630 in carbon_menu_item_create, to 932 in sync_menu_shell before 
	if (GTK_IS_CHECK_MENU_ITEM(carbon_item) && carbon_item
	if (!carbon_item->submenu) {
	    carbon_index++;
	    continue;
	}

Regards,
John Ralls