Hi
Ok,
1. Anyway that is no so big problem if you do not want to keep space data
together with buttons.
As I got from you message you can guaranty last pmove message(s) contains
right data for the determination of pointer position in the time of
clicking. It's more than enough. By the way my code is looks like the same
of yours except I avoid of calling 3rd party libraries directly and I use
own wrappers. My experience showed me that code for really good system has
to be not depended from any other library(thats funny when I see MFC
programmers who made software(and own brain) absolutely mot portable). I
make semi-embedded software like navigational systems, marine simulators.
Ask me how many libraries graphics libraries and input system I changed for
the last 10 years? A lot of. Know I can just make one more wrapper over
existing libraries and keep my other code just untouchable.
Absent of space data and click data made me a little confused because GGI is
the first library I have seen making this dividing :)
2. Event generation has not so many to do with cursor generation. But If GGI
library do not provide cursor monitoring and generation of it the GGI users
have to do this job manually. IMHO it will be nice for many users of really
nice GGI, if GGI will work together with GII to provide mouse cursor
monitoring when GGI will get hardware cursor access.
3. Marcus already gave some explanation for the Poll. Thanks. May be letter
it will good to show my code as one more gui development system using GGI.
Best regards, Dmitry
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 22, 1999 3:05 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
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]>
=
