[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