nanogui: gdk port and nano-X
Subject:
Re: gdk port and nano-X
From:
Morten Rolland ####@####.####
Date:
31 Mar 2000 07:57:00 -0000
Message-Id: <38E46609.EC30E174@screenmedia.no>
Paolo Molaro wrote:
>
> > : 7) problems separating event-handling from the internals
> >
> > We need more input on this.
>
> Not everyone uses select() to check for input available on the
> socket and it's not safe the way events are stored now (you need
> a list, not a single storedevent to make it right).
[You say that you don't use select; my comment is based on
the select method to illustrate why there is a single stored
event now.]
Is this for the server or the client? For the client, you didn't
originally need any storage at all, because the client would
ask the server "is there an event for me" and fetch them
from the server one at a time. Very synchronous operation that
didn't work well with select, which is a must.
With the advent of the GrPrepareSelect/GrServiceSelect functions,
a single event storage is needed on the client:
1) GrPrepareSelect sends a message to the server:
"Send me a single event, but only when you got one!"
2) client sleeps on select
3) client wakes up (for some reason) and calls
GrServiceSelect
4a) If there is data from the server, it is an event and
it is processed.
4b) If there is no data from the server, but some drawing
has to be done that includes returning *any* data to
the client, then we might run into trouble:
4c) * We send a request to the server and awaits the reply
* The server wakes up because of a mouse move and
ships the event to the application (because of our
request in 1) and then processes the request in 4b.
* The client is waiting for the response to its request
but receives an event!
This event needs to be stored, but no more. The server will
only send the single one, until a new GrPrepareSelect is
called or an explicit poll is made.
Now, this is the theory... There are problems in this area right
now and I'm looking into it. The above facts will be used for
guidance, though, so no more than a single event should never
have to to be queued on the client today.
If you have code-traces or code that proves otherwise, I'd like
to hear about it!
Regards,
Morten Rolland, Screen Media
