Dear Marcus
>>Well, this is only a problem for broken or really strange apps, but
>>I think we should still provide a way around it:
This is of semantic problem. IMHO When I call something like Poll at first
and GetQueued I expect (very deep inside of my mind) to get all events
"already" buffered by an input library. As I told it was not a problem. It
seemed strange to me behavior like that because it is different from
expected by me.
Of course software uses only GII buffering will never understand this
problem. But Any software uses own buffering immediately get it. You can ask
me why do I need to use own buffer? Let se some my explanation provided to
Andreas under topic 1.
Thanks
Dmitry
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marcus
Sundberg
Sent: Friday, October 22, 1999 8:19 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Andreas Beck wrote:
> > 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.
Well, this is only a problem for broken or really strange apps, but
I think we should still provide a way around it:
Let gq be the number of events queued in LibGII and kq be the number
of events queued in the kernel.
Initial state: gq = 0, kq = 3
giiEventPoll() is called ==> fetches all events ==> gq = 3; kq = 0;
giiEventRead() is called, but only twice ==> gq = 1; kq = 0;
Now the user moves the mouse arround ==> gq = 1; kq = 5;
giiEventPoll() is called ==> as gq > 0 no events are fetched from kq
into gq. This is 100% correct due to performance reasons, BUT:
When giiEventsQueued() is called and returns the number of events in
the queue you get 1 allthough there are more events that could be
read.
My suggestion is that we add a new function
int giiQueuedAfterPoll(struct gii_input *inp, gii_event_mask mask);
which will first poll all relevant input sources, regardless of the
number of events queued, and then return the number of events available.
When I think of it we should definitely add this function, because
it will allow the following common code:
struct timeval tv = { 0, 0};
if (giiEventPoll(inp, mask, &tv)) {
n = giiEventsQueued(inp, mask);
while (n--) {
giiEventRead(inp, &ev, mask);
process_event(%ev);
}
}
to be replaced with:
n = giiQueuedAfterPoll(inp, mask);
while (n--) {
giiEventRead(inp, &ev, mask);
process_event(%ev);
}
Unless there are any objections or suggestions for a better name
I'll add this function to LibGII (and it's companion in LibGGI).
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
