Re: [Development] QCOMPARE & mixed types

[Lars Knoll]

On 21 Apr 2017, at 12:53, Konstantin Tokarev 
> wrote:



21.04.2017, 13:45, "Milian Wolff" 
>:
On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote:
 Hi,

 Jedrzej asked me to raise the issue here.

 Rationale for both allowing, as well as for why I think the rationale for
 the existing ban is wrong, is included in the commit message:

   https://codereview.qt-project.org/192269

I for one welcome this change. I always cringed when I wrote code such as

QCOMPARE(getSomeQUint64(), 0)

and it would fail to compile, forcing me to write ugly code such as

QCOMPARE(getSomeQUint64(), quint64(0))

I've also come across code that failed to compile some platforms, since it
used something like 0l or 0ll which did not match whatever platform-specific
type was used on the lhs...

So, from my side a clear +1!

Another case: comparing QString or QByteArray on one side with const char*
literal, or with expression which returns QStringBuilder

Implicit conversions from QByteArray/const char * to QString was one of the 
reasons we didn't want this in the past (Qt 4), as those conversions were 
locale dependent. That is of course less of a problem since Qt 5.0.

Cheers,
Lars



--
Milian Wolff | milian.wo...@kdab.com | Software 
Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
,

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Heads up - 5.9 soft string freeze

[Jani Heikkinen]

Hi all,

Qt 5.9 beta is out & work towards final release continues. One step on the way 
is String Freeze which should happen really soon to be able to minimize time 
needed between beta and RC. So let's start keeping the translatable strings as 
it is & fix remaining important issues. And let's have the official String 
Freeze 28th April 2017.

Br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Announce] Qt Creator 4.2.2 released

[List for announcements regarding Qt releases and development]

We are happy to announce the release of Qt Creator 4.2.2.

http://blog.qt.io/blog/2017/04/21/qt-creator-4-2-2-released/

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Announce mailing list
annou...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCOMPARE & mixed types

[Konstantin Tokarev]

21.04.2017, 13:45, "Milian Wolff" :
> On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote:
>>  Hi,
>>
>>  Jedrzej asked me to raise the issue here.
>>
>>  Rationale for both allowing, as well as for why I think the rationale for
>>  the existing ban is wrong, is included in the commit message:
>>
>>    https://codereview.qt-project.org/192269
>
> I for one welcome this change. I always cringed when I wrote code such as
>
> QCOMPARE(getSomeQUint64(), 0)
>
> and it would fail to compile, forcing me to write ugly code such as
>
> QCOMPARE(getSomeQUint64(), quint64(0))
>
> I've also come across code that failed to compile some platforms, since it
> used something like 0l or 0ll which did not match whatever platform-specific
> type was used on the lhs...
>
> So, from my side a clear +1!

Another case: comparing QString or QByteArray on one side with const char*
literal, or with expression which returns QStringBuilder

> --
> Milian Wolff | milian.wo...@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCOMPARE & mixed types

[Milian Wolff]

On Freitag, 21. April 2017 12:10:07 CEST Marc Mutz wrote:
> Hi,
> 
> Jedrzej asked me to raise the issue here.
> 
> Rationale for both allowing, as well as for why I think the rationale for
> the existing ban is wrong, is included in the commit message:
> 
>   https://codereview.qt-project.org/192269

I for one welcome this change. I always cringed when I wrote code such as

QCOMPARE(getSomeQUint64(), 0)

and it would fail to compile, forcing me to write ugly code such as

QCOMPARE(getSomeQUint64(), quint64(0))

I've also come across code that failed to compile some platforms, since it 
used something like 0l or 0ll which did not match whatever platform-specific 
type was used on the lhs...

So, from my side a clear +1!
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QCOMPARE & mixed types

[Marc Mutz]

Hi,

Jedrzej asked me to raise the issue here.

Rationale for both allowing, as well as for why I think the rationale for the 
existing ban is wrong, is included in the commit message:

  https://codereview.qt-project.org/192269

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding std::weak_ptr to QModelIndex

[Marc Mutz]

On Friday 21 April 2017 09:32:44 Filippo Cucchetto wrote:
> 2017-04-21 9:13 GMT+02:00 Marc Mutz :
> > On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote:
> > > Is there any plan to enhance the QModelIndex interface by adding
> > > support
> > 
> > to
> > 
> > > std::weak_ptr > > I know that is not necessary since we can directly store T* from
> > > shared_ptr but being able to store a weak_ptr seems a little bit
> > 
> > safer.
> > 
> > There is no such plan. QModelIndexes should not be stored anywhere, they
> > are
> > simply an interface type: as long as you're using ti correctly, you could
> > not
> > observe the weak_ptr being reset
> > 
> Yes and i agree, but there's a difference between a crash of an
> application and a warning.

