Original bug report: http://bugreports.qt.nokia.com/browse/QTBUG-5525 toUpper and toLower This is a feature request, not a bug report. I've been building what I call a "RichTextEdit", aka a simple text editor built on top of an editable QWebView. Things like bold, underline, italic all work pretty well. I need one additional piece of functionality: toUpper and toLower. There is no built in support for such functionality in QWebKit, nor do I suggest there necessarily should be. But it would be nice if there was a way for me to implement it myself. This is what I do currently: void RichTextEdit::toUpperCase() { execCommand("insertHTML", selectedText().toUpper()); } void RichTextEdit::toLowerCase() { execCommand("insertHTML", selectedText().toLower()); } void RichTextEdit::execCommand(const QString &cmd, const QString &arg) { QWebFrame *frame = page()->mainFrame(); QString js = QString("document.execCommand(\"%1\", false, \"%2\")").arg(cmd).arg(arg); std::string str = js.toStdString(); frame->evaluateJavaScript(js); } Aka, I use the insertHTML function and simply replace the selected text. The problem with this is: 1) I'd like to preserve the selection and 2) I lose complex internal formatting within the selection. For example, if the text was <b>One</b> Two <b>Three</b> Four <b>Five</b> Add I select the entire thing and do a toUpper then the result is the entire text becomes bolded. If I could get at the HTML, do my modifications, and push that HTML back over the selected html, then I'd be a very happy camper. I suspect that would work if I simply had a function like QString QWebView::sectedHTML() and if the insertHTML javascript function provided a means to maintain the selection (aka select the insertion if we're doing a replace). If there is a way to improve my existing code without modifications to Qt I'd love to hear about it. :)
why QWebView? What about QGraphicsWebView, or QWebPage?
You're right, this should probably lie farther down the food chain in something like QWebPage. What is fundamental is also being able to set the selected html as well, thus I'm looking for something like QString QWebPage::selectedHTML() const; void QWebPage::setSelectedHTML(QString val); where the latter results in a web page with updated content and the updated portion still selected
Well, this is very similar to selectedText(), so I would say it should be both in QWebPage and QWebView, just like selectedText() currently. But yes, at least in QWebPage ;-) IMHO let's keep "setSelectedHTML" out of this wish (i.e. make a separate one for it), it sounds quite more involved, than a simple "get me the selection as HTML" when there's already a "get me the selection as plain text".
David, you make a good point. FYI, this is how I currently convert a selection portion to upper case. I replace the selected portion. Aka I have to refer to javascript's insertHTML command... QString text = m_webView->selectedText(); text = input.toUpper(); QWebFrame *frame = m_webView->page()->mainFrame(); QString js = QString("document.execCommand(\"%1\", false, \"%2\")").arg("insertHTML").arg(text); frame->evaluateJavaScript(js);
Sorry, that should be: QString text = m_webView->selectedText(); text = text.toUpper(); QString js = QString("document.execCommand(\"%1\", false, \"%2\")").arg("insertHTML").arg(text); QWebFrame *frame = m_webView->page()->mainFrame(); frame->evaluateJavaScript(js);
Created attachment 68755 [details] Proposed patch Added QWebView::selectedHtml() and QWebPage::selectedHtml() Returned markup originates from the current selection range.
Comment on attachment 68755 [details] Proposed patch LGTM
Comment on attachment 68755 [details] Proposed patch This needs API review before landing.
Just want to mention this here for the record. Already discussed it with Andreas on IRC, but I am not sure what the proper resolution should/would be: The call to Range::toHTML() used to obtain the selected text will result in the internal style information, which is not part of the actual page, being included in the html fragment that is returned. This might be appropriate if your intention is to paste the selection into a Rich text editing environment, but that cannot be assumed for this API. At least I do not think. There are use cases such as page validation or text to speech where is additionally and rather ugly inclusion is not a necessary welcome. Infact doing this issue was enough of a concern that someone put the following comments atop WebCore::createMarkup (WebCore/editing/markup.cpp), the function the Range::toHTML() function relies on to create the HTML representation: // FIXME: Shouldn't we omit style info when annotate == DoNotAnnotateForInterchange? // FIXME: At least, annotation and style info should probably not be included in range.markupString()
Attachment 68755 [details] was posted by a committer and has review+, assigning to Andreas Kling for commit.
What's left to be done here?
Committed r75242: <http://trac.webkit.org/changeset/75242>