[no subject]

>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? 

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".

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.

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?

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 :)

--p