Bug 25823 – [Qt] Add API to generate a QUrl from a user string url

• Component: WebKit Qt
• Status: RESOLVED FIXED

[Benjamin Meyer]

Add an API to generate a QUrl out of a string correcting for errors and missing information. See the API documentation for more details about the function.

[Benjamin Meyer]

Created attachment 30387 [details]
the patch with the api

[Kenneth Rohde Christiansen]

The patch is OK with me, and the autotest is definately a plus.

The reviewer might point out that this is probably not the best place for having such a function and that it should be in QUrl, but as it makes many web assumptions, that has been rejected. Thus QWebView seems like the best place to put such functionality, that taken in consideration.

[Eric Seidel (no email)]

Comment on attachment 30387 [details]
the patch with the api

Personally I don't think this is a very good idea for Qt to expose.

"Guessing the URL" only helps on the first request.  After that there are redirects and URL re-writes and JavaScrpt which are going to cause the final URL to change quite a bit, making exposing this API less useful.

But I don't work on the Qt port.  So I'll let a Qt reviewer review this.

[Holger Freyther]

Comment on attachment 30387 [details]
the patch with the api


> +    If that is not the case, an attempt is made to turn the string into a
> +    http:// or ftp:// URL. The latter in the case the string starts with
> +    'ftp'. The result is then passed through QUrl's tolerant parser, and
> +    in the case or success, a valid QUrl is returned, orelse a QUrl().

orelse??? space missing?



> +        QUrl url = view->guessUrlFromString(string);

my taste would say to use the static type QWebView::guessUrlFromString... ignore that at your will..


are you sure that QWebView is the best place for that? If I have a QWebPage in a graphics view item I still want to use the guessing and using QWebView might not feel right. Do you think QWebView is the best place to put it? what about QWebPage?

[Holger Freyther]

Okay landed as is in r44180. Didn't know if you have commit access or not... I will await the usual API review that will happen before 4.6.