Thanks for the reply.
I think I have to modify the Qt header file to solve this issue.
On Thu, Jul 2, 2015 at 3:09 PM, Bo Thorsen b...@vikingsoft.eu wrote:
Den 01-07-2015 kl. 18:36 skrev Edward Sutton:
Is there a work-around I could use in my Qt project file?
Upgrade to 5.5.1.
Den 01-07-2015 kl. 18:36 skrev Edward Sutton:
Is there a work-around I could use in my Qt project file?
Upgrade to 5.5.1. It's already fixed.
The problem was not deemed important enough to affect the 5.5.0 release.
My Chicago based sales rep told me that ( somewhere buried in my license
On Jul 2, 2015, at 2:09 AM, Bo Thorsen
b...@vikingsoft.eumailto:b...@vikingsoft.eu wrote:
Den 01-07-2015 kl. 18:36 skrev Edward Sutton:
Is there a work-around I could use in my Qt project file?
Upgrade to 5.5.1. It's already fixed.
The problem was not deemed important enough to affect the
On Thursday 02 July 2015 16:36:55 Martin Koller wrote:
Hi,
my app compilation fails with Qt 5.5.0 on iOS since I found in qglobal.h
#if defined(Q_OS_IOS)
# define QT_NO_PROCESS
#endif
to be honest, I did never try if it worked, but at least my code did compile
with Qt 5.4.2
Was
Hi,
my app compilation fails with Qt 5.5.0 on iOS since I found in qglobal.h
#if defined(Q_OS_IOS)
# define QT_NO_PROCESS
#endif
to be honest, I did never try if it worked, but at least my code did compile
with Qt 5.4.2
Was QProcess never supposed to work there or is this a new limitation ?
On Thursday 02 July 2015 13:47:26 Edward Sutton wrote:
Is there a work-around I could use in my Qt project file?
Apply the fix to qcompilerdetection.h
https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=patch;h=7d5e849e2808e9051a6d3ab19f29109b852f7bc9
--
Thiago Macieira -
On Thursday 02 July 2015 10:44:14 Marc Mutz wrote:
D-pointers are not called Compiler Firewalls for nothing. Just compare
assembly generated from use of QColor (which doesn't even have a d-pointer,
but is mostly out-of-line anyway) with that generated for QRgb.
That's not a fair comparison.
On 7/2/15 2:00 PM, Bernhard wrote:
Unfortunately adding signals of the template’s type is exactly what I
would have needed several times. In that case there is no clean
solution. I once added QVariant based signals as a workaround but that
was ridiculous. In modern times having powerful C++
On Thursday 02 July 2015 23:00:43 Bernhard wrote:
Unfortunately adding signals of the template’s type is exactly what I would
have needed several times. In that case there is no clean solution. I once
added QVariant based signals as a workaround but that was ridiculous. In
modern times having
On Thursday 02 July 2015 23:00:43 Bernhard wrote:
Unfortunately adding signals of the template’s type is exactly what I would
have needed several times.
Then you should have used Boost.Signals.
Qt is not the only C++ library out there, and asking it to be everything for
everyone is
On 7/2/15 2:23 PM, Milian Wolff wrote:
On Thursday 02 July 2015 23:00:43 Bernhard wrote:
Unfortunately adding signals of the template’s type is exactly what I would
have needed several times. In that case there is no clean solution. I once
added QVariant based signals as a workaround but
On Thursday 2. July 2015 08:41:12 Thiago Macieira wrote:
On Thursday 02 July 2015 13:47:26 Edward Sutton wrote:
Is there a work-around I could use in my Qt project file?
Apply the fix to qcompilerdetection.h
https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=patch;h=7d5e849e2
We still have trouble (it seemed like things went back to working for a while),
then either some network connection/switch and/or some server blade went down
again.
I don't know the details of the hardware, but there are people looking at it.
Unfortunately it will affect all integrations since
On Thursday 02 July 2015 23:00:43 Bernhard wrote:
Unfortunately adding signals of the template’s type is exactly what I would
have needed several times. In that case there is no clean solution. I once
added QVariant based signals as a workaround but that was ridiculous. In
modern times having
14 matches
Mail list logo
