[webkit-qt] Extending the hybrid support of QtWebkit to more types: feedback please!

Simon Hausmann simon.hausmann at nokia.com
Sun Dec 13 02:18:50 PST 2009


On Sunday 13 December 2009 02:00:33 am Rosenthal Noam (Nokia-D-Qt/RedwoodCity) 
wrote:
[...]
> Alternatives:
> - Use something like a new QWebElement::pixmap() / QWebElement::setPixmap()
>  function - Use a source-string mechanism, something like <img
>  src="qpixmap://1acd0339" />, and have the QtWebkit image decoders to
>  handle that somehow (this would probably require a much bigger fix than my
>  patch). - Wait till #31863 is fixed, and find a way to do it then: the
>  solution would probably look a lot like the proposed patch, as eventually
>  the feature of converting an HTMLImageElement to Qpixmap would have to
>  happen somewhere:)

Ideally we can find a solution that we can implement now but that we know 
_will_ be compatible with #31863.

On second thought I _think_ the resulting API should not be a direct 
conversion from QImage/QPixmap to HTMLImageElement, as they are not 
equivalent. The latter has a lot more attributes to specific that are not part 
of QPixmap/QImage.

In fact this reminds me very much of the problem of using generated content as 
backgrounds and for images:

	http://webkit.org/blog/175/introducing-css-gradients/

Alternatively, would it make sense to put this into the Canvas API?

Either way I would like to find an _explicit_ API that we can document, which 
might mean extending one of the .idl files.

Simon


More information about the webkit-qt mailing list