Hi
Thanks for your reply
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. 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.
Was it good? It is no good, at least because gii client software is not
right place to do it. Why do I need to keep every pmove message until get
pbutton and pmove again? That is not pretty at least.
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.
Also I do not see any problem with "Using the mapper filters, you can push
"mouse buttons" on the keyboard and vice versa ..."
For example Button can be the "reset button" on the computer instead of left
or middle mouse button, but if human thinks that that one has functionality
related to the mouse cursor it should be and We have to have xyz closure to
the click place inside of point device driver. I repeat ones more I am
discussing only about the case when cursor generation is not my task.
2. Please refer my old mail. I already found the way how to live together
with poll, and read functions :) 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). I think poll function really poll only one message
for each message type per one call, does not it?
Using of gii like this:
poll
n=queued
while(n--) read
is bad in case of i have some internal buffers and some other cases.
Actually I have to do following code to have all last messages
n=0;
do
{
while(n--) read;
poll()
}
while (n=queued);
It seems a strange for me behavior like that I expected that after Poll funk
Queued will report all messages from internal buffers.
Best regards, Dmitry Semenov
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 21, 1999 18:02
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Hi !
> 1. Why GII gii_event.pbutton does not have cursor coordinate information
Because the buttons and the pointer position are not related in any way
theoretically. Using the mapper filters, you can push "mouse buttons" on
the keyboard and vice versa ...
> in case of GII buffering and sending data which have absolute cursor
> position (x target and may be future fb target with hardware cursor).
? I don't get you here. What has absoluet cursor position to do with buttons
?
> 2. Why GII does not use button data in case of sending pmove event?
Same reason, see above.
> 3. I found some strange behavior inside of GII.
> -I poll GII one time
> -I read all events queued inside GII in my internal buffer with keeping
> only one pmove message inside of my buffer
> -I read one message from my buffer.
> -I move my cursor in case of pmove data
> -I call ggUSleep(10);
> -I see funny effect on the screen:
> my cursor making always is to late :) It looks like GII buffer can not
> give me back all messages by one polling.
>
> if I do poll and read queued messages like this:
>
> while(Poll()); instead of one polling
> where Poll is something like this [... snip ...]
> I've found no problem with my cursor.
Hmm - I get you right, that gii events are kept queued inside gii when you
try to read them - right ?
Well, there is a possible simple explanation:
ggiPoll unblocks _as_soon_as_ one of the associated FDs gets readable. Now,
if the Mouse e.g. first sends a Pointer-update-packet or similar, this gets
read into LibGGI immediately during the poll. The poll then unblocks, as
data
is available. At that point, there is only the first sent event from the
mouse available. The mouse keeps sending data, but the LibGII poll routine
has already terminated, as it terminates as soon as the first event gets
readable.
For such situations, where this behaviour is undesireable, as there are long
delays between frames, it might make sense to use something like
while(ggiPoll())
do_the_evenht_reading();
eventually_wait_a_short_grace_time();
}
This allows for "slow" devices that do not instantaneously deliver all data.
What mouse do you have ? we might want to check the driver, if it does the
expected thing, which is to loop in its poll handler as long as data is
incoming.
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
