[Development] HEADS-UP: Branching from '5.12' to '5.12.4' done

[Jani Heikkinen]

Hi!

Final downmerge from '5.12' to '5.12.4' is now done. So all changes targeted to 
Qt 5.12.4 release must be done in '5.12.4' and '5.12' is for Qt 5.12.5 release. 

And as usual staging in '5.12.4' is restricted to release team only. We will 
monitor new changes there & stage changes in automatically. But please remember 
that no any nice-to-haves in anymore; those can wait Qt 5.12.5 release.

br,
Jani


From: Releasing  on behalf of Jani Heikkinen 

Sent: Wednesday, May 22, 2019 12:24 PM
To: development@qt-project.org; releas...@qt-project.org
Subject: [Releasing] HEADS-UP: Branching from '5.12' to '5.12.4' started

Hi!
We have now soft branched '5.12.4' from '5.12'. So all new changes targeted to 
Qt 5.12.4 release should be done in '5.12.4' instead. Final downmerge from 
'5.12' to '5.12.4' will happen Monday 27th May so there is enough time to 
finalize ongoing changes in '5.12' and start using '5.12.4'.

Target is to create first Qt 5.12.4 snapshot for testing during this week & get 
the official release out ~ mid June (11.6.2019 is current estimation)

br,
Jani Heikkinen
Release Manager
___
Releasing mailing list
releas...@qt-project.org
https://lists.qt-project.org/listinfo/releasing
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

On 27 May 2019, at 13:51, Eike Ziller 
mailto:eike.zil...@qt.io>> wrote:



On 27. May 2019, at 12:49, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

On 27 May 2019, at 11:37, Giuseppe D'Angelo 
mailto:giuseppe.dang...@kdab.com>> wrote:

Il 27/05/19 10:24, Simon Hausmann ha scritto:
Hi,
I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.

Could someone please summarize where we are inside this thread? Now I'm 
completely lost…

My summary would be as follows:

* We rename QList to QArrayList
* We can still discuss whether it should rather be Qt5::QList
* QStringList and QBAList will be implemented using QVector
* QList becomes an alias to QVector in wip/qt6 (for now at least)
* We delay the decision on what QList will be in Qt 6 for a little while
* QVector for Qt 6 will most likely be updated with the changes Thiago has 
waiting since quite some years

What is the summary for these?

Thiago?


* To be able to reach a decision:
* we test some Qt libs and apps with QList being an alias to QVector
* We know that the only source incompatibility is the stability of references

At least the following are source incompatibilities currently (though easily 
noticeable because they generate compile errors):

- QVector doesn’t have to/fromSet, to/fromStdList or (obviously) to/fromVector

See https://codereview.qt-project.org/c/qt/qtbase/+/260813 . To/fromVector will 
be added as deprecated methods in Qt 6.

- QVector requires the value type to be default constructible

Already fixed , see https://codereview.qt-project.org/c/qt/qtbase/+/242197

Cheers,
Lars


* If it turns out that most of Qt and (maybe also KDE) run without problems 
with QList = QVector, we should IMO go down that route.
* The reason is that aliasing those classes will resolve many other problems we 
could otherwise run into

Cheers,
Lars

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

--
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

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

Re: [Development] What's the status of a moved-from object?

[Konstantin Ritt]

пн, 27 мая 2019 г. в 11:46, Edward Welbourne :

> сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
>  Repeat after me: default ctors do _not_ establish a valid value.
>
> As an aged C programmer I can respect that ;^>
>
> On 2019-05-25 17:24, Konstantin Ritt wrote:
> >>> Perhaps you mean "trivial type's default ctors do _not_ establish a
> >>> valid value"?
>
> сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development <
> development@qt-project.org>:
> >> No, I actually meant default ctor. What should the default value be?
> >> _Obviously_ zero-initialisation. But oh, no, QSize is different. So
> >> maybe it's not _quite_ so obvious what the default value is. Why is
> >> pen's default value a black solid line instead of NoPen? Why is
> >> QBrush's default ctor not solid black, but NoBrush? See? It's just
> >> nonsense to try to pick a default value, so this is to say: Don't
> >> try.
> >>
> >> There's exactly one exception: containers. _Clearly_ no-one would
> >> _ever_ expect a container to start out anything but empty.
>
> Indeed.
>
> Konstantin Ritt (26 May 2019 10:51) replied:
> > Sure we should force a no-op default ctor where possible, and provide
> > some helper code that returns a valid default/specialized value of
> > that type where {0} isn't enough or non-intuitive
> > (i.e. QQuaternion::identity(), QRect::empty(), QSize::invalid()).
>
> (I can't help but wonder whether QRect::empty() should take a point at
> which to place its empty rectangle.  An animated rectangle that shrinks
> and expands repeatedly [0] shouldn't forget its location at the moment
> when it is transiently empty, so empty rectangles at distinct locations
> are distinct.  But I'm unfamiliar with QRect, so maybe not.)
>
> [0] example (in SVG), remembering position and orientation while empty:
> http://www.chaos.org.uk/~eddy/img/geom/transpyth.svg
>
> > There could [be] more exceptions when we're talking about non-trivial
> > types, at least some of them could be resolved by providing
> > convenience/helper initializers.
>
> Many types need an invalid value (this is the current default for
> QDate, QTime, QDateTime and QTimeZone).  But not all.
>
> For arithmetic types, up to and including QQuaternion and matrices,
> you'll need a zero-value; many (including square matrices) shall also
> need a unit value.  While zero is a natural default, being explicit is
> good; and standard integral/floating types don't default to it.
>
> Various others are (at present) constructed with default values.  In the
> case of QLocale, that can be controlled by calling a static method,
> QLocale::setDefault(), and we'd need to add (as someone tried to do a
> little while ago) a QLocale::defaultLocale() or QLocale::getDefault() to
> get that (note that we can't use the name QLocale::default() as it's a
> reserved word) if we stopped making the default constructor produce it.
> Note that QLocale's default isn't the same thing as QLocale::system(),
> although it starts out so, until setDefault() is called.
>
> We're not particularly consistent about what default construction
> produces; sometimes undefined, sometimes defined but invalid, sometimes
> a zero, sometimes a "reasonable" default.  Which, as Marc tripped over,
> is a source of confusion for authors of client code.  Having static
> methods to return invalid, zero, unit, default values could be made a
> consistent pattern, with consistent naming, to reduce confusion.
>
> We can, of course, do that without changing what the default-constructed
> objects are, but changing that also to a consistent pattern - the same
> as the moved-from state - would make matters clearer (for any choice of
> what moved-from state to consistently use).  But it'd be SiC.
>
> Eddy.
>

Completely agreed.


Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Eike Ziller]

> On 27. May 2019, at 12:49, Lars Knoll  wrote:
> 
>> On 27 May 2019, at 11:37, Giuseppe D'Angelo  
>> wrote:
>> 
>> Il 27/05/19 10:24, Simon Hausmann ha scritto:
>>> Hi,
>>> I’m very much in favor of having QList be an alias for QVector and try it 
>>> out, in qt5, with creator and KDE.
>> 
>> Could someone please summarize where we are inside this thread? Now I'm 
>> completely lost…
> 
> My summary would be as follows:
> 
> * We rename QList to QArrayList
>   * We can still discuss whether it should rather be Qt5::QList
> * QStringList and QBAList will be implemented using QVector
> * QList becomes an alias to QVector in wip/qt6 (for now at least)
> * We delay the decision on what QList will be in Qt 6 for a little while
> * QVector for Qt 6 will most likely be updated with the changes Thiago has 
> waiting since quite some years

What is the summary for these?

> * To be able to reach a decision:
>   * we test some Qt libs and apps with QList being an alias to QVector
>   * We know that the only source incompatibility is the stability of 
> references

At least the following are source incompatibilities currently (though easily 
noticeable because they generate compile errors):

- QVector doesn’t have to/fromSet, to/fromStdList or (obviously) to/fromVector
- QVector requires the value type to be default constructible 

>   * If it turns out that most of Qt and (maybe also KDE) run without 
> problems with QList = QVector, we should IMO go down that route.
>   * The reason is that aliasing those classes will resolve many other 
> problems we could otherwise run into
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
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

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

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 27 May 2019, at 11:37, Giuseppe D'Angelo  wrote:
> 
> Il 27/05/19 10:24, Simon Hausmann ha scritto:
>> Hi,
>> I’m very much in favor of having QList be an alias for QVector and try it 
>> out, in qt5, with creator and KDE.
> 
> Could someone please summarize where we are inside this thread? Now I'm 
> completely lost…

My summary would be as follows:

