It is worth a try if the BC pans out to be true. It would be nice to see some real life use-cases and how these are solves with this new API (or extensions thereof) before actually going for it.
Will it be possible to split next nodes on the DOM, for instance if you want to do pagination with WebKit (a use-case that once came up writing an epub reader on top of QtWebKit)? Kenneth On Tue, Mar 1, 2011 at 8:50 PM, Benjamin Poulain <[email protected]> wrote: > Hello, > > Andreas and I were talking about the recuring problem of QWebElement being > too simple to handle use cases with text. > > We were thinking about what kind of simple change would get us out of those > problems (text wrapping, selections, text + element as children, etc). > > > Given the following changes, anyone has comments?: > > class QWebNode { > enum Type { Element, Text }; > Type type() const; > QWebElement parent() const; > QWebElement document() const; > QWebNode nextSibling() const; > QWebNode previousSibling() const; > QString toPlainText() const; > } > > class QWebElement: public QWebNode { > } > So we could play with QWebNode of type Text for text. > > (Yep, I think that is BC to change the parent class in this case :)) > > > cheers, > Benjamin, > _______________________________________________ > webkit-qt mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt > -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
