[Development] QWebChannel setTimeout

[Chris Adams]

A long time ago there were plans to add
https://codereview.qt-project.org/#/c/49155 but see the comments regarding
context deletion and also https://codereview.qt-project.org/#/c/84341/


On Sun, Jul 6, 2014 at 4:07 PM, Hausmann Simon <Simon.Hausmann at digia.com>
wrote:

> I think setTimeout would be a good function to add to qml's Javascript
> environment, as imperative js api next to the timer element.
>
> That said, the risk is high that people use it to drive animations or work
> around other things.
>
> Anyway, patches welcome :)
>
> Simon
>
>   Opprinnelig melding
> Fra: Milian Wolff
> Sendt: 02:33 lørdag 5. juli 2014
> Til: development at qt-project.org
> Emne: Re: [Development] QWebChannel setTimeout
>
>
> On Friday 04 July 2014 13:41:28 Bernd Lamecker wrote:
> > Hi,
> >
> > is there a special reason why you call
> > setTimeout(function() { channel.exec({type:
> QWebChannelMessageTypes.idle});
> > }, 0); (Line 179 & 197 in qwebchannel.js)
> > via setTimeout? For me this also works without doing a singleshot.
> > But the setTimeout function is not defined when including qwebchannel.js
> > into a qml application.
>
> You can have a look at what I did in Client.qml in
> https://codereview.qt-project.org/#/c/81523/13//ALL - there I implement
> setTimeout in terms of a QML
> Timer object. Ugly and doesn't support multiple simultaneous calls to
> setTimeout, but at least it works. I really think we should have a
> setTimeout
> in QML, if alone to better support embedding external JavaScript libraries.
>
> Now, on the topic of _why_ I use setTimeout there: This comes from the
> original implementation of the QWebChannel we did for a customer of ours
> on an
> embedded platform which showed serious performance issues and scheduling
> problems, i.e. sending WebSocket messages repeatedly to a QtWebKit client
> completely hogged up the CPU in the WebSocket code and all other
> applications
> froze. This might need to be revisited, esp. considering that we'll get
> much
> faster QtWebKit IPC instead of WebSockets for the common case. So maybe,
> all
> of that is not required anymore. But before I blindly remove this stuff, I
> guess we should first work on the core functionality and then eventually
> cleanup such legacy code (and write more benchmarks etc. to verify we are
> not
> breaking anything).
>
> Bye
>
> --
> Milian Wolff | milian.wolff at kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140707/1f757e94/attachment.html>