Hi !
> 1. Mouse is a human input device, as well as others pointing device.
> Practically buttons are related to mouse position and usual human expects
> reasonable button action right in place where he has clicked it.
Yes. This however does not mean, that the driver producing the "clicks" has
to know anything about the driver producing the moves.
This is why the moves and clicks are separate. Please note, that it is
possible to mix relative and absolute pointer events. A simple example of
that would be keyboard emulated mouse (which only makes sense as relative
events) on a absolute-mouse target like X.
> What have we do with GII. Something like that collecting:
> pmove1 abs
> pbutton
> pmove2 abs
> will do
> (pmove1.x +pmove2.x)/2 and the same for y.
??? What ?
I'll sketch how a LibGGI mouse handling routine for a system that expects to
work with absolute coordinates is intended to look like:
{
static int mousex,mousey;
...
ggiEventPoll(vis, emKey|emPointer, NULL);
events = ggiEventsQueued(vis, emKey|emPointer);
while (events--) {
ggiEventRead(vis, &event, emKey|emPointer);
switch(event.any.type) {
case evPtrButtonPress:
switch(event.pbutton.button) {
case GII_PBUTTON_FIRST:
do_something_as_appropriate(mousex,mousey);
break;
case GII_PBUTTON_SECOND:
...
}
break;
case evPtrButtonRelease:
... if needed ...
break;
case evPtrAbsolute:
mousex = event.pmove.x;
mousey = event.pmove.y;
break;
case evPtrRelative:
mousex += event.pmove.x;
mousey += event.pmove.y;
break;
}
/* Constrain mouse in any case */
if (mousex < 0) mousex = 0;
if (mousey < 0) mousey = 0;
if (mousex > xmax) mousex = xmax;
if (mousey > ymax) mousey = ymax;
} /* while */
}
As you can see, this nicely symmetriyes the cases of abs and rel events.
Basically the same can be done for apps that expect relative events, though
those might get trouble on absolute input data when trying to "keep turning
left" or similar.
> Was it good? It is no good, at least because gii client software is not
> right place to do it.
To do what ? (pmove1.x +pmove2.x)/2 ? There is no reasonable place to do
such a calculation at all. To make sense at all, you would have to make a
weighted mean based on the time between the individual event's timestamps.
There is no assumption of something like a linear motion between points
between move events, and for sure no assumption, that the click happens in
the middle of that.
The expected behaviour is, that the above used mousex,mousey variables
express the correct position of the pointer, when a click comes in.
If the mouse was moved between the last move and the click, the driver is
expected to send another move and then the click to correctly position the
pointer before transmitting the click.
> Why do I need to keep every pmove message until get
> pbutton and pmove again? That is not pretty at least.
You don't. See above. In case that delivers incorrect results, we have a bug
in a driver or backend and need to fix the driver or flame the backend
authors.
> I understand that it is my task to determinate correct click place in case
> of relative move messages and I do. But I really hope I will be able to
> avoid mouse cursor software emulation(what I have done because of no choice)
> and to forget about relative messages for pointing device like mouse in the
> future when GGI will take care about hardware cursor.
GGI will never take away the information you get from the input device.
While we may provide a method to place a hardware sprite on the display,
thus allowing to easily make up a mouse pointer, this will not influence
the pointer data sent from the input device.
> I repeat ones more I am discussing only about the case when cursor
> generation is not my task.
I still do not get what cursor generation has to do with input handling.
There are some applications that would be pretty unhappy, if we converted
all input to absolute pointer events. Guess why the X target has the
relmouse mode ...
> In the depth My question was why after calling poll(I call it with 0 time
> delay) the queued function shows only one message we have inside of
> queue but actually there are many (inside of some internal buffers).
If that is the case, this is a bug and should be fixed.
> I think poll function really poll only one message for each message type
> per one call, does not it?
No. It should check and queue all attached inputs, and all inputs should
read their sources until they are drained.
> It seems a strange for me behavior like that I expected that after Poll funk
> Queued will report all messages from internal buffers.
Yes. This is the intended behaviour.
However it could well be, that it is not correctly implemented in all
targets. If you could send some code that clearly shows the problem together
with the inputs that exhibit the problem, that should help to fix it.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
