The upgrade was completed. Please let jira-ad...@qt-project.org know if you run
into problems due to the upgrade.
--
Alex
From: Jira-admin on behalf of Alex Blasche
Sent: Monday, 20 April 2020 13:48
To: development@qt-project.org; inter...@qt-project.o
Hi,
On 25-04-20 16:49, André Pönitz wrote:
We all know the story that began with
"We knew for a long time that QList is not a good default
container, despite what the documentation claims. The problem
boils down to the fact that for a lot of types T, QList is
needlessly inef
On Tue, Apr 28, 2020 at 12:25:32AM +0200, Jean-Michaël Celerier wrote:
>> As starters, there are 85 occurences of QList::takeFirst() in Qt
>> Creator source code. Replacing these with QVector replaces a O(1)
>> operation with an O(n) operation.
>
>Apologies if I'm wrong, but isn't Q
> As starters, there are 85 occurences of QList::takeFirst() in Qt Creator
source code. Replacing these with QVector replaces a O(1) operation
with an O(n) operation.
Apologies if I'm wrong, but isn't QList::erase (and anything derivative)
always O(N) ?
With a lower cost than std::vector for thing
On Mon, Apr 27, 2020 at 11:13:26AM -0400, Matthew Woehlke wrote:
> On 25/04/2020 10.49, André Pönitz wrote:
> > We all know the story that began with
> >
> > "We knew for a long time that QList is not a good default
> > container, despite what the documentation claims. The problem
> >
Hi,
I looked at the patch again and searched a bit around. I think nl_langinfo is
“broken” on macOS but it doesn’t matter: everything seems to be utf-8, all
system APIs expect it. I think the CI is well configured and the patch should
treat Darwin like Android :-)
Simon
Am 27.04.2020 um 19:09
Hi,
I can't really think of anything that's changed in the default macOS setup that
would affect the locale encoding.
The scripts that are run are here:
https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/qtci-macos-10.14-x86_64
but I'm not even sure that it's possible to "misconfig
On Sunday, 26 April 2020 09:22:00 PDT Thiago Macieira wrote:
> On Thursday, 31 October 2019 14:11:05 PDT Thiago Macieira wrote:
> > Re: https://codereview.qt-project.org/c/qt/qtbase/+/275152 (WIP: Move
> > QTextCodec support out of QtCore)
> > See also: https://www.python.org/dev/peps/pep-0538/
> >
On 25/04/2020 10.49, André Pönitz wrote:
We all know the story that began with
"We knew for a long time that QList is not a good default
container, despite what the documentation claims. The problem
boils down to the fact that for a lot of types T, QList is
needlessly ineffic
Hi,
It is time to start freezing Qt 6.0.0 initial schedule. I have had some
discussion and based on those here is the initial schedule for Qt 6.0.0:
- Qt 6.0 Feature freeze 31.8.2020
- Qt 6.0 Alpha 14.9.2020
- Qt 6.0 Beta 1 1.10..2020
- Qt 6.0.0 RC 17.11.2020
- Qt 6.0.0 Final 1.12.2020
And in
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
Moving to one year release approach doesn't equal to make Qt less
stable.
> Ville:
>>> Of course it does, if we now allow API breaks every year.
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote:
>> Not necessarily: if we *allow* API break
Hi Simon
yes that worked, didn’t know about Q_MOC_INCLUDE
Thanks!
PS: seems Creator’s syntax highlighter doesn’t know about it either :)
> On 27 Apr 2020, at 11:08, Simon Hausmann wrote:
>
> Hi,
>
> I think the solution may involve keeping forward-declarations but adding
> visibility to
Hi,
the current solution in our repositories is to use the Q_MOC_INCLUDE(X) macro,
which causes moc to write an #include X directive in the generated file. This
avoids having to do the include in the header (which as you noticed isn't
always possible).
We're aware of the issues, and there was
Hi,
I think the solution may involve keeping forward-declarations but adding
visibility to the "other" types in moc generated code by using Q_MOC_INCLUDE in
A to include B and vice versa. Does that make sense?
Simon
From: Development on behalf of Mike Krus
vi
Hi
I have 2 classes, A and B, derived from QObject, each have a property
of type pointer-to-other-class. So
class A : public QObject {
Q_PROPERTY(B *foo …)
…
};
And:
class B : public QObject {
Q_PROPERTY(A *foo …)
…
};
Because of the circular dependency, I can’t #include the full class
definit
On Mon, 27 Apr 2020 at 10:10, Alberto Mardegan
wrote:
>
> On 23/04/20 14:57, Ville Voutilainen wrote:
> > QVector is certainly closer to std::vector than QList is to std::list.
> > Vector isn't a really good name either,
> > for people recently taught in elementary school math, or for java
> > pro
On 23/04/20 14:57, Ville Voutilainen wrote:
> QVector is certainly closer to std::vector than QList is to std::list.
> Vector isn't a really good name either,
> for people recently taught in elementary school math, or for java
> programmers coming in.
> For C++ programmers, it gives a much better s
17 matches
Mail list logo
