On 10.1.2012 19.04, "Oswald Buddenhagen"
wrote:
>On Tue, Jan 10, 2012 at 11:57:35AM +, ext shane.kea...@accenture.com
>wrote:
>> My view is the workflow should look like this:
>>
>i agree, except with the first point:
>
>> 1. author submits change to the version they normally work on (4.8 o
On 01/11/2012 04:06 PM, ext Ismael Luceno wrote:
> error: invalid static_cast from type 'QObject*' to type
> 'QAndroidPlatformScreen*'
Is this GCC 4.6 by any chance?
I've had a report of it failing to compile some moc-generated code in my
project too. I don't know this code but in my code's case
g++ -c -Wno-psabi -march=armv5te -mtune=xscale -msoft-float -fpic
-ffunction-sections -funwind-tables -fstack-protector -fno -short-enums
-DANDROID -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__
-D__ARM_ARCH_5TE__ -Wa,--noexecstack -DQT_NO_QWS _TRANSFORMED
-DQT_NO_TEMPORARYDIR -DQT_NO_SHAREDM
Hi, just speaking by myself since at least I have got a N950 in my hands
running Qt 5...
On 01/10/2012 06:16 AM, ext xizhi@nokia.com wrote:
> Hi,
>
> I would like to get some clarity regarding Qt5 on Harmattan...
>
> Based on the Wiki page here
> (http://developer.qt.nokia.com/wiki/Qt_5.0), H
On Tue, Jan 10, 2012 at 02:08:38PM +0100, João Abecasis wrote:
> On 10. jan. 2012, at 13.31, ext Oswald Buddenhagen wrote:
> > On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
> >> It is not appropriate to tag an atomically-replace-previous-version on
> >> to the close()
> >
> >
On Tue, Jan 10, 2012 at 11:57:35AM +, ext shane.kea...@accenture.com wrote:
> My view is the workflow should look like this:
>
i agree, except with the first point:
> 1. author submits change to the version they normally work on (4.8 or 5.0)
>
no, the author starts his submission against qt5
Hi,
thanks for your input. What do you think about adding some sizeHint policy to
this? I'm thinking about as it is done for QComboBox, i.e. AdjustToContents vs.
AdjustToContentsOnFirstShow. Translated to this use case would be to never
return any different sizeHint (and especially never call u
Hi,
We (QtWebKit team) intent on testing and making sure that WebKit works
reasonable on the N9, but it is not a hard target for the release.
Instead what we are focusing on it providing a better QML view which comes with
most of the N9 browser features out of the box.
Kenneth
Hi,
I would like to get some clarity regarding Qt5 on Harmattan...
Based on the Wiki page here (http://developer.qt.nokia.com/wiki/Qt_5.0),
Harmattan is not a Tier 1 platform.
I also didn't find any Wiki page saying anything regarding Tier 2 and Tier 3
platforms.
The only information I can fin
On 10.1.2012 14.58, "lars.kn...@nokia.com" wrote:
>On 1/9/12 8:50 PM, "ext lars.kn...@nokia.com"
>wrote:
>
>>On 1/9/12 6:09 PM, "ext Quim Gil" wrote:
>>
>>>Hi Sergio,
>>>
>>>On 01/09/2012 06:12 AM, ext Sergio Ahumada wrote:
Qt 4.x has been in Gerrit since 03/01/2012
https://bug
On 10. jan. 2012, at 13.31, ext Oswald Buddenhagen wrote:
> On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
>> It is not appropriate to tag an atomically-replace-previous-version on
>> to the close()
>
> you don't provide any supporting evidence for that pov, though.
Because
On 1/9/12 8:50 PM, "ext lars.kn...@nokia.com" wrote:
>On 1/9/12 6:09 PM, "ext Quim Gil" wrote:
>
>>Hi Sergio,
>>
>>On 01/09/2012 06:12 AM, ext Sergio Ahumada wrote:
>>> Qt 4.x has been in Gerrit since 03/01/2012
>>>
>>> https://bugreports.qt.nokia.com/browse/QTQAINFRA-432
>>
>>Wow, such an await
Hi,
thanks for your input. What do you think about adding some sizeHint policy to
this? I'm thinking about as it is done for QComboBox, i.e. AdjustToContents vs.
AdjustToContentsOnFirstShow. Translated to this use case would be to never
return any different sizeHint (and especially never call u
On 6. jan. 2012, at 21.27, ext David Faure wrote:
> On Friday 06 January 2012 11:41:05 =?ISO-8859-1?Q?Jo=E3o?= Abecasis wrote:
>> I don't support putting this in QFile as has been suggested as, from my
>> experience with it, this will open a can of worms in maintenance and
>> subtle issues croppin
On Tuesday, 10 de January de 2012 11.57.35, shane.kea...@accenture.com wrote:
> 1. author submits change to the version they normally work on (4.8 or 5.0)
> 2. code review happens, change accepted
> 3. CI happens, change integrated
> 4. author cherry-picks to the other repository, resolving any con
On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote:
> It is not appropriate to tag an atomically-replace-previous-version on
> to the close()
>
you don't provide any supporting evidence for that pov, though.
> and normal clean up that the destructor does.
>
that i agree with.
> >
On 6. jan. 2012, at 22.09, ext Thiago Macieira wrote:
>> Why would this be better? It can't be "because it's not clear which file
>> some methods should work on" (Joao's argument), since it would still have
>> all the QFile methods. It can't be because we need additional API compared
>> to QFile,
On 6. jan. 2012, at 22.13, ext Thiago Macieira wrote:
> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
>> Exception handling is a new argument though. But doesn't the current QFile
>> have the exact same issue then? You start writing, throw an exception, dtor
>> calls close, there
With both 4.8 and 5.0 in gerrit, how should we do back/forward porting of bug
fixes between repositories?
Should the change author cherry-pick, resolve conflicts, and submit a change to
the other repository?
Or will a fix accepted to 4.8 be applied to 5.x without usually needing further
involve
On 10. jan. 2012, at 02.39, ext craig.sc...@csiro.au wrote:
> On 09/01/2012, at 10:14 PM, Oswald Buddenhagen wrote:
>> On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote:
>>> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
Exception handling is a new argument tho
On 1/10/12 6:39 AM, "ext Stephen Kelly" wrote:
>On Tuesday, December 20, 2011 10:17:20 Thiago Macieira wrote:
>> str = QString::fromLatin1("%1 %2").arg(foo, bar);
>> reason: QString::fromLatin1 will need to allocate memory
>> use: QStringLiteral
>
>I looke
On Monday, January 09, 2012 19:37:47 Gábor Lehel wrote:
> ...and apologies for the email spam but yet another complication is
> that if the header defining the macro is included later than the one
> which does the poisoning, that'll also result in an error. Probably
> that's also solvable by #ifdef
22 matches
Mail list logo
