Re: Event handling with nested containers

Darren Vincent Hart wrote:
> 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.

Basicly you're right, i forgot about delegate mouse event when i wrote 
it. I agree that the widgets should only handle local coordinates. 
Changing delegate mouse event seems appropiate, implementing that one now.

> 
> Darren
> 
> On Thu, 2003-09-11 at 01:45, Darren Vincent Hart wrote:
> 
>>On Thu, 2003-09-11 at 01:19, Marc Strämke wrote:
>>
>>>Hi team ,
>>>We might run into some big trouble with our current solution of event 
>>>handling. One of the recent changes of darren made widget's screen 
>>>coordinates relative to their parent's, 
>>
>>Please note, we all agreed on it, I just happened to implement it!  *g*
>>
>>
>>>this means that a widget cannot 
>>>determine where it lives on the screen, but when handling pointer 
>>>events, it has to do exactly this! 
>>
>>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 
>>>to create a method pass_event_downwards in stk::event_handler so that 
>>>each container my offset the mouse coordinates and give the event to his 
>>>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 
>>>get_screen_position that recursively calls itself on the parent until it 
>>>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 
>>>commit the one chosen then (this affects all handle event functions of 
>>>all widget b t w *g*)
>>>
>>>BTW: Is there any reason for drawing before checking the event sources 
>>>in the mainloop? This gives us a few jitties worse response time to user 
>>>'s interaction.
>>>
>>
>>Not that I can think of.
>>
>>Darren
>>
>>
>>>
>>>_______________________________________________
>>>Libstk mailing list
>>>Libstk@Óq«LD—"
>>>http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk
>>
>>
>>_______________________________________________
>>Libstk mailing list
>>Libstk@Óq«LD—"
>>http://www.dvhart.com/cgi-bin/mailman/listinfo/libst
> 
> k