Re: [Freekode-public] Events

[Guilherme S. <gui...@gm...>]

I=B9m working on the event system for mac.
Until now, I have only used Mac functions on three kdFunctions: kdWaitEvent=
,
kdPostEvent and kdPumpEvents (not yet implemented).

One thing I think can be shared by all systems, is the event callback
module.
If we have a function that returns the callback for a given KD_EVENT id, it
would be great :)


By the way. How do you plan to translate the SO events into KD events?
For now, I=B9m using a mega-switch, that translates MAC_EVENT_ID into
KD_EVENT_ID.
I would prefer something more =B3advanced=B2...


Another important subject about events, that I have already discuss with
fozi but not with you, guys.
What is supposed to happen to events sent by the OS that KD doesn=B9t specify=
?

I suggested that we should extend the struct Kdevent (as predicted by the K=
D
specification) to store a void* pointer to the OS event data.
This way we let the user decide what to do.
If he doesn=B9t want to treat specific OS events, he calls the DefaultEvent
function as usual and moves on.
If he wants to be an hero, he can convert to the correct data struct and
treat the event as he want.

For this to work we have to create a new KD_EVENT_ID, such as, FK_EVENT_OS
or something.

What do you think?


Guilherme Santos


On 9/20/07 12:22 AM, "Diogo Teixeira" <fo...@gm...> wrote:

> Let's get the event handling discussion started.
>=20
> -----
>=20
> After some debate we ended up with two options on the table regarding the
> event system implementation.
>=20
> 1) The first one is straightforward, it involves a global event queue. Th=
e
> system and input events are
> captured by a platform event handler and posted to the global queue using
> kdPostEvent. In this case we
> would have to do our own callback handling which would probably require
> another container.
>=20
> 2) An alternative implementation is to use the event system and callback
> handler provided by the operating
> system. In Mac and Windows this implementation would be very straightforw=
ard
> as both are thread safe and
> support events and callbacks. However, this might not be true for all
> platforms so the first implementation
> might still be required as a fall back.
>=20
> Unless we have more options, I think we have no choice but to implement t=
he
> first one. Once it's done,
> supporting new platforms becomes almost trivial.
> The second option, however, might still be useful by saving us  some reso=
urces
> and processing on some
> platforms.
>=20
> Fire away.
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>=20
> _______________________________________________
> Freekode-public mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freekode-public