[webkit-reviews] review requested: [Bug 31115] [Qt] QWebFrame::setHtml() should be removed : [Attachment 43851] documentation change v1

[bugzilla-daemon at webkit.org]

Jędrzej Nowacki <jedrzej.nowacki at nokia.com> has asked  for review:
Bug 31115: [Qt] QWebFrame::setHtml() should be removed
https://bugs.webkit.org/show_bug.cgi?id=31115

Attachment 43851: documentation change v1
https://bugs.webkit.org/attachment.cgi?id=43851&action=review

------- Additional Comments from Jędrzej Nowacki <jedrzej.nowacki at nokia.com>
(In reply to comment #2)
> * The function is consistent with the rest of Qt (QTextEdit::setHtml,
> QTextDocument::setHtml, QGraphicsTextItem::setHtml). Qt developers love the
> fact that our API is consistent.
This is nice point :-), but on the other hand classes mentioned by you are much
simpler (implementation & functionality). I think it's clear that you shouldn't
put SVG into the QTextEdit, but for the QWebPage it is not so obvious. Moreover
Qt had to be not only simple, but should "force" right application design. As
setHtml is a nice shortcut, I don't think that it must be used on the first
place. Developers need to know what actually they want to process (SVG, HTML,
XHTML...).

> * setHtml() is also very convenient. We say that with the Qt API common
things
> should be easy and special tasks should be possible. Populating a widget to
> render web content with a given string of HTML falls clearly into the former
> category.
Yes it should be, but as we don't provide unified access for XHTML and HTML it
is a source of problems.

> * To satisfy the use-case of a more advanced task we added setContent(),
which
> is harder to use but also more flexible.
So I prepared a little patch for it. I don't think, we should close the
discussion.