Re: Alt and Command keys in the quartz backend

[John Ralls <jralls ceridwen us>]

On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote:

> On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote:
>> On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer <mitch gimp org> wrote:
>>> On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote:
>> 
>> [ ... imminent turf war ... ]
>> 
>> this seems to be about two different things, neither of which are in
>> conflict (and i think john actually agrees with this).
>> 
>> 1) whether or not the Alt key should generate MOD1 as a modifier
>> 2) whether or not code that wants to be cross-platform can assume that
>> they can use MOD1 with its own chosen semantics
>> 
>> the problem is that (2) includes GTK, not just applications, and GTK
>> already makes this assumption. as a result, john changed the modifier
>> that alt/option generates on OS X, because (2) is not true for OS X.
>> 
>> if (2) was fixed so that GTK was not an example of code that assumes
>> that MOD1 is free for any interpretation on any platform, then (1) is
>> moot, and it really doesn't matter what the Alt key generates on OS X
>> (hence, it could be MOD1).
>> 
>> but as long as (2) remains an issue within GTK itself, its hard to
>> argue that a key that has clearly different purposes for a large body
>> of platform users of OS X should be handled by GTK as if it had some
>> different meaning based on another platform.
> 
> That's not what I'm asking for. The only special meaning of "Alt"
> in GTK is to invoke mnemonics. Other than that, it's simply a modifier.
> Same on the Mac, it's just a modifier. Let's just disable the mnemonics
> on the Mac then.
> 
> The fact that the OS uses it to generate special characters is
> not really relevant here. One X11 window manager "steals" key
> combo A from the app, the other one key combo B, there is nothing
> I can do about this.
> 
> Turning "Alt" into "Alt" fixes more than it breaks. It fixes e.g.
> configuring GTK keybindings (you can easily make Alt-cursor do
> word navigation then, the config file says alt, it's all correctly
> mapped, the modifier says alt, and it just works).
> 
> And it's not just key bindings. Alt-click should be alt-click,
> there is nothing wrong about that. If the OS decides to use it
> for its own purposes, then it's the job of higher-level code
> to be aware of that. 
> 
> If we need to change something in GTK as a consequence of that
> change, then so be it, but please let's not do strange stuff
> to the quartz' backend's modifier mapping just to accommodate
> some code in GTK that was never meant to handle the Mac, but
> can easily be changed to simply do it.

It's not really different. Getting rid of the hard-coded association between <alt> in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. 

This doesn't have anything to do with being able to map option-d to an accelerator map item <alt>d and have it work. It won't. (At present in master <alt>d will map to command-d, which works fine and presents only a documentation problem to the app developer.)

Regards,
John Ralls