[Development] URLs in QML/JS
Simon.Hausmann at digia.com
Wed Jun 19 17:26:49 CEST 2013
Thanks Alan x2 :) Sounds like QUrl bindings are the way to go.
Alan Ezust <alan.ezust at gmail.com> wrote:
On Mon, Jun 17, 2013 at 2:31 PM, Alan Alpert <416365416c at gmail.com<mailto:416365416c at gmail.com>> wrote:
On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon
<Simon.Hausmann at digia.com<mailto:Simon.Hausmann at digia.com>> wrote:
> I'd like to make URLs a better supported citizen in the world of QML's
> (1) We could just create more or less a 1:1 API mapping of QUrl. A url object
> processing with functions that expect strings. But otherwise it would have
> properties such as scheme, authority, path. Unfortunately the formatting options of
> QUrl's C++ API don't seem to map very well to a JS property based API, so we'd
> have to stick with the defaults (PrettyDecoded?)
> API in the world wide web. The most recent spec appears to be from the whatwg:
> http://url.spec.whatwg.org/ and it seems quite reasonable, as well as
> https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html. However those are drafts
> and therefore likely subject to change, I think.
> Can anyone see a clear preference of (1) over the (2)? (1) is non-standard and
> likely to cause incompatibility issues in the future when integrating with
> third-party JS libraries. OTOH (2) may take who-knows-how-long until it finalizes.
I prefer (1), although it should ideally be a 1:1 mapping of
functionality with an API designed for QML. We'll have incompatibility
either way if it's a changing spec. We went with a draft spec for the
QtQuick.LocalStorage API and I don't think that's compatible with how
browsers implement local storage anymore. Better to add the
compatibility in a separate layer/step (which we'll need anyways for
I agree, I'd like to see QUrl (as well as a few other Qt types) in QML with APIs as close to the Qt APIs as possible.
Another type I'd like to see in QML is the QTimer type, with notify properties and all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development