| Trolltech Home | Qt4-preview-feedback Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi,
I've just downloaded a 4.4 snapshot and played around with QtWebKit a bit -
works great, but there are some things that could be better (or maybe I just
overlooked the right way to do them?):
1. There doesn't seem to be a way to handle content types QtWebKit doesn't
handle, e.g. embedded videos - is there any way to handle new content types
(writing plugins or reacting to some signal that notifies the main
application it should take care of the content) yet?
2. It would make sense for a C++ object that is being used from JavaScript
through addToJSWindowObject to know what QWebFrame it is being called from,
if it has been added to several frames. Right now, sender() is 0 when a slot
is invoked from JavaScript - setting it to the QWebFrame would make sense
(e.g. to do some qobject_cast<QWebFrame*>(sender())->evaluateJavaScript()
bits as part of the slot)
3. A QWebPage::addToJSWindowObject (that just adds it to all QWebFrames)
convenience function would be nice to have (for generic helper classes that
just provide extra functionality to JavaScript, e.g. getting a list of
available fonts on the system)
4. The return value of QWebFrame::evaluateJavaScript() isn't always what you'd
expect - e.g. document.getElementById("something").style.color;
returns an empty string rather than the color of the object I asked about
(the opposite, document.getElementById("something").style.color='#123456';,
works from evaluateJavaScript, so I'm sure I'm in the right frame) -- while
at it, it would probably make sense to return a QVariant instead of a
QString, given the return can be pretty much any type.
5. It would be nice to be able to get a pointer to the QWidget representing
some HTML tags (e.g. to use QLineEdit features such as setting a validator on
a <input> tag) -- API-Wise, something like "QWidget
*QWebFrame::widgetForElementId(const QString &id)" comes to mind [returning 0
for anything that isn't shown using a QWidget].
Other than that, I haven't run into problems with QtWebKit yet - great work!
bero
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
On Sunday 10 February 2008 17:47:07 Bernhard Rosenkränzer wrote:
> Hi,
> I've just downloaded a 4.4 snapshot and played around with QtWebKit a bit -
> works great, but there are some things that could be better (or maybe I
> just overlooked the right way to do them?):
>
> 1. There doesn't seem to be a way to handle content types QtWebKit doesn't
> handle, e.g. embedded videos - is there any way to handle new content types
> (writing plugins or reacting to some signal that notifies the main
> application it should take care of the content) yet?
Yes, we're working on providing an API for that.
> 2. It would make sense for a C++ object that is being used from JavaScript
> through addToJSWindowObject to know what QWebFrame it is being called from,
> if it has been added to several frames. Right now, sender() is 0 when a
> slot is invoked from JavaScript - setting it to the QWebFrame would make
> sense (e.g. to do some
> qobject_cast<QWebFrame*>(sender())->evaluateJavaScript() bits as part of
> the slot)
There is unfortunately no easy solution at the moment. I can only think of an
approach similar to QScriptContext at the moment. But for now that will be a
known limitation of the API ;(
> 3. A QWebPage::addToJSWindowObject (that just adds it to all QWebFrames)
> convenience function would be nice to have (for generic helper classes that
> just provide extra functionality to JavaScript, e.g. getting a list of
> available fonts on the system)
I'm not sure how useful that is, given that nowadays most websites have only
one frame?
> 4. The return value of QWebFrame::evaluateJavaScript() isn't always what
> you'd expect - e.g. document.getElementById("something").style.color;
> returns an empty string rather than the color of the object I asked about
> (the opposite, document.getElementById("something").style.color='#123456';,
> works from evaluateJavaScript, so I'm sure I'm in the right frame) -- while
> at it, it would probably make sense to return a QVariant instead of a
> QString, given the return can be pretty much any type.
I agree, the return type should be a QVariant. We're working on fixing that.
> 5. It would be nice to be able to get a pointer to the QWidget representing
> some HTML tags (e.g. to use QLineEdit features such as setting a validator
> on a <input> tag) -- API-Wise, something like "QWidget
> *QWebFrame::widgetForElementId(const QString &id)" comes to mind [returning
> 0 for anything that isn't shown using a QWidget].
Unfortunately that's not possible to implement because native widgets are not
used to implement form elements. They are drawn using QStyle at run-time, but
the implementation is completely inside WebKit.
> Other than that, I haven't run into problems with QtWebKit yet - great
> work! bero
Thanks for testing/playing around with it! :)
Simon
Attachment:
Attachment:
signature.asc
Description: This is a digitally signed message part.