Doubleclick handling for <select> tag (#71427)
Germain Garand
germain at ebooksfrance.org
Sun Oct 3 07:55:26 BST 2004
Le Samedi 02 Octobre 2004 21:19, rwlbuis at xs4all.nl a écrit :
> Right. Well David and SadEagle gave me a few pointers, and I patched
> khtml enough so for the KListBox the painting and mouse events seem
> to be handled correctly now, and in the same way as for any other widget,
> i.e. it is handled in KHTMLView::eventFilter like for other render
> widgets. In fact paint and some key events are untouched, while mouse
> events are handled and not given back to the KListBox event handler, but
> they reach it anyway using the dom event mechanism.
ah good... :)
mmh, I don't know if there's any gain for keypress/release events to go
through the DOM for this widget, but at least for Paint events you lose the
main benefit of __khtml widgets (ie: proper z-index support). Also if you
don't modify RenderWidget::paintWidget accordingly, they would be painted
twice.
If you want to check, attached is my work on widget painting optimization,
that makes both textarea and lisbox full __khtml widgets, including painting.
Maybe you could test how it fares with regard to event handling?
I didn't investigated much that part.
(for z-index, see a good testcase for listbox here:
http://gcc.gnu.org/bugzilla/query.cgi?help=1 => help pop-ups.
See also attached testcase for textarea and some others)
> Now from my pov this seems pretty nice, but I still wonder about some
> things. First whether there are any scenarios, ie. other events that need
> testing for the KListBox case? Since I check for QScrollView derivatives,
> are there any widgets that get affected by the new code?
For keys and mouse events, it looks fine.
> And finally
> mozilla also seems to handle events on the options in the select, I think
> khtml should do that too, but I have not started on implementing that yet.
>
I'm afraid I can't comment much on that. Are there added benefits?
> > I still have some oddities of event handling and refresh upon scrolling
> > with
> > those, but I'll post the code soon... maybe someone will be able to help
> > resolving the remaining issues.
>
> I think there is a good chance of that :)
So here it is...
In the meantime, I could solve the refresh upon scrolling problem.
As for key/mouse handling, it looks like it works nicely, but I didn't tested
extensively.
Only problem is what looks like a race condition in QTextEdit, that makes it
crash when deleting the las two empty lines of an otherwise empty textarea
using Backspace.
Greetings,
Germain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041003/945dede6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: widget_painting.diff
Type: text/x-diff
Size: 15121 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041003/945dede6/attachment.diff>
More information about the kfm-devel
mailing list