On 4/23/20 15:52, Thiago Macieira wrote:
Proposed:
template using QVector = QList; // mark deprecated
template class QList { $(implementation to be moved); }
Proposal 2:
template class QList { $(implementation to be moved); }
template using QVector = QList;
no deprec
On Fri, 24 Apr 2020 at 00:13, Vitaly Fanaskov wrote:
> How often do you think we can play this game until people look for
> something they consider more stable?
>
> Moving to one year release approach doesn't equal to make Qt less stable.
Of course it does, if we now allow API breaks every year.
One year for a major Qt release and then break API?
I didn't say that.
The thing is that there will be much less changes for one year. It means that
you need to do less job to switch a version. I hope it also will lead to more
careful feature planning and API design. With shorter release cycle it
Am Do., 23. Apr. 2020 um 21:01 Uhr schrieb Giuseppe D'Angelo via
Development :
>
> On 4/23/20 6:54 PM, Manuel Bergler wrote:
> >> This is a documentation bug or a Creator bug. You're supposed to land on
> >> this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
> > Technically this
On 2020-04-23 14:55, Thiago Macieira wrote:
On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
Provide clang-based tools to (semi-)automatically port users' code
bases to
a new version of Qt. These tools might either fix a code or at least
add a
comment in potentially problematic pl
On 23/04/2020 10.45, Giuseppe D'Angelo via Development wrote:
(Otherwise, "list" in Python is heterogeneous, why isn't QList
heterogeneous?)
That doesn't count; *variables* in Python are heterogeneous.
a = 5 # type(a) == int
a = 'foo' # type(a) == str
It should not surprise one that
On 4/23/20 6:54 PM, Manuel Bergler wrote:
This is a documentation bug or a Creator bug. You're supposed to land on
this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
Technically this is the correct place to land on, but it isn't
helpful. Just like Julius, if I have a container
On 23/04/2020 05.30, Ville Voutilainen wrote:
On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of
that.
Indeed. In Qt5, QList is sometimes a list,
sometimes a vector, but in Qt6 it's never a list.
Correction: in Qt5,
A development release of version 2.5 of the Qt VS Tools is now available.
(Changelog:
https://code.qt.io/cgit/qt-labs/vstools.git/tree/Changelog?id=0048dbab02ca6ee81dd3b27ff1525e02ce756ac7
)
Installation packages for v2.5.0 can be downloaded from:
https://download.qt.io/development_releases
On Thu, Apr 23, 2020 at 04:45:02PM +0200, Giuseppe D'Angelo via Development
wrote:
> On 4/23/20 1:20 PM, Edward Welbourne wrote:
> > So how much harm does it really cause, to keep both names; and use
> > whichever feels like the more natural description of the value one is
> > returning ?
>
> I m
Am Do., 23. Apr. 2020 um 18:07 Uhr schrieb Giuseppe D'Angelo via
Development :
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another suggestion: Get rid if the aliases; use the fully-qualified
> > types instead.
> >
> > I'm always irritated if I open the documentation of QVariantList from
> >
On 4/23/20 5:04 PM, Julius Bullinger wrote:
Another suggestion: Get rid if the aliases; use the fully-qualified
types instead.
I'm always irritated if I open the documentation of QVariantList from
within Qt Creator, and land on the QVariant docu instead. I'm interested
in the features of the con
On Thu, Apr 23, 2020 at 05:04:27PM +0200, Julius Bullinger wrote:
> On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:
> > == Naming of functions and types if QList = QVector ==
> >
> > We have QStringList, QVariantList and friends, which are aliases /
> > subclasses of QList and so on.
On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
>
>I read the entire discussion,
On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:
== Naming of functions and types if QList = QVector ==
We have QStringList, QVariantList and friends, which are aliases /
subclasses of QList and so on.
Should they become QStringVector, QVariantVector; and the *List names
stay, a
1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot
work in all cases either.
That's true, but on the other hand, covering at least a half of code bases
would be a huge progress. I don't have representative statistics, but I guess
that the real percentage will be larger.
Hi,
You're right, I was mistaken. I tried the virtual method API change locally and
it works with the aliasing, either way. So it's only a problem if we combined
it with deprecation and asked our users to move over while they want to
maintain compatibility with both versions of Qt. Thiago's pro
On 4/23/20 1:20 PM, Edward Welbourne wrote:
So how much harm does it really cause, to keep both names; and use
whichever feels like the more natural description of the value one is
returning ?
I missing the bigger picture about this thread. What are we trying to
assess / solve?
== Source co
Hi,
I think your proposal is fine, too - still counts as something that improves
the situation for our users and our API. And they'd certainly appreciate one
deprecation warning less ;-)
Simon
From: Development on behalf of Thiago
Macieira
Sent: Thursday, Ap
On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
> Provide clang-based tools to (semi-)automatically port users' code bases to
> a new version of Qt. These tools might either fix a code or at least add a
> comment in potentially problematic places where a user should correct the
> cod
On Thursday, 23 April 2020 02:15:29 PDT Simon Hausmann wrote:
> Proposed:
>
> template using QVector = QList; // mark deprecated
> template class QList { $(implementation to be moved); }
Proposal 2:
template class QList { $(implementation to be moved); }
template using QVecto
On Thursday, 23 April 2020 01:41:54 PDT Laszlo Agocs wrote:
> -1 for QList. Why reuse and prioritize a name that has been tainted by
> plenty of past discussions and comes with a lot of past baggage? Any Google
> etc. search will bring up plenty of "QList-bad QVector-good" materials for
> years to
Den tors 23 apr. 2020 kl 13:38 skrev André Pönitz :
>
> On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> > Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> > >
> > > That depends on the number of the functions affected, and how commonly
> > > those
> > > are used. If we are t
On 2020-04-23 11:48, List for announcements regarding Qt releases and
development wrote:
We are happy to announce the release of Qt Creator 4.12!
https://www.qt.io/blog/qt-creator-4.12-released
Thank you! I like the new Restart feature, i.e. when you switch Theme,
say from Flat Light to Flat D
I think we should completely remove QList in Qt6. It was planned before, as far
as I remember. The main reason is to be consistent with STL wording and do not
violate POLA too much.
I read the entire discussion, and I'd like to say this one more time: we don't
have to fight the consequences. Be
Hi everyone,
Coin version 1.4 has gone thorough testing process and a Coin production update
is scheduled for tomorrow 24.4.2020 at 1pm CEST. In the update the Coin
instance is moved to another host. This causes all modules to be rebuilt as
storage is not transferred in the process. The rebuild
On 23-04-20 12:49, Mitch Curtis wrote:
-Original Message-
From: Development On Behalf Of
André Somers
Sent: Thursday, 23 April 2020 12:04 PM
To: Jaroslaw Kobus ; development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi,
On 23-04-20 11:58, Jaroslaw K
> On 23 Apr 2020, at 11:30, Ville Voutilainen
> wrote:
>
> On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
>>
>> Almost all the time I second your positions, but not this time ;)
>>
>> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid
>> of that.
>
> Indeed. QList
On Thu, 23 Apr 2020 at 14:28, André Pönitz wrote:
>
> On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> > On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
> > >
> > > Almost all the time I second your positions, but not this time ;)
> > >
> > > QList is historically a cause of amb
On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> >
> > That depends on the number of the functions affected, and how commonly those
> > are used. If we are talking about just a few virtual functions here and
> > there
> > which
Hi all,
Branching from '5.15' to '5.15.0' is now done. So from now on all changes
targeted to Qt 5.15.0 release must to be done in '5.15.0' and '5.15' is for Qt
5.15.1.
As usual no any nice-to-haves in '5.15.0' anymore. Target is to publish Qt
5.15.0 RC at the end of April and so on we really n
On Thu, Apr 23, 2020 at 12:17:38PM +0200, Daniel Engelke wrote:
>> You'd need also adapt some variable and function names,
>> comments and documentation are silently broken.
>
>I don't really see it, unless you name all variables like qListMyList.
>
>As for comments it's not like
On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
> >
> > Almost all the time I second your positions, but not this time ;)
> >
> > QList is historically a cause of ambiguity, and Qt6 is the chance to get
> > rid of that.
>
> Indee
On Thu, Apr 23, 2020 at 10:02:04AM +0200, André Pönitz wrote:
> On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann wrote:
> >Hi,
> >
> >In dev we've had QVector being an alias for QList for a while now. For
> >the 6.0 release this particular topic (QList/QVector) suggests two
> >
I'm using QList in many cases, per ex:
C++:
QList myList();
QML:
ListView { ... model: xxx.myList()
C++
QVector myList();
getting Error from QML ListView: Unknown method return type:
QVector
(tested with Qt 5.13.2)
perhaps I misunderstood something or will QML in Qt6 have no problems
André Pönitz (23 April 2020 10:52)
> "vector" in this context is a misnomer. It does not "carry" something
> from one place to another,
It is a container, in which values are carried from one piece of code to
another. The same can, of course, be said of every container.
However, that's all that
I wouldn't treat that "List" as type information but rather as "container of
objects" or simply "multiple objects".
Otherwise all functions would need type information in them aka "isActive()"
becomes "isActiveBool()".
Dan
From: Jaroslaw Kobus
To: André Somers , "development@qt-projec
> -Original Message-
> From: Development On Behalf Of
> André Somers
> Sent: Thursday, 23 April 2020 12:04 PM
> To: Jaroslaw Kobus ; development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> Hi,
>
> On 23-04-20 11:58, Jaroslaw Kobus wrote:
> > There
Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
>
> That depends on the number of the functions affected, and how commonly those
> are used. If we are talking about just a few virtual functions here and there
> which are not expected to be overriden by a vast majority of applications
> (such
> You'd need also adapt some variable and function names,
> comments and documentation are silently broken.
I don't really see it, unless you name all variables like qListMyList.
As for comments it's not like the logical meaning changes. Besides, QList will
have QVectors implementation anyway
Hi,
On 23-04-20 11:58, Jaroslaw Kobus wrote:
There are cases, where the name of the function contains the "list", like:
QList QMdiArea::subWindowList(QMdiArea::WindowOrder order =
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList
QLowEnergyAdvertisingParamet
There are cases, where the name of the function contains the "list", like:
QList QMdiArea::subWindowList(QMdiArea::WindowOrder order =
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList
QLowEnergyAdvertisingParameters::whiteList() const;
etc...
So, subWindowLis
We are happy to announce the release of Qt Creator 4.12!
https://www.qt.io/blog/qt-creator-4.12-released
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
S
On Thu, Apr 23, 2020 at 10:52:07AM +0200, Daniel Engelke wrote:
>I don't see a lot of work in string replacing QList with QVector and
>QStringList with whatever it would be, as long as the API is
>compatible.
A proper replacing is not done by replacing one type by another.
You'd need
On 4/23/20 10:55 AM, Simon Hausmann wrote:
So take for example this function in QIconEngine:
virtual QList availableSizes(QIcon::Mode mode =
Icon::Normal, QIcon::State state = QIcon::Off) const;
If we change that to QVector, we require our users to clutter their code
base with #ifdefs. If we
On Thu, Apr 23, 2020 at 10:06:07AM +0200, Albert Astals Cid via Development
wrote:
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> > Hi,
> >
> > In dev we've had QVector being an alias for QList for a while now. For the
> > 6.0 release this particular topic (QLi
On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann wrote:
>Hi,
>
>In dev we've had QVector being an alias for QList for a while now. For
>the 6.0 release this particular topic (QList/QVector) suggests two
>goals (among others):
>
>(1) Use the same type throughout the
On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
>
> Almost all the time I second your positions, but not this time ;)
>
> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid
> of that.
Indeed. QList causes confusion for the uninitiated that are aware of
the differences bet
El dijous, 23 d’abril de 2020, a les 10:27:15 CEST, Simon Hausmann va
escriure:
> Hi Dmitriy,
>
> No, this is not an April's Foolk joke.
>
> Previous discussions were largely centred around the implementations and
> bringing them together. With this thread my concern is the API and the
> churn o
Hi Simon,
On 23-04-20 10:55, Simon Hausmann wrote:
Hi,
So take for example this function in QIconEngine:
virtual QList availableSizes(QIcon::Mode mode =
Icon::Normal, QIcon::State state = QIcon::Off) const;
If we change that to QVector, we require our users to clutter their
code base with
That depends on the number of the functions affected, and how commonly those
are used. If we are talking about just a few virtual functions here and there
which are not expected to be overriden by a vast majority of applications (such
as the QIconEngine example), then changing the signatures is
Hi,
Ah yes, I'm suggesting to keep the implementation in Qt 6, so:
Qt 6 QList == Qt 6 QVector and deprecate Qt 6 Vector.
Or differently put:
Currently:
template class QVector { $(implementation to be moved) }
template using QList = QVector;
Proposed:
template using QVecto
Hi,
I don't see the issue with the search&replace with virtual functions. In Qt 5,
those use QList, so our users will use it there too. In Qt 6, we change it to
QVector, but as QList is an alias of QVector in Qt 6, the user's code (still
using QList) will still work just fine.
Am I missing some
Almost all the time I second your positions, but not this time ;)
QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of
that.
Philippe
On Thu, 23 Apr 2020 07:53:04 +
Lars Knoll wrote:
Ive had similar thoughts lately as well. I can see a few more reasons to keep
> On 2020 Apr 23, at 10:27, Simon Hausmann wrote:
>
> Hi Dmitriy,
>
> No, this is not an April's Foolk joke.
>
> Previous discussions were largely centred around the implementations and
> bringing them together. With this thread my concern is the API and the churn
> our users would have to a
Hi,
So take for example this function in QIconEngine:
virtual QList availableSizes(QIcon::Mode mode = Icon::Normal,
QIcon::State state = QIcon::Off) const;
If we change that to QVector, we require our users to clutter their code base
with #ifdefs. If we keep it with QList but use QVector i
El dijous, 23 d’abril de 2020, a les 10:23:21 CEST, Simon Hausmann va
escriure:
> Hi,
>
> Yes, apologies, QList is an alias for QVector. I propose to switch that
> around.
But keeping which implementation?
I.e. it's not clear if you are suggesting to make
Qt6 QList == Qt5 QVector and deprec
Hi,
If we did the search & replace and use QVector throughout our API, won't that
make it harder for our users to maintain a code base with 5 and 6? For example
if we change the signature of virtual functions.
I think we'd do our users a favour by sticking to QList - I'm not concerned
about th
Hi Simon,
I think having a name that is close to the standard is very important as it
makes it easy to find the Qt counterpart.
Back in the days I had to ask a StackOverflow question to find Qts unique_ptr
(QScopedPointer), because I couldn't find it due to the naming.
Dmitriy also has a very
-1 for QList. Why reuse and prioritize a name that has been tainted by plenty
of past discussions and comes with a lot of past baggage? Any Google etc.
search will bring up plenty of "QList-bad QVector-good" materials for years to
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also
Hi Dmitriy,
No, this is not an April's Foolk joke.
Previous discussions were largely centred around the implementations and
bringing them together. With this thread my concern is the API and the churn
our users would have to apply to their code base in order to use Qt 5 and Qt 6.
Simon
__
Hi,
Yes, the "proximity" of QVector to std::vector is on argument in favour of it.
However I'm not certain that that's worth giving up on the goal of making it
easy to maintain a code base between 5 and 6 with a consistent API in Qt. At
the end of the day we serve our users 🙂
That said, what d
Hi,
Yes, apologies, QList is an alias for QVector. I propose to switch that around.
Simon
From: Development on behalf of Albert
Astals Cid via Development
Sent: Thursday, April 23, 2020 10:16
To: development@qt-project.org
Subject: Re: [Development] Proposal
+1 for QList.
(6) No need to remane QStringList into QStringVector for consistency reasons.
Jarek
From: Development on behalf of Lars Knoll
Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Developm
El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
>
> In dev we've had QVector being an alias for QList for a while now.
It's the other way around, isn't it?
corelib/tools/qcontainerfwd.h:
template using QList = QVector;
Cheers,
Albert
--
Albert Astals Ci
El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
>
> In dev we've had QVector being an alias for QList for a while now. For the
> 6.0 release this particular topic (QList/QVector) suggests two goals (among
> others):
>
> (1) Use the same type throughout the
Hi Simon,
I hope it's not a belated April's Fool joke? As far as I can remember, for
the past few years, one would read everywhere to switch to QVector from
QList because of this and that, and to choose QVector as the default choice
container instead of QList like it was back in the days. I can't
I’ve had similar thoughts lately as well. I can see a few more reasons to keep
QList as the name of the class:
(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need
for people to re-learn Qt
(5) a lot less code churn for us and our
Hi,
In dev we've had QVector being an alias for QList for a while now. For the 6.0
release this particular topic (QList/QVector) suggests two goals (among others):
(1) Use the same type throughout the public API of Qt.
(2) Make it easy for our users to maintain a code base that works wi
69 matches
Mail list logo
