Re: setting gdk display

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-10-25 at 23:13, Paul Davis wrote:
> Owen wrote:
> 
> >The definition that GTK+ makes: MOD1 *is* Alt (the modifier used
> >for accelerator bindings, etc.) works much better than any attempt to
> >look at the keysym does.
> >
> >Everybody wants Mod1 to pop up their menus, virtually everyone has
> >Mod1 immediately adjacent to the spacebar. But sometimes that key
> >is Alt, sometimes it is Meta.
> 
> As I see it, and as the original X Window docs see it on my reading,
> Mod1 is NOT a key and Mod1 is most definitely not a position on a
> keyboard. Mod1 is a just a semantic-free tag bound by a user to a
> key. GTK doesn't make the definition that "Mod1 is Alt". It defines
> Mod1 as the modifier used for certain operations. I can bind another
> key to Mod1, and presto, it now does the same things that any other
> key bound to Mod1 does. There is no special relationship between Alt
> and Mod1 other than a convention that seems to have emerged in XFree86
> and/or distributions that this should be the default binding when X
> starts up. That convention could be broken next week by XFree86 or a
> distributor and GDK could do (almost) nothing about it.

GTK+ does something about it by being there; XFree86 or a distributor
can't afford to suddenly make all GTK+ programs not work correctly.
And (while I haven't tested extensively) I think many other toolkits
and programs make the same assumption.

> >Alt would not be a virtual modifier, because that just creates more
> >problems than it solves.
> >
> >The interesting virtual modifiers are Super and Hyper. (We'd also have
> >NumLock and ScrollLock because they are easy to do, if less useful.)
> 
> i generally find persistent modifier keys to be more or less useless
> as modifiers. and in fact they quite often cause problems sometimes by
> confusing users: "why isn't this key working the way it used to?"
> (this is very noticeable in emacs; accidentally press numlock, and all
> of a sudden many of your finger-memorized keystrokes in emacs cease to
> work).

If this happens, it's a bug in the application, or possibly in your
config. (Maybe you have NumLock mapped to the same modifier bit as some
other key symbol.)

I haven't seen any problems with Emacs recently..

> >On Sat, 2003-10-25 at 15:17, Paul Davis wrote:
> >> the specific problem with the relationship between keyboards and X
> >> modifiers is that X imposes no policy on bindings. its become "normal"
> >> for Alt to be bound to mod1, but there is no requirement that this be
> >> true, let alone that Alt_L and Alt_R should necessarily be the same
> >> modifier. 
> >
> >The basic idea is to have applications refer to hyper and super, and
> >GTK+ deals with the whole which-modifier-bit-is-that issue. See 
> 
> what happened to meta? 

Meta is useless because both Alt and Meta got mapped into the "Alt/MOD1"
role on different systems. The best policy is to discard Meta as an
independent modifier.

> i personally think this is all semantics. X defined a number of
> modifiers and gave them meaningless names with no particular bindings
> specified.  it feels as if what you're proposing is an identical
> scenario, only replacing the meaningless names like "modN" with ones
> like "hyper".

There just aren't enough bits in the modifiers field to make standards
like "Mod3 is the Windows key". Plus, there is *extensive* diversity
in how these modifier bits get mapped to key symbols currently beyond
Mod1.

> until you go as far as windows or the mac does, none of this really
> makes life easier for users or developers. on those platforms,
> everybody knows that the key marked "FOO" does the job known as
> "foo". i know this task is much more difficult for linux, because of
> the diversity of the hardware involved. but i also think that
> replacing X's semantic-free, generic modifier names with GDK
> semantic-free, generic modifier names isn't changing the situation in
> any meaningful ways. owen noted that "hyper" etc. are to be considered
> "virtual modifiers", yet "mod1" etc. are already virtual modifiers
> that are specifically not associated with specific keys.

What I'm proposing isn't just renaming; I'm talking about using 
modifier names that correspond directly with key symbol names,
instead of having *more* names. The problem then just becomes that
the key symbol names used for extra modifiers don't correspond to what
is actually printed on the keyboard.

Because of the great diversity in hardware out there, and because
so much hardware has the Windows logo there, I don't see any way
around that. 

> i can't reliably tell a user that they should press <key>-<button1>,
> because X (and GDK) doesn't give me keyboard state along with button
> events.  it gives me buttons and modifiers in the event->state
> field. until the key<=>modifier binding is defined and cast in stone,
> i still can't predict with true confidence what <key> will cause a
> certain bit to be set in the event->state field. and i note that the
> linux world doesn't even have a standardized name for the key engraved
> on most keyboards with a "windows" logo. is it "hyper", "super",
> "start", "windows", "logo" - i've seen all these names used. what key
> do i press to get mod5 or mod4?

Standardizing keymaps and documentation here is a reasonable thing to
do. For a long time, things got screwed up here by the whole Meta/Alt
mess, but now XFree86 is shipping a reasonable Windows => Super setup by
default.

But it's going to be *much* easier to standardize on how to refer
to Super in documentation than how to refer to mod4.

> to be honest, none of this will likely affect me soon, because i think
> that ardour is going to adopt a radical new UI model from another
> system called protux [sic]. we're taking it a bit further, to the
> point that every key can function as either a mouse button (as one of
> the developers commented "no mouse ever has enough buttons") or can be
> a mouse button modifier. this requires that we track keyboard state
> ourselves, which we already do, and that we forget about the
> event->state field entirely (it won't contain enough
> information). that's why i mentioning this now, because i think that
> in a couple of months, i won't care anymore :)

Hopefully the hardware limitations of standard keyboards won't trip you
up here. (When you start doing arbitrary chords on PC keyboards, you
get some strange results because the keys aren't really wired up 
independently.)

Regards,
						Owen