Re: [Gtk-osx-devs] Stop the beeping



On Jun 15, 2010, at 10:54 PM, Hamish Mackenzie wrote:

> I have been using the following patch to stop unwanted beeping when Command+C, Command+V and Command+X are pressed in the latest version of Leksah (sorry I did not get around to sending this sooner).
> 
> The change to menu_event_handler_func stops the beeping.
> 
> The change to sync_menu_shell worked around a bug that I think has now been fixed in git.
> 
> ~/gtk/source/ige-mac-integration$ git diff
> diff --git a/src/ige-mac-menu.c b/src/ige-mac-menu.c
> index 3b85dbd..f170e9f 100644
> --- a/src/ige-mac-menu.c
> +++ b/src/ige-mac-menu.c
> @@ -711,7 +711,7 @@ menu_event_handler_func (EventHandlerCallRef  event_handler_call_ref,
>                                   (gpointer) &idleData->widget);
>        g_idle_add_full (G_PRIORITY_HIGH, activate_idle_cb,
>                         idleData, activate_destroy_cb);
> -       return noErr;
> +       return eventNotHandledErr;
>        break;
>     case kEventClassMenu:
>        if (event_kind == kEventMenuEndTracking)
> @@ -720,7 +720,7 @@ menu_event_handler_func (EventHandlerCallRef  event_handler_call_ref,
>     default:
>        break;
>     }
> -    return CallNextEventHandler (event_handler_call_ref, event_ref);
> +    return eventNotHandledErr;
> }
> 
> static gboolean
> @@ -928,11 +928,10 @@ sync_menu_shell (GtkMenuShell *menu_shell, MenuRef carbon_menu,
>        if (GTK_IS_CHECK_MENU_ITEM (menu_item))
>            carbon_menu_item_update_active (carbon_item, menu_item);
>        carbon_menu_item_update_accel_closure (carbon_item, menu_item);
> -       if (gtk_menu_item_get_submenu (GTK_MENU_ITEM (menu_item)))
> -           carbon_menu_item_update_submenu (carbon_item, menu_item, debug);
> +       GtkWidget *submenu = gtk_menu_item_get_submenu (GTK_MENU_ITEM (menu_item));
>        {
> -           GtkWidget *submenu;
>            if (submenu) {
> +               carbon_menu_item_update_submenu (carbon_item, menu_item, debug);
>                sync_menu_shell (GTK_MENU_SHELL(submenu), 
>                                 carbon_item->submenu, FALSE, debug);
>            }

You're better off putting your effort into re-porting your application code to use GtkOSXApplication, which uses Cocoa -- meaning that it has a chance of working on future versions of OSX. 

The first hunk seems wrong: By queueing a signal, Gtk has taken responsibility for the event and no further processing should be required. 

I agree that the second hunk is correct; it's not appropriate to call the next handler if we're just passing the result of it back. Event Manager will take care of that if we return eventNotHandledErr.

The last hunk won't apply against the current code, and appears to be stylistic in any case. What is it supposed to change?

Regards,
John Ralls






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]