On Sep 6, 2011, at 3:46 PM, Michael Natterer wrote:

> On Tue, 2011-09-06 at 14:30 -0700, John Ralls wrote:
>> 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 <mi...@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.
> 
> I have no idea what you are talking about.
> 
>> 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"?
> 
> Why on earth would you want to map both keys to the same modifier?
> 
> Nobody uses "Alt" for accelerators, I don't think we are talking
> about the same things here, in GTK+:
> 
> - Accelerator is the thing to invoke actions (menu shortcuts)
>  -> invoked by Command on the mac, and by Control on != Mac.
> 
> - Mnemonic is the thing that invokes the underlined stuff
>  -> invoked by Alt on != Mac, doesn't exist on the Mac
> 
> Where is the conflict here? We just need to make sure accelerators
> are invoked by whatever modifier combination is triggered by Command,
> and making it the same as the modifier triggered by Alt doesn't make
> any sense.
> 
> And just to finally say it, please spare us this aggressive undertone.

I quit.

Regards,
John Ralls

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to