* We rename QList to QArrayList
* We can still discuss whether it should rather be Qt5::QList
* QStringList and QBAList will be implemented using QVector
* QList becomes an alias to QVector in wip/qt6 (for now at least)
* We delay the decision on what QList will be in Qt 6 for a little while
* QVector for Qt 6 will most likely be updated with the changes Thiago has 
waiting since quite some years
* To be able to reach a decision:
* we test some Qt libs and apps with QList being an alias to QVector
* We know that the only source incompatibility is the stability of 
references
* If it turns out that most of Qt and (maybe also KDE) run without 
problems with QList = QVector, we should IMO go down that route.
* The reason is that aliasing those classes will resolve many other 
problems we could otherwise run into

Cheers,
Lars

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

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 27/05/19 10:24, Simon Hausmann ha scritto:

Hi,

I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.


Could someone please summarize where we are inside this thread? Now I'm 
completely lost...


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Edward Welbourne]

сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
 Repeat after me: default ctors do _not_ establish a valid value.

As an aged C programmer I can respect that ;^>

On 2019-05-25 17:24, Konstantin Ritt wrote:
>>> Perhaps you mean "trivial type's default ctors do _not_ establish a
>>> valid value"?

сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development 
mailto:development@qt-project.org>>:
>> No, I actually meant default ctor. What should the default value be?
>> _Obviously_ zero-initialisation. But oh, no, QSize is different. So
>> maybe it's not _quite_ so obvious what the default value is. Why is
>> pen's default value a black solid line instead of NoPen? Why is
>> QBrush's default ctor not solid black, but NoBrush? See? It's just
>> nonsense to try to pick a default value, so this is to say: Don't
>> try.
>>
>> There's exactly one exception: containers. _Clearly_ no-one would
>> _ever_ expect a container to start out anything but empty.

Indeed.

Konstantin Ritt (26 May 2019 10:51) replied:
> Sure we should force a no-op default ctor where possible, and provide
> some helper code that returns a valid default/specialized value of
> that type where {0} isn't enough or non-intuitive
> (i.e. QQuaternion::identity(), QRect::empty(), QSize::invalid()).

(I can't help but wonder whether QRect::empty() should take a point at
which to place its empty rectangle.  An animated rectangle that shrinks
and expands repeatedly [0] shouldn't forget its location at the moment
when it is transiently empty, so empty rectangles at distinct locations
are distinct.  But I'm unfamiliar with QRect, so maybe not.)

[0] example (in SVG), remembering position and orientation while empty:
http://www.chaos.org.uk/~eddy/img/geom/transpyth.svg

> There could [be] more exceptions when we're talking about non-trivial
> types, at least some of them could be resolved by providing
> convenience/helper initializers.

Many types need an invalid value (this is the current default for
QDate, QTime, QDateTime and QTimeZone).  But not all.

For arithmetic types, up to and including QQuaternion and matrices,
you'll need a zero-value; many (including square matrices) shall also
need a unit value.  While zero is a natural default, being explicit is
good; and standard integral/floating types don't default to it.

Various others are (at present) constructed with default values.  In the
case of QLocale, that can be controlled by calling a static method,
QLocale::setDefault(), and we'd need to add (as someone tried to do a
little while ago) a QLocale::defaultLocale() or QLocale::getDefault() to
get that (note that we can't use the name QLocale::default() as it's a
reserved word) if we stopped making the default constructor produce it.
Note that QLocale's default isn't the same thing as QLocale::system(),
although it starts out so, until setDefault() is called.

We're not particularly consistent about what default construction
produces; sometimes undefined, sometimes defined but invalid, sometimes
a zero, sometimes a "reasonable" default.  Which, as Marc tripped over,
is a source of confusion for authors of client code.  Having static
methods to return invalid, zero, unit, default values could be made a
consistent pattern, with consistent naming, to reduce confusion.

We can, of course, do that without changing what the default-constructed
objects are, but changing that also to a consistent pattern - the same
as the moved-from state - would make matters clearer (for any choice of
what moved-from state to consistently use).  But it'd be SiC.

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

[Development] Qt 5.12.4 changes files

[Jani Heikkinen]

Hi,
Initial ones here: 
https://codereview.qt-project.org/q/message:%2522Add+changes+file+for+Qt+5.12.4%2522+status:open

Maintainers, please do needed modifications & make sure reviews are done during 
this week

br,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit is back

[Jukka Jokiniva]

Hi,

Search "commit:thesha1", like 
https://codereview.qt-project.org/q/commit:a5bc7c8d7e790739326cc250f2290dd7cf3225be
More search options here: 
https://gerrit-documentation.storage.googleapis.com/Documentation/2.16.7/user-search.html

--Jukka


