[bt-devel] Unwanted drags by KHTMLPart

[Martin Gruner]

Thanks for investigating this tedious matter, Eeli! :D

mg

On Saturday 22 November 2008 11:06:24 Eeli Kaikkonen wrote:
> Months ago I found a nasty bug: if I start dragging a verse number from
> a display view, drag it to somewhere where it's not accepted, release
> the mouse and move mouse back to the display view, there will
> mysteriously be a new drag which includes our sword:// link but is not
> the same than the drag created by our code. This could even crash BT
> sometimes if I then moved the drag (which stays there even when the
> mouse button has been released) to an empty toolbar area.
>
> Finally, after hours of work, I found the reason: KHTMLPart creates URL
> drags automatically in its own khtmlMouseMoveEvent. We have to call it
> because it handles selection for us. Needless to say, it's not
> documented and I had to read the KDE code to find it out. I couldn't
> find a way to prevent this, other than an ugly hack: I temporarily
> changed the drag delay to some large int. Maybe it could be possible to
> give KHTMLPart::khtmlMouseMoveEvent() a new event, but it takes
> khtml::MouseMoveEvent which doesn't have public members other than the
> ctor, and I don't dare to touch it because I don't know what each
> argument means. So we are stuck with the ugly hack before we get rid of
> KHTML or someone finds out a better hack...
>
> I was working with dnd and bookmarks months ago but got depressed by
> this and some other difficulties. Now I must continue because those must
> be done before 1.7.
>
> --Eeli Kaikkonen
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel