| Top | |
|
|
|
On some platforms, Glk can recognize when the mouse (or other pointer) is used to select a spot in a window. You can request mouse input only in text grid windows and graphics windows.
A window can have mouse input and character/line input pending at the same time.
If the player clicks in a window which has a mouse input event pending,
glk_select() will return an event whose type is evtype_MouseInput. Again,
once this happens, the request is complete, and you must request another if
you want further mouse input.
In the event structure, win
tells what window the event came from.
In a text grid window, the val1
and val2
fields are the x and y coordinates
of the character that was clicked on.
So val1 is the column, and val2 is the row.
The top leftmost character is considered to be (0,0).
In a graphics window, they are the x and y coordinates of the pixel that was clicked on. Again, the top left corner of the window is (0,0).
Most mouse-based idioms define standard functions for mouse hits in text windows — typically selecting or copying text. It is up to the library to separate this from Glk mouse input. The library may choose to select text when it is clicked normally, and cause Glk mouse events when text is control-clicked. Or the other way around. Or it may be the difference between clicking and double-clicking. Or the library may reserve a particular mouse button, on a multi-button mouse. It may even specify a keyboard key to be the "mouse button", referring to wherever the mouse cursor is when the key is hit. Or some even more esoteric positioning system. You need only know that the user can do it, or not.
However, since different platforms will handle this issue differently, you should be careful how you instruct the player in your program. Do not tell the player to “double-click”, “right-click”, or “control-click” in a window. The preferred term is “to touch the window”, or a spot in the window.
Goofy, but preferred.