[bt-devel] Next: 2.0beta3? Or RC1? - Mag window issue

Gary Holmlund gary.holmlund at gmail.com
Wed May 13 21:58:34 MST 2009


Eeli Kaikkonen wrote:
> Gary Holmlund wrote:
>
>>
>> Perhaps the combination of debug code and running javascript to 
>> set/clear the timer is the cause of the issue. It is  rather hard to 
>> pin down timing issues like this.
>
> We should fix it anyways, because it may bite use later. The code is 
> quite complicated nowadays because there is jscript and the old 
> timer/mousemove code has moved to a non-widget class. Additionally 
> it's not properly commented, it has old comments like "see 
> timerEvent()" while there's no timerEvent in that class anymore. I 
> hope you could refactor the comments and comment the code so that the 
> flow could be followed.
>
> I think the problem is that the location of the cursor isn't check 
> when the timer is triggered.
>
> The old timer event in chtmlreaddisplay.cpp worked like this:
>
> DOM::Node currentNode = nodeUnderMouse();
> // Process the node under cursor if it is the same as at the start of 
> the timer
> if (!currentNode.isNull() && (currentNode != m_previousEventNode) && 
> this->view()->underMouse()) {
> ...
>
> So there were two things checked: that the mouse is over a node, and 
> that the mouse is over this window (though I wonder how it can be 
> "currentNode !=", unless it's a bug). I take it for granted that these 
> should be checked with the new system, too.
>
> Can you take this task?
>
> --Eeli Kaikkonen
I will look into the further. I  realize that the flow is harder to 
follow since there are 2 C++ classes and javascript to implement this 
feature. I think that you know that structuring it into the 3 areas was 
a requirement from Qt to be able to use the javascript with QtWebkit. I 
certainly would not have done it this way if there was a simpler 
approach. I will see what I can do to document the flow better.

Gary



More information about the bt-devel mailing list