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 b
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 unreasona
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 havi
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 havi
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 se
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++ generic programming features it is a sh
On Thursday 02 July 2015 17:48:59 Thiago Macieira wrote:
> 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 anyw
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=7d5e849e
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 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
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 - thiago.macieir
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 Jul 2, 2015, at 2:09 AM, Bo Thorsen
mailto: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 5.5.0 release.
My
On Wed, Jul 1, 2015 at 5:11 PM, Olivier Goffart wrote:
> On Wednesday 1. July 2015 16:50:09 Stephen Kelly wrote:
>> Hello,
>>
>> I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
>> many warnings for each translation unit about
>> -Winconsistent-missing-override.
>
> https://cod
On Wednesday 01 July 2015 11:59:58 Simon Hausmann wrote:
> Hi,
>
> We are currently experiencing severe connectivity issues in our CI
> infrastructure. As a result integrations staged in Gerrit are likely to
> fail, hang or - in the worst case - kill kittens.
>
> Digia IT is working on it.
qtbas
On Thursday 02 July 2015 03:02:51 Thiago Macieira wrote:
> [*] getting a d pointer does not mean getting rid of the private members.
> See the Qt 6 task for QDateTime, for example. It's also possible to have
> classes with no d pointer, but you need to be absolutely sure there's no
> chance of ext
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 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 alr
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
19 matches
Mail list logo
