Re: gtk_accelerator_set_default_mod_mask ()

[Tim Janik <timj gtk org>]

On Sat, 2 Feb 2002, Owen Taylor wrote:

> Would it make sense to add:
> 
>  mask |= GTK_MOD1_MASK | GDK_SHIFT_MASK | GDK_CONTROL_MASK
> 
> to this function... that is, not allow setting a mask more restrictive
> than the default mask?
> 
> If you set a mask more restrictive than the default mask, the result
> is that all the bindings for the standard GTK+ widgets break ... see
> Jody's earlier mail on the subject.
> 
> I'm not really sure why you'd want to call this function at all, but
> it's conceivable that expanding the mask would make sense.
> 
> (The main problem with expanding it is that the binding of
> MOD2,... aren't mapped in any standard way to symbols. We get away
> with ignoring this issue for MOD1, but that doesn't work for the other
> modifiers.)

urm. gtk_accelerator_set_default_mod_mask() was introduced when
gimp's keybindings wouldn't work because you had num-lock turned on,
so essentially gimp upon startup could tell gtk to ignore num-lock.
we later changed the default mod mask used by gtk, and there's not been
a good reason to use gtk_accelerator_set_default_mod_mask() since (i can't
think of one at least).

if users want to extend the default mod mask to support e.g. windows keys
an x86 keyboards, that'd be a valid alteration to the default mod mask,
but it'd be a per-user thing, not a per-program thing.

so ideally, we'd have _gtk_accelerator_set_default_mod_mask() internally
to gtk only, and an rc-file flag property that allowed users to tell gtk
to support additional modifiers in the default mask.

with the API already frozen, what comes closes to that is to make
gtk_accelerator_set_default_mod_mask() essentially a NOP (short of
deprecating it) and adding that rc-file property.

> 
> Regards,
>                                         Owen 

---
ciaoTJ