> > The symbol is the unicode value of the symbol the key is supposed to produce
> > under the current locale and the modifiers in effect.
> cool. so what modifiers can (possibly) exist ?

There is a modifiers field in the event that has a bitfield of the modifiers
that are currently in effect. Possible bits are:

#define GII_MOD_SHIFT   (1 << GII_KM_SHIFT)
#define GII_MOD_CTRL    (1 << GII_KM_CTRL)
#define GII_MOD_ALT     (1 << GII_KM_ALT)
#define GII_MOD_META    (1 << GII_KM_META)
#define GII_MOD_SUPER   (1 << GII_KM_SUPER)
#define GII_MOD_HYPER   (1 << GII_KM_HYPER)
#define GII_MOD_ALTGR   (1 << GII_KM_ALTGR)
#define GII_MOD_CAPS    (1 << GII_KM_CAPS)
#define GII_MOD_NUM     (1 << GII_KM_NUM)

Moreover you will get keypresses and releases when modifiers are
engaged/disengaged. These events are a little more detailed, as they
also give a left/right flag for the modifiers that are present twice.

> > Regarding unicode values: We used some values of the User defined unicode
> > ranges to represent "metasymbols" like cursor movement and function keys.

> Sorry, I'm no unicode expert. Is there really a unicode value semantically
> equivalent to 'move the focus forward' ?

No. We used a unicode range that is "reserved for applicaion defined use".

It is intended to be used for carrying metadata like the above.

> Good. I introduced my own event definition though because in general I want
> to abstract from 'real' devices so it doesn't hurt if a given setup has no
> keyboard or mouse at all. 

Yes. Good. X is a royal pain without keyboard.

> comes from. This way, I can program the controllers in a way which is not 
> only completely device independant but also highly configurable. 
> You can map whatever events to whatever state changes/commands to be 
> triggered. You can especially say that you want to combine mouse 
> positional/button events with the keyboard modifiers into one event type. 

Well basically you could use the LibGII filters feature, which allows to do
the same. However I think it is good, if Berlin does it itself, as ou can
then more easily provide a GUI configuration tool that does not interact
with GII directly which gives less versionning headaches.

> > However there will probably be a problem with eastern languages that utilize
> > popupmenus to select a symbol from several that have the same keyboard
> > representation.
> oh, that sounds ugly. So is the keyboard symbol interpreted as a glyph 
> and the user must then choose one of the unicodes corresponding to it ? 

I don't know from experience. The way people explained it to me, it is like 
entering the vocal expression by the keyboard and you will then get a list
of all possible symbols that sound this way (but have different meaning of
course ...) ...

> I mean, if I write a text, I'm more concerned about the content than about 
> the form, so I would want my keys to correspond to characters rather 
> than glyphs. Anyway, we'll see how far we can get with this info.

The problem seems to exist with the languages that have a huge number of
characters/symbols. As you can't get them onto a reasonably sized keyboard, 
you use a reduced keyboard that can somehow express the vocal properties
and a database lookup that will give all possible chars that sound this way.

One probably has to see this live to fully understand how it works. Anyone
here that works with such a system, who could give some first hand knowledge

> > The underlying system is usually configured by the usual tools like loadkeys
> > or xmodmap.
> yeah. (xmodmap certainly not :)

Oh - well, I don't see a problem running Berlin on top of X - as well as
vice versa. This should help users to make the transition to Berlin easier,
as they can 1. trial run it on their X and 2. use their old X apps on top of
Berlin, when they miss them.

CU, Andy

= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to