Re: Alt and Command keys in the quartz backend

[John Ralls <jralls ceridwen us>]

On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote:

> On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote:
>> 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. 
> 
> It is not the right thing to do. Why do you insist on that,
> and what is wrong about the "hard-coded" association between
> ALT and MOD1_MASK? What is the problem about fixing GDK to
> map Alt to what is globally considered Alt, and then fix
> the platform-specific things in GTK+ afterwards?


For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3.

For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated.
 
Nothing is wrong with <alt> being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write "(Command-foo on Macs)" next to every occurrence of "The accelerator for Bar is Alt-foo"?

Regards,
John Ralls