[Development] URLs in QML/JS

[Alan Ezust]

On Mon, Jun 17, 2013 at 2:31 PM, Alan Alpert <416365416c at gmail.com> wrote:

> On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon
> <Simon.Hausmann at digia.com> wrote:
> > I'd like to make URLs a better supported citizen in the world of QML's
> > JavaScript, and it appears that a few options present themselves:
> >
> > (1) We could just create more or less a 1:1 API mapping of QUrl. A url
> object
> > in JavaScript would continue to have a toString method, for convenient
> > 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?)
> >
> > (2) There appears to be development towards creating a specified URL
> JavaScript
> > 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
> browser objects).
>

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.
Don't worry about conforming to a standard javascript API until there is
one.

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...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130618/06614167/attachment.html>