Re: Event handling with nested containers

OK, so the only reason the widgets work at the moment is because they
are all children of a state (which is located at 0,0).  So we do need to
translate the mouse event, but since there is already a
delegate_mouse_event routine, why not just use it and modify the x,y
point it contains by subtracting the x,y postion of the object passing
it along (the container).  It seems logical that widgets should work
entirely in local coordinates.

Marc, I think is the same as your first proposed solution, but just
updating an existing method, rather than writing a new one.

Darren

On Thu, 2003-09-11 at 01:45, Darren Vincent Hart wrote:
> 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
>=20
> Please note, we all agreed on it, I just happened to implement it!  *g*
>=20
> > 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
>=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?
>=20
> > 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 hi=
s=20
> > active child. This seems really ugly, doesnt it?
>=20
> 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)
>=20
> > 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 i=
t=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 use=
r=20
> > 's interaction.
> >=20
>=20
> Not that I can think of.
>=20
> Darren
>=20
> >=20
> >=20
> > _______________________________________________
> > Libstk mailing list
> > [email protected]
> > http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk
>=20
>=20
> _______________________________________________
> Libstk mailing list
> [email protected]
> http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk