Hey guys, On Monday 07 July 2014 10:54:30 Chris Adams wrote: > 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/
Nice, I esp. like the Qt.later function. Anyhow, with Qt.after in place, one could trivially also add a "setTimeout" global function, or use it instead of setTimeout in library code where appropriate. Is anyone working on the above codereviews to bring them to Qt V4? > On Sun, Jul 6, 2014 at 4:07 PM, Hausmann Simon <[email protected]> > > That said, the risk is high that people use it to drive animations or work > > around other things. I don't think so, really. The animation framework is a) much easier to use for that matter b) documented to be used for that purpose. And the same could be said about declarative Timer objects as well, I don't really see the difference besides this being imperative API. Bye > > Fra: Milian Wolff > > Sendt: 02:33 lørdag 5. juli 2014 > > Til: [email protected] > > 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 | [email protected] | 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
