Hi,
There is also a fix for the failing tst_qquicktrailemitter in
declarative/stable (see
https://bugreports.qt-project.org/browse/QTBUG-33421 ,
https://codereview.qt-project.org/#change,60072 ) , so, a merge
stable->dev for qtdeclarative might further improve things.
Friedemann
--
Friedem
On Thursday 19 December 2013 09:19:38 Rick Stockton wrote:
> On 12/18/2013 01:10 PM, Andreas Aardal Hanssen wrote:
> > On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
> Inner-most quote is from Martin Koller.
>
> >>> I've discovered that with Qt5 I get a different order of mouse events on
> >>
On 20 December 2013 04:52, Kuba Ober wrote:
> Is this supported on all platforms now? IIRC it did not work OS X last time I
> tried, but yes,
> it did work great on Windows.
>
> — Kuba
The Cocoa framework mandates that all GUI-related operations must be
done in the first thread in a process [1].
On 19 Dec 2013, at 18:36, Rick Stockton
wrote:
> Perhaps we should perform as QT4 did (there wasn't a second ButtonPress,
> the DoubleClick "ate it"). Such use cases would then need to be "fixed
> up" (i,e, to accept EITHER event as a cause for executing that Action)?
> Logical, but a lot of wor
Is this supported on all platforms now? IIRC it did not work OS X last time I
tried, but yes,
it did work great on Windows.
— Kuba
On Dec 14, 2013, at 3:25 PM, Roland Winklmeier
wrote:
> Thanks very much Olivier and Thiago!
> That works brilliant.
>
> No idea why I forgot that QThread must
<< SNIP >>
On 12/18/2013 06:30 PM, Nicolás Alvarez wrote:
> 2013/12/18 Andreas Aardal Hanssen :
>> On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
>>
I've discovered that with Qt5 I get a different order of mouse events on
a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
doubl
On 12/18/2013 01:10 PM, Andreas Aardal Hanssen wrote:
> On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
Inner-most quote is from Martin Koller.
>>> I've discovered that with Qt5 I get a different order of mouse events on
>>> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
>>> double clicki
On 19.12.2013 17:42, Thiago Macieira wrote:
> On quinta-feira, 19 de dezembro de 2013 11:01:55, Fält Simo wrote:
>> Ci is recovering from the cloning problems we have had during last two
>> days. We still don't know the root cause for the problems, but after the
>> last updates to Jenkins this mor
On quinta-feira, 19 de dezembro de 2013 17:47:50, Sergio Ahumada wrote:
> https://codereview.qt-project.org/74073 qtbase
> https://codereview.qt-project.org/74074 qtdeclarative
Thanks Sergio.
Looks like the qtdeclarative failure might be real, though.
--
Thiago Macieira - thiago.macieira (AT) in
On quinta-feira, 19 de dezembro de 2013 09:16:32, Albert Astals Cid wrote:
> But that needs:
> a) A central place to write down those investigated places that have been
> proven to be harmless so that not N people waste their time investigating
> b) Reinvestigation every X time to make sure it i
On quinta-feira, 19 de dezembro de 2013 11:01:55, Fält Simo wrote:
> Ci is recovering from the cloning problems we have had during last two
> days. We still don't know the root cause for the problems, but after the
> last updates to Jenkins this morning builds have failed only due to test
> failur
On Tue, Dec 17, 2013 at 08:48:40AM -0800, Thiago Macieira wrote:
> On terça-feira, 17 de dezembro de 2013 20:29:19, Yang Fan wrote:
> > "C:\Program Files (x86)\Microsoft Visual Studio
> > 11.0\VC\BIN\nmake.exe" -f Makefile.Release
> >
> > Microsoft (R) Program Maintenance Utility Version 1
I can not see much changes on codereview from your link since summer of
last year. What do I miss?
Your attached PDF was interessting, thanks for it.
kind regards
Kai-Uwe Behrmann
Am 16.12.2013 10:43, schrieb Alexandros Dermenakis:
> Hello!
>
> I am working on merging a patch I made in summer 20
Ci is recovering from the cloning problems we have had during last two days.
We still don't know the root cause for the problems, but after the last updates
to Jenkins this morning builds have failed only due to test failures, not due
to problems connecting to codereview.
Simo
From: developme
On 19 Dec 2013, at 11:29, Tim Blechmann wrote:
>>> Should Qt clean-up dynamically allocated reachable pointers, or is this
>>> useless / pointless work?
> [snip]
>> 2) static leak, which is when the pointer is overwritten at shutdown without
>> being freed
> i wonder: what is the definition of "s
>> In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
>> using new that it never destroys. The memory is always pointed to by a
>> static member pointer, so it's never "lost" exactly, but the memory is
>> never freed by Qt (but hopefully will be by any decent OS). Is this a bug
On Thursday 19 December 2013, Andreas Hartmetz wrote:
> On Wednesday 18 December 2013 09:34:37 Sorvig Morten wrote:
> > On 18 Dec 2013, at 01:22, Thiago Macieira
wrote:
> > > If it turns out that the failure to destroy is harmless, I'm not sure
> > > we should do anything. If it's harmless, that
On 19 Dec 2013, at 03:30, Nicolás Alvarez wrote:
> That would break many use cases, such as QSpinBox, which performs an
> action on every press (not release) and doesn't care about double
> click events.
No it wouldn’t. The default implementation of mouseDoubleClickEvent() calls
mousePressEvent(
On Wednesday 18 December 2013 15:57:55 Thiago Macieira wrote:
> On quarta-feira, 18 de dezembro de 2013 20:45:35, Lisandro Damián Nicanor
>
> Pérez Meyer wrote:
> > On Wednesday 18 December 2013 14:32:41 Lisandro Damián Nicanor Pérez Meyer
> >
> > wrote:
> > > On Wednesday 18 December 2013 16:56:
On Wednesday 18 December 2013 16:52:06 Thiago Macieira wrote:
> On quarta-feira, 18 de dezembro de 2013 16:41:08, Alex Montgomery wrote:
> > I think Thiago made a great point when he said, "Objects not properly
> > destroyed at shutdown could be an indication of something else wrong". The
> > thing
20 matches
Mail list logo
