On Wednesday, 30 August 2017 23:12:40 PDT Lars Knoll wrote:
> > a) revert the 5.6 backport of 88a8feeacb9bdaff9ee06164424e407eb904cd10 so
> > that 5.6.x will forever calculate Keccak, not SHA3;
> >
> > b) additionally backport 12c5264d9add1826d543c36d893db77262195fc6 to both
> > 5.6 and 5.9, with
> On 30 Aug 2017, at 21:45, Thiago Macieira wrote:
>
> When writing the 5.6.3 changelog, I'm currently leaving it with:
>
> **
> * Important Behavior Changes *
> *
Hi all,
Still quite many Qt 5.6.3 change files still without any action or missing
'+2'... (see
https://codereview.qt-project.org/#/q/message:%22Add+change+file+for%22,n,z )
Maintainers, please finalize these during today; we need to get these in to be
able to proceed with Qt 5.6.3 release
br
On Wednesday, 30 August 2017 17:17:32 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > It makes QTimer possible.
> > That sounds quite important to me :-)
>
> I guess so :) I still don't get what purpose calling QObject::timerEvent()
> has if the method itself does nothing. Gives me somet
Thiago Macieira wrote:
> It makes QTimer possible.
..
> That sounds quite important to me :-)
I guess so :) I still don't get what purpose calling QObject::timerEvent() has
if the method itself does nothing. Gives me something to ponder.
> function, because it would break the existing code. A
On Wednesday, 30 August 2017 14:17:05 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
>
> Oops, missed this one.
>
> > Unfortunately, we can't change anymore.
>
> Can someone explain what could possibly be broken by changing this? Can the
> current base-level QObject::timerEvent() be used
Thiago Macieira wrote:
Oops, missed this one.
> Unfortunately, we can't change anymore.
Can someone explain what could possibly be broken by changing this? Can the
current base-level QObject::timerEvent() be used for anything constructive
other
than heating the office or preventing a CPU core
When writing the 5.6.3 changelog, I'm currently leaving it with:
**
* Important Behavior Changes *
***
Hi,
I ran into and reported a CPU burning issue a couple of days back, which was
quickly resolved. It intrigued me why an application that doesn't use native
Mac menus at all would be calling [NSMenu update] at all.
I now know that the menu which triggered the scheduled NSMenu update is one
t
On Wednesday, 30 August 2017 07:32:42 PDT Jason H wrote:
> > For one-offs or maybe tens of copies, sure, there's a lot of Arduinos. And
> > a lot of Raspberry Pis too.
> >
> > For production runs, that number goes very quickly to zero.
>
> I guess this comes down to whom you are marketing. I can
On Wednesday, 30 August 2017 00:30:05 PDT Olivier Goffart wrote:
> We can change the documentation and recommend against using killTimer and
> startTimer. QBasicTimer should be used instead. This would have probably
> avoided the problem in this case (as one would have called stop instead of
> m_up
> Sent: Tuesday, August 29, 2017 at 5:07 PM
> From: "Thiago Macieira"
> To: development@qt-project.org
> Subject: Re: [Development] Qt and IoT infographic
...
> > Besides, this comes a bit as disdainful. I work in music research and
> > *everything* embedded uses Arduinos, Pi, Beaglebones or sim
Hi,
We have new Qt 5.9.2 snapshot available via online installer. Instructions how
to get it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer
Snapshot is based on https://codereview.qt-project.org/#/c/203493/
Packages are smoke tested and seems to be OK so please take a tour. P
> Today, that QObject::schedule is achieved by (ab)using
QTimer::singleShot(0, func).
There have been interesting discussions on StackOverflow about this :
https://stackoverflow.com/questions/21646467/how-to-execute-a-functor-or-a-lambda-in-a-given-thread-in-qt-gcd-style
https://stackoverflow.com
Il 30/08/2017 11:28, Morten Sørvig ha scritto:
There is also the option of creating new API that better covers the use case of
running a pice of code once when control returns to the event loop. In use this
could look something like this:
QCocoaMenu::scheduleUpdate()
{
if (m_updateScheduled
> On 30 Aug 2017, at 09:30, Olivier Goffart wrote:
>
> Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
>> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
>>> Which we just rediscovered :) Funny though, apparently 1 misdirected
>>> startTimer() call can turn a
> On 29 Aug 2017, at 18:00, Thiago Macieira wrote:
>
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
>> And yet it has a web server for serving up either a human-readable page or
>> JSON on demand, and it also pushes data to a central server periodically.
>
> Is that a static JS
Thiago Macieira (earlier):
>>> Research shows NO ONE deploys Arduino for real products. It's a
>>> maker toy, stuff hobbyists use to make one-off things and some
>>> professional makers use for initial prototyping. When they get
>>> serious, Arduino goes out the window and they get real boards.
[..
Maybe even deprecate startTimer and killTimer?
-1
I like this low level insight, which gives me a higher sense of control about
what's going on.
Philippe
On Wed, 30 Aug 2017 08:06:35 +
Lars Knoll wrote:
>> On 30 Aug 2017, at 09:30, Olivier Goffart wrote:
>>
>> Am Dienstag, 29. August
On 30 Aug 2017, at 09:30, Olivier Goffart
mailto:oliv...@woboq.com>> wrote:
Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
Which we just rediscovered :) Funny though, apparently 1 misdirected
startTimer() call
Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira:
> On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote:
> > Which we just rediscovered :) Funny though, apparently 1 misdirected
> > startTimer() call can turn any application in a CPU hog that burns cycles
> > without e
21 matches
Mail list logo