On 27/05/2019, 11.07, "Liang Qi"  wrote:

Gerrit admins,

Thanks for the upgrade.

I like MERGE_LIST feature very much, 
https://codereview.qt-project.org/c/qt/qtbase/+/262306/5..6//MERGE_LIST

But I have one question, when I search a sha1 of one commit, the old gerrit 
only shows the change itself, the new gerrit will also show all changes which 
have comments of that sha1. How should I do if I only want to get the change 
itself? Thanks.

Best regards,
Liang

> On 20 May 2019, at 15:00, Jukka Jokiniva  wrote:
> 
> Dear all,
> 
> we are happy to inform you that Gerrit and COIN are back online and all 
operation can resume. All access has been restored.
> Please refer to the public wiki for further information, 
https://wiki.qt.io/Gerrit_Upgrade_2019.
> 
> Bug reports and improvement ideas can be reported to bugreports.qt.io 
(project=QTQAINFRA component= Gerrit). Here is a tiny link: 
http://tiny.cc/new-qt-gerrit-issue
> 
> Best regards,
> your friendly Gerrit admin team.
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development



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

Re: [Development] QList for Qt 6

[Simon Hausmann]

Hi,

I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.


Simon

On 27. May 2019, at 10:12, Lars Knoll  wrote:

>> On 25 May 2019, at 00:37, Giuseppe D'Angelo via Development 
>>  wrote:
>> 
>> Il 24/05/19 18:16, Uwe Rathmann ha scritto:
 We're talking about code that users should_stop_  using anyhow,
 and port away from it, right?
>>> Please also consider the situation of 3rd party libraries ( like Qwt ),
>>> that have to support Qt5/Qt6 from the same code base - probably for many
>>> years after Qt6 has been released.
>>> Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even
>>> support Qt3/Qt4 from the same code base, what was a nightmare as you can
>>> imagine.
>>> In my daily work project we also have a set of core libraries, that run
>>> on old hardware with Qt4/QWS and on more recent projects with Qt5.
>> 
>> This is yet another argument in favour of "don't touch QList": codebases 
>> that need compatibility.
> 
> Having QList an alias to QVector would solve almost all of those problems 
> (except for the fear that now unstable references might break some code).
> 
> I’d say we now check on some larger code bases (Qt, Creator and maybe some 
> parts of KDE), how replacing QList with QVector works out in practice. And do 
> a decision after that.
> 
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 25 May 2019, at 00:37, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 24/05/19 18:16, Uwe Rathmann ha scritto:
>>> We're talking about code that users should_stop_  using anyhow,
>>> and port away from it, right?
>> Please also consider the situation of 3rd party libraries ( like Qwt ),
>> that have to support Qt5/Qt6 from the same code base - probably for many
>> years after Qt6 has been released.
>> Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even
>> support Qt3/Qt4 from the same code base, what was a nightmare as you can
>> imagine.
>> In my daily work project we also have a set of core libraries, that run
>> on old hardware with Qt4/QWS and on more recent projects with Qt5.
> 
> This is yet another argument in favour of "don't touch QList": codebases that 
> need compatibility.

Having QList an alias to QVector would solve almost all of those problems 
(except for the fear that now unstable references might break some code).

I’d say we now check on some larger code bases (Qt, Creator and maybe some 
parts of KDE), how replacing QList with QVector works out in practice. And do a 
decision after that.

Lars

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

Re: [Development] Gerrit is back

[Liang Qi]

Gerrit admins,

Thanks for the upgrade.

I like MERGE_LIST feature very much, 
https://codereview.qt-project.org/c/qt/qtbase/+/262306/5..6//MERGE_LIST

But I have one question, when I search a sha1 of one commit, the old gerrit 
only shows the change itself, the new gerrit will also show all changes which 
have comments of that sha1. How should I do if I only want to get the change 
itself? Thanks.

Best regards,
Liang

> On 20 May 2019, at 15:00, Jukka Jokiniva  wrote:
> 
> Dear all,
> 
> we are happy to inform you that Gerrit and COIN are back online and all 
> operation can resume. All access has been restored.
> Please refer to the public wiki for further information, 
> https://wiki.qt.io/Gerrit_Upgrade_2019.
> 
> Bug reports and improvement ideas can be reported to bugreports.qt.io 
> (project=QTQAINFRA component= Gerrit). Here is a tiny link: 
> http://tiny.cc/new-qt-gerrit-issue
> 
> Best regards,
> your friendly Gerrit admin team.
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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