Two Keyboard Issues/Questions (linux)

[michael.nischt]

Hi all,

This is my first post in this forum and I am quite new to the LWJGL. Therefore I hope the questions are too stupid.


1. Keyboard does NOT support INSERT,DELETE, HOME, END, PAGE_UP, PAGE_DOWN?

I noticed that there are no KEY_PAGE_UP and KEY_PAGE_DOWN constants. Are these not available or do these simply have other names?

Further, I noticed that 'isKeyDown' always returns false for KEY_INSERT, KEY_DELETE, KEY_HOME and KEY_END (and probably others). However, the array keys and character keys work fine.

(tested it on Ubuntu 10.04.1)


2. Keyboard relies on Display?

This is more a 'design' question to help me better understand the concepts behind the LWJGL:

Reading the API docs I noticed:

"Create" the keyboard. The display must first have been created. The reason for this is so the keyboard has a window to "focus" in.

And searching the forum I found:

Except, if I understand correctly, the keyboard can't be created without first creating a display. And creating a display automatically creates a keyboard, rendering Keyboard.create() completely useless.

This reflects the behavior of my code:

public static void main(String[] arguments) throws Exception
{
    Display.create();
    Keyboard.create();

    while(true)
    {
        Display.update();

        boolean exit = false;

        for(int i=0; !exit && i< Keyboard.getKeyCount(); i++)
        {
            if(Keyboard.isKeyDown(i))
            {
                System.out.println(Keyboard.getKeyName(i));
                exit = true;
                break;
            }
        }

        if(exit) break;
    }

    Keyboard.destroy();
    Display.destroy();
}

My problem is that I would like to use the 'Keyboard' class in junit tests together with mocking events using java.awt.Robot - it would be even better if the API offered this functionality itself (like Mouse.setCursorPosition. For example OpenGL unit tests work fine without a Display and only a Pbuffer).

Isn't it possible to capture the keyboard state without a window or by creating a hidden one when Keyboard.create() is called and no display was created before. I guess a Keyboard.update() would be needed along.


Thanks for explanations and answering,
Micha

[honktronic]

I'm having a similar problem on Mac OX 10.6+ where Keyboard.KEY_GRAVE doesn't register (in fact it registers as KEY_NONE...wtf?!). The other keys I'm using for user input work just fine. It registers just fine on Windows 7 and Ubuntu.

While I was testing, I also found that the apostrophe/quote key registered as KEY_NONE. My Linux machine registers the bar/backslash key and the Windows/Start key as KEY_NONE as well.

Anybody else run into this sort of problem?

[princec]

wrt. key names - See KEY_PREV and KEY_NEXT. They're not necessarily labelled in the same way as on the actual keys.

wrt. unit tests - if you are involving keyboard input, or even simulating keyboard input, you're not writing unit tests, or at best you're writing unit tests that won't be testing anything useful.

Cas