[Webkit-unassigned] [Bug 31115] [Qt] QWebFrame::setHtml() should be removed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=31115


Jędrzej Nowacki <jedrzej.nowacki at nokia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|webkit-unassigned at lists.web |jedrzej.nowacki at nokia.com
                   |kit.org                     |
  Attachment #43851|                            |review?, commit-queue?
               Flag|                            |




--- Comment #3 from Jędrzej Nowacki <jedrzej.nowacki at nokia.com>  2009-11-25 09:11:10 PST ---
Created an attachment (id=43851)
 --> (https://bugs.webkit.org/attachment.cgi?id=43851)
documentation change v1

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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.