Doubleclick handling for <select> tag (#71427)

[Rob Buis]

Hi Germain,

On Mon, Oct 04, 2004 at 10:28:37AM +0100, Germain Garand wrote:
> Le Dimanche 03 Octobre 2004 21:41, rwlbuis at xs4all.nl a ?crit :
> oh, sorry! my tree was really dirty. Attached one should apply cleanly.

Thnx :)
 
> > > (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.

Wow, quite complex. I'll study that code some more... 

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

Well, I have to let the patch be for a while I think, since I am going to 
.nz (work) until 19th. I'll have some internet access to read mails, so I 
can comment on any patches though, but not test them.
In the meantime, could you or someone else have a look at #41505? It would 
be sweet to have another patch in before I leave ;)
Cheers,

Rob.