Re: Event handling with nested containers

On Thu, 2003-09-11 at 01:19, Marc Str=C3=A4mke wrote:
> Hi team ,
> We might run into some big trouble with our current solution of event=20
> handling. One of the recent changes of darren made widget's screen=20
> coordinates relative to their parent's,=20

Please note, we all agreed on it, I just happened to implement it!  *g*

> this means that a widget cannot=20
> determine where it lives on the screen, but when handling pointer=20
> events, it has to do exactly this!=20

The widget's at the moment all work fine with relative coordinate
positions (see spinner where the up and down arrow regions are used),
what situation do you see where this is insufficient?

> My current proposal for this would be=20
> to create a method pass_event_downwards in stk::event_handler so that=20
> each container my offset the mouse coordinates and give the event to his=20
> active child. This seems really ugly, doesnt it?

Marc, there is already a delegate_mouse_event in widget and container
that passes the event downward, let's just make it more generic
(delegate_event) and use that rather than creating another method.
(if its necessary at all that is)

> In my source tree i've implemented  a function in container stk::point=20
> get_screen_position that recursively calls itself on the parent until it=20
> reaches state, so the widget can get the screen position of its parent.
> Please give me some feedback which method you like or dislike, i'll=20
> commit the one chosen then (this affects all handle event functions of=20
> all widget b t w *g*)
>=20
> BTW: Is there any reason for drawing before checking the event sources=20
> in the mainloop? This gives us a few jitties worse response time to user=20
> 's interaction.
>=20

Not that I can think of.

Darren

>=20
>=20
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk