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