Doubleclick handling for <select> tag (#71427)

[rwlbuis at xs4all.nl]

Hi Germain,

> 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.

 Thanks, I didnt realize this...

> 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.

I can't apply the patch :( I just did patch -p 0 < patchfile but
it did not work. If I must I can add the changes by hand, but I'd rather
not :)

> (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)

Thnx, this really shows the problem. So your patch can handle it? What is
the trick here, I did not delve that deep into khtml to learn about
zindexes so far, though I think I'll study the code more in future...

>> 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?

Well, I assume the specs just "demand" it, though I have not really seen
real-life cases, I am just judging from how mozilla handles it.

> 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.

Again, sorry, but I couldnt check because of the patch not applying.
Cheers,

Rob.