Difference between revisions of "Where to store the state info (e.g., previous position) between mouse events?"
(Created page with 'Discussion from #introduction with khuey <pre> 20:40 <@humph> evening 20:41 <@humph> any content/dom folks about? 20:41 <@humph> I need to bounce some ideas off someone 20:43 < …') |
|||
Line 62: | Line 62: | ||
20:56 < khuey> sure, np | 20:56 < khuey> sure, np | ||
</pre> | </pre> | ||
+ | |||
+ | My current thinking, confirmed by my conversation with Kyle, is to store the x/y state on nsEventStateManager, and to pass it up with the event by extending nsEvent with prevRefPoint, to match its current refPoint member. A logical place to do this might be in nsEventStateManager::GenerateMouseEnterExit. I've emailed smaug for his thoughts before I make these changes. |
Latest revision as of 23:00, 19 November 2011
Discussion from #introduction with khuey
20:40 <@humph> evening 20:41 <@humph> any content/dom folks about? 20:41 <@humph> I need to bounce some ideas off someone 20:43 < khuey> sure 20:43 <@humph> hey 20:43 <@humph> so here's my issue 20:43 <@humph> working on mouselock, and I need to keep track of some state between mouse events 20:44 <@humph> basically, screenX/Y for this event - screenX/Y from last event is my delta 20:44 -!- knaszradi [knaszradi@6D77304.CB647380.581B62B0.IP] has joined #introduction 20:44 <@humph> the screenX stuff works like this http://zenit.senecac.on.ca/wiki/index.php/Stack_Trace_for_nsDOMMouseEvent::GetScreenX 20:44 <@humph> I'm trying to figure out where to stick my state between events 20:45 < khuey> mmm 20:45 < khuey> good question 20:45 < khuey> how doe "mouselock" work? 20:45 <@humph> for purposes of what we're discussing here 20:46 <@humph> you have two new things on nsIDOMMouseEvent 20:46 <@humph> movementX and movementY 20:46 -!- jking [jking@9DCF6B6E.4B6AD646.67AC9B1.IP] has quit [Ping timeout] 20:46 <@humph> and this is a delta of screenX and screenY 20:46 -!- knaszradi [knaszradi@6D77304.CB647380.581B62B0.IP] has quit [Quit: knaszradi] 20:46 <@humph> since last movement 20:46 <@humph> so I'm thinking I have to put this state on something as I'm building the dom/ui event 20:47 <@humph> such that I can reach down from the nsDOMMouseEvent and get it (or else pass it into it when I init) 20:47 <@humph> I'm struggling to find a perfect shelf for this, as it were 20:47 < khuey> so, the right place is probably nsEventStateManager 20:47 <@humph> I wondered this 20:47 <@humph> leave it on there as the event is being created? 20:47 < khuey> it stores things like http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventStateManager.h#506 20:48 < khuey> right 20:48 <@humph> yes, this looks right 20:48 < khuey> not sure exactly where the right place to set things is 20:49 <@humph> how do I get back to it from within nsDOMMouseEvent 20:49 <@humph> well, I can just bang it in for now to explore 20:49 < khuey> maybe nsEventStateManager::CheckForAndDispatchClick 20:49 <@humph> http://zenit.senecac.on.ca/wiki/index.php/Stack_Trace_for_nsDOMMouseEvent::nsDOMMouseEvent_ctor 20:50 <@humph> but it will have various paths depending on the type of event 20:50 <@humph> that's the general path 20:50 < khuey> mmm, yeah, that's a synthetic event click 20:50 < khuey> that's actually not the general path 20:50 <@humph> no? 20:51 < khuey> no, that's the path that's taken when we synthesize a click cause reflow or js or whatever changed what's actually under the cursor 20:51 <@humph> I see 20:51 <@humph> I see what you mean in PresShell 20:52 < khuey> so, the other fun bit is that nsEventStateManagers are per presContext 20:52 < khuey> so each document has a different one 20:52 < khuey> that may or may not be a problem for you 20:53 <@humph> that will work, since you can't hold a lock on multiple docs at once 20:53 < khuey> ok 20:53 <@humph> only one element can be locked 20:53 <@humph> so it's not a click, but a mousemove I need to deal with 20:54 <@humph> well, actually, I guess it's any mouse event 20:54 <@humph> anything that will expose a MouseEvent 20:54 < khuey> ah, right 20:54 <@humph> maybe in DispatchMouseEvent I can grab the refPoint 20:55 < khuey> so I think those all go through nsESM::GenerateMouseEnterExit 20:55 < khuey> but I'm not certain 20:56 <@humph> ok, I'll poke 20:56 <@humph> this has been helpful, thanks 20:56 < khuey> sure, np
My current thinking, confirmed by my conversation with Kyle, is to store the x/y state on nsEventStateManager, and to pass it up with the event by extending nsEvent with prevRefPoint, to match its current refPoint member. A logical place to do this might be in nsEventStateManager::GenerateMouseEnterExit. I've emailed smaug for his thoughts before I make these changes.