Re: Disabling "alt-*" menu functionality

I'm confused by your response: I'm not asking about application development, I'm asking about how to work with or disable gtk's handling of those mnemonics after the fact. It appeared that setting "gtk-enable-mnemonics=0" may have worked for all gtk-2 applications (per the ticket I linked),

Re: Disabling "alt-*" menu functionality

Mnemonics are created, AFAIK, in the code when the menu items are constructed. There are various ways this can be done, but I suspect it cannot be undone if you all you have is a ready to run application. In GTK2, the simplest way to do this was to put an underscore in front of the desired letter

Re: Disabling "alt-*" menu functionality

I didn't write the app. I want to be able to disable the mnemonics globally, and there doesn't appear to be a way to do that in gtk-3. John On 12/08/2016 03:38 PM, Paul Davis wrote: Don't create mnemonics when creating menu items. That's all. Our app (Ardour) is GTK (2) but we never define

Re: Disabling "alt-*" menu functionality

Don't create mnemonics when creating menu items. That's all. Our app (Ardour) is GTK (2) but we never define any menu mnemonics, and consequently there are no Alt-* bindings created by GTK (we need all available bindings for the app's own control and management. On Thu, Dec 8, 2016 at 11:23 PM,

Disabling "alt-*" menu functionality

Is there any way to prevent gtk from taking over "alt-*" handling (e.g. alt-f for _File menu, alt-e for _Edit menu) from the application? I can see that some users use that, but others (like me) prefer to rebind alt to other functionality (e.g. find in Firefox). Looking into this launchpad

Re: gtk_file_chooser_dialog_new and gtk_file_chooser_native_new very slow on a Windows 10 64-bit PC

On 12/08/2016 10:24 AM, Ian Puleston wrote: > Yep, this was it. I disabled the floppy drive in the BIOS as the poster > there said he did, and the problem went away - now the file chooser dialogs > open immediately. Also the first two paragraphs there almost exactly mirror > the OS and hardware

RE: gtk_file_chooser_dialog_new and gtk_file_chooser_native_new very slow on a Windows 10 64-bit PC

> From: Timm Bäder [mailto:m...@baedert.org] > > On 07.12, Ian Puleston wrote: > > A little debugging showed that the time is spent in > > gtk_file_chooser_dialog_new which takes 15 seconds to execute. I tried > > switching to gtk_file_chooser_native_new instead but it too has the > > same

Re: gtk_file_chooser_dialog_new and gtk_file_chooser_native_new very slow on a Windows 10 64-bit PC

Ian, On Thu, Dec 8, 2016 at 9:35 AM, Timm Bäder wrote: > On 07.12, Ian Puleston wrote: >> A little debugging showed that the time is spent in >> gtk_file_chooser_dialog_new which takes 15 seconds to execute. I tried >> switching to gtk_file_chooser_native_new instead but it too

Re: gtk_file_chooser_dialog_new and gtk_file_chooser_native_new very slow on a Windows 10 64-bit PC

On 07.12, Ian Puleston wrote: > A little debugging showed that the time is spent in > gtk_file_chooser_dialog_new which takes 15 seconds to execute. I tried > switching to gtk_file_chooser_native_new instead but it too has the same > problem taking just as long. Was the debugging just a printf