On Monday, 20 May 2019 19:35:03 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > The replacement for QtXml are the streaming classes in QtCore. They've
> > been available for 10 years.
>
> But those are no replacement for the QDom* DOM API. They are also not
> idiomatic SAX, by design. Both
On Monday, 20 May 2019 12:05:58 PDT Allan Sandfeld Jensen wrote:
> I agree. I would consider anything other than deleting or reassigning a
> moved object undefined behavior, so asserting on it seems like a good help
> to users of our APIs.
I agree, but we should leave this as a fallback case,
Thiago Macieira wrote:
> The replacement for QtXml are the streaming classes in QtCore. They've
> been available for 10 years.
But those are no replacement for the QDom* DOM API. They are also not
idiomatic SAX, by design. Both those limitations make them an insufficient
replacement for QtXml
On Monday, 20 May 2019 15:41:16 PDT Bernhard Lindner wrote:
> Hi!
>
> Is it correct that the Qt XML and Qt Xml Patterns components are both
> deprecated?
Yes, they are.
>
> If yes, are there any details known like:
> - How long or up to which Qt version will these components be part of Qt?
> -
Hello everyone,
Is there any current support/plan to support HDR pixel formats within Qt?
Thanks,
Quinn Romanek
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hey wait, I knew that at one point in time. I've been using Qt since 3.3. I
can't keep track of all the magic under the hood.
I just hope i was right about the rest. And some judge things based off me. I
am violently thrown around between Qt, Python, Java, JavaScript projects. It's
a miracle
Hi!
Is it correct that the Qt XML and Qt Xml Patterns components are both
deprecated?
If yes, are there any details known like:
- How long or up to which Qt version will these components be part of Qt?
- Will replacment components be available?
- Are security fixes still be implemented?
- Are
On Montag, 20. Mai 2019 22:58:49 CEST Konstantin Shegunov wrote:
> On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen
>
> wrote:
> > On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > > state.
> There is no readability difference between the use of a Qt container and
> that of an STL container. Don't confuse familiarity with
> simplicity.
That is true. You can get familiar with both, STL and foot fungus over time.
But both will
remain disturbing forever ;-)
I used STL from time
Il 20/05/19 22:58, Konstantin Shegunov ha scritto:
I agree as well, although I have a minor nitpick. Q_ASSERT works only if
it was not stripped while building Qt. Meaning that I'm often working,
as I'm sure other users, on Linux especially, with the default (i.e.
release) version of Qt from
On Mon, May 20, 2019 at 11:23:13PM +0200, Mutz, Marc via Development wrote:
> On 2019-05-20 23:21, André Pönitz wrote:
> > > > Exhibit A:
> > > >
> > > > foo().contains(x)
> > > >
> > > >
> > > > Exhibit B:
> > > >
> > > > {
> > > > ... container = foo();
> > > >
On Tue, May 21, 2019 at 12:27 AM André Pönitz wrote:
> > Somehow *suggest* to the user that [s]he's supposed to build in
> > debug mode otherwise they're on their own?
>
> Nobody forces you to use Q_ASSERT.
>
Now you lost me. I don't, it was suggested as a means to prevent at-library
site
On Mon, May 20, 2019 at 11:58:49PM +0300, Konstantin Shegunov wrote:
> I agree as well, although I have a minor nitpick. Q_ASSERT works only if it
> was not stripped while building Qt. Meaning that I'm often working, as I'm
> sure other users, on Linux especially, with the default (i.e. release)
>
On 2019-05-20 23:21, André Pönitz wrote:
On Mon, May 20, 2019 at 10:48:29PM +0200, Mutz, Marc via Development
wrote:
On 2019-05-20 22:18, André Pönitz wrote:
> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
> wrote:
> > [...] There is no readability difference between the
On Mon, May 20, 2019 at 10:48:29PM +0200, Mutz, Marc via Development wrote:
> On 2019-05-20 22:18, André Pönitz wrote:
> > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
> > wrote:
> > > [...] There is no readability difference between the use of a Qt
> > > container and
> >
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <
development@qt-project.org> wrote:
> All I'm saying is that there are tons of examples (QGradient) where the
> use of an owning container in the API is just a very bad idea and limits
> the implementor's freedom and/or performance.
On Mon, May 20, 2019 at 08:44:47PM +, Marco Bubke wrote:
> On May 20, 2019 22:16:11 André Pönitz wrote:
>
> > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> >> [...] There is no readability difference between the use of a Qt container
> >> and
> >> that of an
On Mon, May 20, 2019 at 10:07 PM Allan Sandfeld Jensen
wrote:
> On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> > Where we still, maybe, disagree, is whether d == nullptr is a valid
> > state. The difference is whether member functions other then destruction
> > and
On 2019-05-20 22:18, André Pönitz wrote:
On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development
wrote:
[...] There is no readability difference between the use of a Qt
container and
that of an STL container.
Exhibit A:
foo().contains(x)
Exhibit B:
{
...
On May 20, 2019 22:16:11 André Pönitz wrote:
> On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
>> [...] There is no readability difference between the use of a Qt container
>> and
>> that of an STL container.
>
> Exhibit A:
>
> foo().contains(x)
>
>
> Exhibit B:
On 2019-05-20 12:48, Lars Knoll wrote:
So you should give people the option to implement their 5% code that’s
performance critical in a fast way and make it as easy as possible for
them to implement the remaining 95%.
I fully agree. The problem is that Qt as a library doesn't know where
these
C++ standart is a software and like any software, it has bugs.
It’s good that «auto_ptr» bug was fixed among with auto a {42};
However, reading the dev list it seems that people claim that *everything* that
is done by the Committee is a bug and there’s only the «Qt way» of doing things
like it
On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> [...] There is no readability difference between the use of a Qt container and
> that of an STL container.
Exhibit A:
foo().contains(x)
Exhibit B:
{
... container = foo();
On Fri, May 17, 2019 at 07:47:55AM +0200, Mutz, Marc via Development wrote:
> On 2019-05-16 23:41, Konstantin Shegunov wrote:
> > you end up where the STL is - so convoluted it's hardly worth making
> > anything with it.
>
> Qt is a C++ library. If you don't like C++, either stay in QML or use
Il 20/05/19 20:36, André Pönitz ha scritto:
I actually think we should consider getting rid of shared_null and
instead have d == nullptr as the null/default constructed state of the
object. Yes, that means we need to check for d == nullptr in member
functions, but I don’t think the overhead is a
On Freitag, 2. November 2018 08:51:22 CEST Lars Knoll wrote:
> Renaming the subthread (it’s got nothing to do with build systems…)
>
> I believe I have a solution to get rid of QList without breaking SC in any
> major way. See https://codereview.qt-project.org/#/c/242199/ and the
> following
On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote:
> On 2019-05-20 17:16, Thiago Macieira wrote:
> > On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
> >> Or maybe we don't disagree at all and Thiago would accept allocating
> >> memory (or, by extension,
On Mon, May 20, 2019 at 01:56:56PM +, Lars Knoll wrote:
> > On 20 May 2019, at 14:51, Mutz, Marc via Development
> > wrote:
> >
> > On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
> >> Hi, Il 19/05/19 18:54, Thiago Macieira ha scritto:
> >>> But I think all Qt classes should go
On 2019-05-20 17:16, Thiago Macieira wrote:
On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
Or maybe we don't disagree at all and Thiago would accept allocating
memory (or, by extension, anything that's noexcept(false)) as a very
good reason to have a nullptr d?
I hadn't
This rather nicely proves my point. Jason isn't even new to this list and
he didn't realize the problems.
No, community as a whole did _not _ have "years and years" to port away
from QList
On Mon, May 20, 2019 at 6:07 PM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:
> > QList is
20.05.2019, 19:58, "Bastiaan Veelo" :
> On 20/05/2019 17:56, Konstantin Tokarev wrote:
>> 20.05.2019, 18:27, "Bastiaan Veelo" :
>>> On 20/05/2019 16:51, Konstantin Tokarev wrote:
Note that it should be possible to rebuild QtTools with QtWebKit
support,
for example this
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
I actually think we should consider getting rid of shared_null and
instead have d == nullptr as the null/default constructed state of
the object. Yes, that means we need to check for d == nullptr in
member functions, but I
On 20/05/2019 17:56, Konstantin Tokarev wrote:
20.05.2019, 18:27, "Bastiaan Veelo" :
On 20/05/2019 16:51, Konstantin Tokarev wrote:
Note that it should be possible to rebuild QtTools with QtWebKit support,
for example this configuration is supported in Gentoo out of the box.
Interesting,
On 20.05.19 17:27, Konstantin Tokarev wrote:
20.05.2019, 18:21, "Thiago Macieira" :
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
I actually think we should consider getting rid of shared_null and instead
have d == nullptr as the null/default constructed state of the object. Yes,
Paul Wicking (16 May 2019 23:21) wrote
> +1
>
> Disclaimer: I sit on the other side of the wall from him.
+1
Disclaimer: I used to sit on the other side of a wall from him.
Eddy.
___
Development mailing list
Development@qt-project.org
20.05.2019, 18:27, "Bastiaan Veelo" :
> On 20/05/2019 16:51, Konstantin Tokarev wrote:
>> 20.05.2019, 16:02, "Bastiaan Veelo" :
>
> [...]
>>> Qt Assistant officially only renders content with QTextBrowser
>>> currently, which is too limited for many of us[1]. There are still
>>> traces of
20.05.2019, 18:21, "Thiago Macieira" :
> On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
>> I actually think we should consider getting rid of shared_null and instead
>> have d == nullptr as the null/default constructed state of the object. Yes,
>> that means we need to check for d ==
On 20/05/2019 16:51, Konstantin Tokarev wrote:
20.05.2019, 16:02, "Bastiaan Veelo" :
[...]
Qt Assistant officially only renders content with QTextBrowser
currently, which is too limited for many of us[1]. There are still
traces of greater WebKit times, but that code remains unused after
On Monday, 20 May 2019 01:50:03 PDT Florian Bruhin wrote:
> What about using Gerrit to do so? I'm not sure how the repository would look
> (probably just text files with the proposal text)? Then people could +1
> that change instead.
I'm neutral on this, so long as the announcement of the
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
> I actually think we should consider getting rid of shared_null and instead
> have d == nullptr as the null/default constructed state of the object. Yes,
> that means we need to check for d == nullptr in member functions, but I
> don’t think
On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote:
> Or maybe we don't disagree at all and Thiago would accept allocating
> memory (or, by extension, anything that's noexcept(false)) as a very
> good reason to have a nullptr d?
I hadn't thought of noexcept, but let's be clear:
> QList is just a linked list
you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html
On Mon, May 20, 2019 at 5:03 PM Jason H wrote:
>
> > Ok, QList as an alias for QVector takes care of the technical issues I
> > have with using inheritance. It doesn't address my concerns
> Ok, QList as an alias for QVector takes care of the technical issues I
> have with using inheritance. It doesn't address my concerns regarding
> breaking QList behaviour. What purpose is served to call something QList
> that is in fact a QVector? Please spell it out for me, as I don't see
> it.
20.05.2019, 16:02, "Bastiaan Veelo" :
> Hi,
>
> I am prepared to do some work on Qt Assistant, and I'd like to know how
> that will be received.
>
> Qt Assistant officially only renders content with QTextBrowser
> currently, which is too limited for many of us[1]. There are still
> traces of
On 2019-05-20 15:52, Lars Knoll wrote:
Hi Marc,
On 20 May 2019, at 14:39, Mutz, Marc via Development
wrote:
Hi Lars,
I'm on record for claiming QList needs to die, and I work for a
company that still makes part of its living by porting Qt 3 apps to
Qt 4 (and 5). So I should be celebrating
My only conern about QList/QVector is a minor one: that the api be more accomodating to cross-language people. push()/append(), size() and length/length().
Now that Qt is thoroughly supporting Python, and JS, and C++ , and implicit conversions, having an API that is normal for any of the
Hi all, IMHO, the previous WEB interface looks better (has more
usability) than a new...
20.05.2019 16:54, Lars Knoll пишет:
Hi Jukka,
Thank you and everybody else that helped for making the upgrade!
Cheers,
Lars
On 20 May 2019, at 15:00, Jukka Jokiniva wrote:
Dear all,
we are happy to
> On 20 May 2019, at 14:51, Mutz, Marc via Development
> wrote:
>
> On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
>> Hi,
>> Il 19/05/19 18:54, Thiago Macieira ha scritto:
>>> But I think all Qt classes should go beyond that, unless they have VERY good
>>> reasons not to do so
Hi Jukka,
Thank you and everybody else that helped for making the upgrade!
Cheers,
Lars
> 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
Hi Marc,
On 20 May 2019, at 14:39, Mutz, Marc via Development
mailto:development@qt-project.org>> wrote:
Hi Lars,
I'm on record for claiming QList needs to die, and I work for a company that
still makes part of its living by porting Qt 3 apps to Qt 4 (and 5). So I
should be celebrating if
> On 20 May 2019, at 15:00, Jukka Jokiniva wrote:
>
> 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
And here’s a filte for open issues
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
Hi,
I am prepared to do some work on Qt Assistant, and I'd like to know how
that will be received.
Qt Assistant officially only renders content with QTextBrowser
currently, which is too limited for many of us[1]. There are still
traces of greater WebKit times, but that code remains unused
For the record: I would also prefer QList to vanish from Qt's interfaces
rather than change its meaning everywhere it's used.
Better have explicit porting than subtle hard to track bugs.
On Mon, May 20, 2019 at 3:41 PM Mutz, Marc via Development <
development@qt-project.org> wrote:
> Hi Lars,
>
On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
Hi,
Il 19/05/19 18:54, Thiago Macieira ha scritto:
But I think all Qt classes should go beyond that, unless they have
VERY good
reasons not to do so (and document so). The moved-from object should
also be
in a valid state so all
Hi Lars,
I'm on record for claiming QList needs to die, and I work for a company
that still makes part of its living by porting Qt 3 apps to Qt 4 (and
5). So I should be celebrating if you create more potential work for
KDAB, but I'm actually ok with keeping QList.
Provided it vanishes from
That's not equal to directly discouraging the use of qlist. Especially
since they have different interfaces.
That's "blah blah blah, if you are interested in details blah blah blah"
I've read it, not everyone did, I am sure of it. And it's not equal to
directly stating: "if you continue using
https://doc.qt.io/qt-5/qlist.html#details
QVector should be your default first choice. QVector will usually give
better performance than QList, because QVector always stores its items
sequentially in memory, where QList will allocate its items on the heap
unless sizeof(T) <= sizeof(void*) and
And on the matter of "you should have read all the discussions so you had
years to port away from QList"
I am sorry, what? QList was never indicated as deprecated or somehow
undesirable in Qt docs far as I know and not every developer actively reads
these topics.
Moreover with all the discussions
I was speaking strictly of the cases where users already have auto used in
their code _expecting it to signify owning container_.
Imagine if they expect ownership in these cases. If the actual owning
container that exists somewhere else somehow goes out of scope
when the user expected to own it
Hi Marc,
> On 16 May 2019, at 15:05, Mutz, Marc via Development
> wrote:
>
> Hi Lars,
>
> On 2018-11-02 08:51, Lars Knoll wrote:
>> I believe I have a solution to get rid of QList without breaking SC in
>> any major way. See https://codereview.qt-project.org/#/c/242199/ and
>> the following
> On 17 May 2019, at 21:12, Giuseppe D'Angelo via Development
> wrote:
>
> Il 17/05/19 16:46, Bernhard Lindner ha scritto:
>>> I've done this experiment for QMap / QHash / QSet, where keeping COW at
>>> the cost of an extra indirection (dptr -> [refcount + std:: class] ->
>>> actual data) is
> On 17 May 2019, at 07:47, Mutz, Marc via Development
> wrote:
>
> On 2019-05-16 23:41, Konstantin Shegunov wrote:
>> you end up where the STL is - so convoluted it's hardly worth making
>> anything with it.
>
> Qt is a C++ library. If you don't like C++, either stay in QML or use Java.
>
+1 from me as well.
Best regards,
Timur.
From: Development [development-boun...@qt-project.org] on behalf of Topi Reiniö
[topi.rei...@qt.io]
Sent: Monday, May 20, 2019 12:26 PM
To: Qt development mailing list
Subject: Re: [Development] Nominating
+1
\topi
From: Development on behalf of Volker
Hilsheimer
Sent: Thursday, May 16, 2019 4:45 PM
To: Qt development mailing list
Subject: [Development] Nominating Mikhail Svetkin for Approver status
Hi,
I’d like to nominate Mikhail Svetkin for Approver status.
Hi,
Qt Design Studio 1.2 is released today, see
https://blog.qt.io/blog/2019/05/17/qt-design-studio-1-2-beta-released/
Big thanks to everyone involved!
Best Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
Hi,
As you may have noticed CI has been up and running again for a while now. We
had some dhcp problems which are solved now.
Br
Heikki
From: Heikki Halmet
Sent: sunnuntai 19. toukokuuta 2019 21.25
To: Qt Development ; development@qt-project.org
Subject: CI is down
Hi,
CI environment is
On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov wrote:
>> If a user needs a regular container, range might be simply assigned to it.
NIkolai Marchenko (16 May 2019 20:38) replied
> It depends on what you expect the average usecase to be.
> If we assume that a regular container is generally
Hi,
Il 19/05/19 18:54, Thiago Macieira ha scritto:
But I think all Qt classes should go beyond that, unless they have VERY good
reasons not to do so (and document so). The moved-from object should also be
in a valid state so all the accessor and mutation API in the class can operate
in the
+1 :P
It’s of course nice for people that are proposed to see that they have support
from the community, but using Gerrit would provide that.
Having authorisation controlled through a version-controlled configuration file
that implicitly generates a tracable and auditable changelog is much
+1.
We could have a document (maybe the README) with the list of current
approvers/maintainers and submit a change request adding a new approver.
And, after testing the new Gerrit, I would love to use Gerrit more for decision
making. The conversation workflow in Gerrit improved a lot in the
Hi,
As someone who's following this list but not working at the Qt Company, I find
the stream of "+1" emails when there's a new proposal for approval rights for
someone a bit noisy :)
What about using Gerrit to do so? I'm not sure how the repository would look
(probably just text files with the
+1
Mårten
Fra: Development på vegne av Volker
Hilsheimer
Sendt: Thursday, May 16, 2019 4:45:19 PM
Til: Qt development mailing list
Emne: [Development] Nominating Mikhail Svetkin for Approver status
Hi,
I’d like to nominate Mikhail Svetkin for Approver
+1
Mårten
Fra: Development på vegne av Simon
Hausmann
Sendt: Friday, May 17, 2019 2:38:10 PM
Til: development@qt-project.org
Emne: Re: [Development] Nominating Ryan Chu for Approvership
+1
Simon
From: Development on behalf
74 matches
Mail list logo
