[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