Jay <[EMAIL PROTECTED]> writes:
> > > case GIIK_P4: byte4 = 1; break;
> > > case GIIK_P6: byte4 = 2; break;
> > > case GIIK_P2: byte4 = 4; break;
> > > case GIIK_P8: byte4 = 8; break;
> >
> > The sym filed of a key event can never contain any of these. The sym
> > field describes the meaning of the key, which would be plain '4', '6',
> > '2' and '8' respectively for the above keys.
> >
> > > case GIIK_PEnter: byte4 = 16; break; // Start
> > > case GIIK_PPlus: byte4 = 32; break; // Select
> >
> > Neither can it contain any of these. Sym field would be GIIK_Enter and
> > GIIK_Plus (which is equivalent to '+').
>
> Then how can I get keys from the keypad?
If we take the "1" key on a standard PC keyboard, label will always be
GIIK_P1. Sym will be GIIUC_1 (ASCII '1') when numlock is active and
GIIK_End when when numlock is inactive.
>
> > > case 27: S9xExit (); break;
> >
> > Broken assumption, use GIIK_Escape.
>
> I think you mean GIIUC_Escape. Done
Yes, sorry about that.
> > You might want to consider using the label field as the sym field
> > will change for many keys when you have a modifier pressed. For
> > things like '+', '-' and other non-alphanumeric symbols it is however
> > wise to check the sym field as many keyboard maps don't have these
> > on an unshifted keys.
>
> What does label accually do? I tried that, but none of the letter keys worked. So
> your saying I need to check both sym and label? I beleve my only problem now is that
> the GIIK_P* keys don't work. what do I need to check for that? label doesn't seem to
> have any effect on that.
Basicly label is excatly what it sounds like - the label on the key.
The reason your letter keys don't work when using the label field is
that if you look at your keyboard it really says 'A', and not 'a',
right? ;) (Well, obviously we can't know what's printed on the user's
keyboard, so the convention is that label is always the uppercase
variant of letters)
In case the key has more than one character labeled on it the label
field is either the character you get without any modifiers or the
"most prominent" (0-9 and '.' on a PC numeric keypad (because
"numeric" implies numbers, even though you have to have numlock
active to get numbers)).
It might be a bit hard to grasp at first, but it is really extremely
powerful. If you are only interrested in what physical key's are
pressed and released (most games for example) you read the label
field. If you just want a stream of ASCII characters (for text
input) you simply read the sym field. Most other systems only give
you one of these, and if you are lucky they contain a more or less
complicated API so you can find out the other one.
(I can tell you that there is a reason why most applications using
raw Xlib (as opposed to a toolkit like GTK or QT) don't handle
the Compose key properly. LibGGI/GII ofcourse handle this fine. ;)
> I don't know what my problem was, but I suspect it was this:
>
> The way I fixed the problem was to simply "export GGI_DISPLAY=display-svgalib" on the
> command line. Also, libggi segfaults in X unless I use "export GGI_DISPLAY=display-x"
> or "export GGI_DISPLAY=display-xlib"
The X part is strange, what does the DISPLAY environment variable
hold?
> I don't really want to speculate, but this is all I can think of that could happen:
> When ggiInit() is called, it goes through a list of targets in a certian order until
> it finds a working target. The problem is for each target it attempts to open, it
> calls libgii before it knows if the target works. That means everytime it fails to
> get a display (such as fb-dev) libgii is called before libggi knows whats going on!
> libgii cannot backout, and therefore, the running app segfaults. This might be due to
> threads.
Well, you are sort of correct. ggiInit() doesn't go through any list
though. ggiOpen(NULL) on the other hand works like this:
If GGI_DISPLAY is set it will do a ggiOpen(getenv("GGI_DISPLAY"), NULL)
otherwise it will do a ggiOpen("auto", NULL). "auto" is a pseudo-
target which will select the "most apropriate" target. The logic
to select that basicly works like this:
If DISPLAY is set, try the display-x target.
If that fails, try targets in this order:
display-fbdev
display-svgalib
display-aa
and use the first we can open.
> I don't accually beleave this is what was happening, but thats what I came up with.
> Can you come up with something better?
For the fbdev target it is true that it opens inputs before it
knows that a framebuffer device is available. However both LibGGI
and LibGII knows exactly what's going on, and "backing out" indeed
works just fine here. If you are experiencing strange things like
this, please post the output of GGI_DEBUG=255 and there's a good
chance someone here can see what goes wrong.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
