Doubleclick handling for <select> tag (#71427)

[Germain Garand]

Le Dimanche 03 Octobre 2004 21:41, rwlbuis at xs4all.nl a écrit :
> 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 :)

oh, sorry! my tree was really dirty. Attached one should apply cleanly.

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

the trick is that KHTMLView is doubly-buffered: when it paints itself, it 
doesn't paint directly on the view but on 128px bands, that are then copied 
in one go (KHTMLView::drawContents).

On the other hand, normal widgets that are added to the view have their own 
economy: when they are dirtied or otherwise obscured, they are sent Paint 
events directly and draw themselves all alone, out of sync.

This doesn't work well when we want to stack our RenderObjects with widgets.
So to get proper stacking, we installed event filters on a selected subset of 
widgets (hackishly named "__khtml"), so that their paint events are 
translated to Paint events on the KHTMLView, which we handle normally in the 
Render tree's paint() routines (themselves properly ordered stacking-wise by 
RenderLayer before hand).

Now, when we arrive in RenderWidget::paintWidgets, we need to paint relevant 
parts of __khtml widgets to our opened QPainter, which is not tied to the 
view, but to our 128 px buffer.
So we need to "copy" the actual widget to this buffer by sending it a Paint 
event directly after redirecting its output.
This process didn't work very well for QScrollViews and other external widgets 
so those where left aside and still painted themselves all alone.

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

OK. I'll happily provide patch testing :)

BTW, if the attached introduce any problem with select or if you don't want to 
care about painting (hey, stacking wasn't working with listviews anyway), 
please just go head with your patch and I'll try to add my stuff afterward 
without breaking anything. I've got the feeling I'm getting invasive :)

Greetings,
Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: widget_painting2.diff
Type: text/x-diff
Size: 15118 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041004/be5c9b13/attachment.diff>