Yes, the former is preferable :)

Seriously, if you still release code that hasn't been though asan, valgrind, 
Purify or any other such tool, a weak_ptr will not help you, either. If you 
don't test, why do you expect your users to report some nondescript warning 
back to you? I'd say they're more likely to report a crash.

> Futhermore since QModelIndexes have been somewhat interfaced with QML this
> bring
> a lot of indeterminism.
>
> > If and when we change QModelIndex to become more convenient, but also
> > more expensive to use, it should probably get a QVariant (or std::any),
> > not any particular type.
> > 
> > Thanks,
> > Marc
> > 
> > --
> > Marc Mutz  | Senior Software Engineer
> > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> > Tel: +49-30-521325470
> > KDAB - The Qt, C++ and OpenGL Experts

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] SignalTranisition: using of signal arguments within onTriggered handler?

[Jan Krause]

a transition of a state machine has normally the properties 
trigger/signal, guard, action... a SignalTransition 
(http://doc.qt.io/qt-5/qml-qtqml-statemachine-signaltransition.html) of 
the declarative state machine framework has signal + guard ...


where is the action property?
there is a triggered signal -> so one can use onTriggered; but how can I 
use the arguments of the trigger signal in the onTriggered handler?


for example:

signal triggerSignal(int myIntParam);
SignalTransition {
  targetState: state_2
  signal: triggerSignal
  guard: myIntParam < 10
  onTriggered: console.log("myIntParam: "+myIntParam)
}

is this possible? or is there an other way to use signal arguments 
within onTriggered?


thanks and cheers
Jan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Edward Welbourne]

Lars Knoll (21 April 2017 10:10)
> Let us know once the updated diffs are available. No point doing the review 
> on the old diffs.

Done :-)

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Lars Knoll]

> On 21 Apr 2017, at 10:08, Edward Welbourne  wrote:
> 
> Lars Knoll (20 April 2017 12:19)
>> Some of the diffs don’t look like they are 100% up to date. Eddy?
> 
> Indeed, I've just been updating them on request.
> I do plan on a bulk update today.

Thanks! Let us know once the updated diffs are available. No point doing the 
review on the old diffs.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 Header diff (API review)

[Edward Welbourne]

Lars Knoll (20 April 2017 12:19)
> Some of the diffs don’t look like they are 100% up to date. Eddy?

Indeed, I've just been updating them on request.
I do plan on a bulk update today.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding std::weak_ptr to QModelIndex

[Filippo Cucchetto]

2017-04-21 9:13 GMT+02:00 Marc Mutz :

> On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote:
> > Is there any plan to enhance the QModelIndex interface by adding support
> to
> > std::weak_ptr > I know that is not necessary since we can directly store T* from
> > shared_ptr but being able to store a weak_ptr seems a little bit
> safer.
>
> There is no such plan. QModelIndexes should not be stored anywhere, they
> are
> simply an interface type: as long as you're using ti correctly, you could
> not
> observe the weak_ptr being reset
>
> Yes and i agree, but there's a difference between a crash of an
application and a warning.
Futhermore since QModelIndexes have been somewhat interfaced with QML this
bring
a lot of indeterminism.


> If and when we change QModelIndex to become more convenient, but also more
> expensive to use, it should probably get a QVariant (or std::any), not any
> particular type.
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
>



-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding std::weak_ptr to QModelIndex

[Marc Mutz]

On Friday 21 April 2017 08:42:37 Filippo Cucchetto wrote:
> Is there any plan to enhance the QModelIndex interface by adding support to
> std::weak_ptr I know that is not necessary since we can directly store T* from
> shared_ptr but being able to store a weak_ptr seems a little bit safer.

There is no such plan. QModelIndexes should not be stored anywhere, they are 
simply an interface type: as long as you're using ti correctly, you could not 
observe the weak_ptr being reset, anyway, and adding an expensive-to-copy type 
such as std::weak_ptr to an otherwise Trivial Class does not pull it's weight.

If and when we change QModelIndex to become more convenient, but also more 
expensive to use, it should probably get a QVariant (or std::any), not any 
particular type.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.9 beta2 available

[Jani Heikkinen]

Hi all,

Qt 5.9 beta2 is now available. Instructions how to get the release are here: 
https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first beta 
can be found as an attachment.

Please test the release and report your effort via 
https://wiki.qt.io/Qt59_release_testing. I hope we can get results for each 
platform in the table to get full coverage & good understanding where we are.

br,
Jani Heikkinen
Release Manager





qt5.9.0-beta1-delta-beta2-commits
Description: qt5.9.0-beta1-delta-beta2-commits
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development