Re: [Development] Qt XML and Qt Xml Patterns

[Thiago Macieira]

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 those limitations make them an insufficient
> replacement for QtXml even for new code, let alone all the existing legacy
> code.

The replacement is not a 1:1 API style and was never meant to. The stream XML 
are StAX, whereas QDomDocument is DOM and QXmlReader is SAX. The point is that 
you can still read and write XML, it's fast and supports namespaces properly.

> Looking around (e.g., in KDE projects and/or related third-party Free
> Software projects), you will find QtXml still widely used, probably even
> more widely than the newer QtCore XML streaming API (depending on your
> sample).

I know. The DOM is extremely useful, which is why I wrote QCborValue (DOM) in 
addition to QCborStream{Reader,Writer} (StAX) and that's why QJsonDocument 
(DOM) is so easy to use.

But the fact is that QDomElement and friends aren't getting maintained.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

[Thiago Macieira]

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, albeit legitimate and 
not too difficult to justify. Here are a couple justifications:

- allocating memory (violates noexcept)
- retaining unknown quantities of memory (in the case of the assignment op)
- complex or slow code
- pessimises code elsewhere

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt XML and Qt Xml Patterns

[Kevin Kofler]

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 even for new code, let alone all the existing legacy 
code.

Looking around (e.g., in KDE projects and/or related third-party Free 
Software projects), you will find QtXml still widely used, probably even 
more widely than the newer QtCore XML streaming API (depending on your 
sample).

Kevin Kofler

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

Re: [Development] Qt XML and Qt Xml Patterns

[Thiago Macieira]

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?
> - Will replacment components be available?

The replacement for QtXml are the streaming classes in QtCore. They've been 
available for 10 years.

There is no replacement for the XMLPatterns module.

> - Are security fixes still be implemented?

Yes, definitely, for as long as we ship them plus 5 years.

> - Are the deprecations irrevocable?

No. Deprecations are only irrevocable when we want to get rid of code that is 
in the way of making progress, such as the QList discussion. Those two modules 
are not in the way of anything else, so the decision can change.

All it takes is someone stepping up to maintain either or both of them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

[Development] HDR Support in Qt

[Quinn Romanek via Development]

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

Re: [Development] QList for Qt 6

[Jason H]

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 that my code works at all.

> Sent: Monday, May 20, 2019 at 7:08 PM
> From: "NIkolai Marchenko" 
> To: "Jean-Michaël Celerier" 
> Cc: "Jason H" , "Qt development mailing list" 
> , "Mutz, Marc" 
> Subject: Re: [Development] QList for Qt 6
>
> 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 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 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.
> >>
> >> My understanding is that QVector requires contiguous memory, consuming a
> >> giant block for all the items in the list. QList is just a linked list.
> >> QVector will fail sooner when memory fragmentation is a problem. I would
> >> expect systems with long-running processes and limited RAM (i.e. embedded,
> >> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> >> especially when the size of each object is large. (You could always just
> >> store pointers though)
> >>
> >>
> >> ___
> >> 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
> >
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt XML and Qt Xml Patterns

[Bernhard Lindner]

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 the deprecations irrevocable?

-- 
Best Regards,
Bernhard Lindner

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

[Allan Sandfeld Jensen]

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. The difference is whether member functions other then destruction
> > > and assignment check for a nullptr d. I'd propose that on classes under
> > > the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the
> > > best balance between safety and speed.
> > 
> > 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 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 the repo. Granted it may be my own fault, but in this
> case the assert isn't tripped and this code simply segfaults for reasons
> that aren't so obvious. Any suggestions how to mitigate that? Somehow
> *suggest* to the user that [s]he's supposed to build in debug mode
> otherwise they're on their own?

If you are using Linux, they typically has debug-packages, and some crash 
handlers (I know at least DrKonqi does), can suggest installing them and 
reloading the backgrace producing even better bugreporting information than 
you began with (even the basic ones would still tell you it is a nullptr 
access and in which function). I don't see how we could improve on that. A log 
entry or graceful error handling or exit would be more likely to missed by 
users.

Q_ASSERT is for developers, it is has nothing to do with end-users. Though 
actually now that I think about it, a developer would get just as good details 
from a nullptr segfault with full debug info, as from a Q_ASSERT, so it might 
not even be needed.


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

Re: [Development] Views

[Bernhard Lindner]

> 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 to time. And I found that it does not matter how often I 
used it...
it still remains hard to read. 

I mean, "pop_back" vs. "removeLast"?! Seriously?! "pop back" sounds funny but 
it is not
easy to read!

I case intuitive naming does not matter for you...
Then compare this thread/answer: https://stackoverflow.com/a/18549053/1421332
With this thread/answer: https://stackoverflow.com/a/421615/1421332
And, LOL, do not skip the comment below the first answer!

Nothing more to say.

-- 
Best Regards, 
Bernhard Lindner

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

[Giuseppe D'Angelo via Development]

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 the repo. Granted it may be my own fault, 
but in this case the assert isn't tripped and this code simply segfaults 
for reasons that aren't so obvious. Any suggestions how to mitigate 
that? Somehow *suggest* to the user that [s]he's supposed to build in 
debug mode otherwise they're on their own?


There is a long standing open feature request against Qt for having 
debug+release builds working on Linux.


TL;DR: we could come up with a Qt-specific solution, not a general 
purpose one (that would require agreement at the FHS level, 
distributions, and some ld.so mechanism à la OSX; in other words, 10 
years). No one wants to get their hands dirty in qmake code though, 
especially given it's dying; maybe something to consider during the 
CMake port.




My 2 c,
--
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] Views

[André Pönitz]

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();
> > > >  std::find(container.begin(), container.end(), x) !=
> > > > container.end();
> > > >  }
> > > 
> > > And now do the same thing [...]
> > 
> > No, I won't.
> > 
> > You were claiming something universally valid (\forall x "There is
> > no difference ...")
> 
> I never said that there's no difference. I said there's no difference in
> readability. Don't confuse familiarity with simplicity (or readability).

Indeed, you claimed only "no difference in readability". 

But I wouldn't agree that there is "no difference in readabilty" between
Exhibit A and B above.

In case B one e.g. would need to check whether all _four_ occurances of
'container' are actually the same. An issue that does not exist in case A.

Andre'
___
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 Shegunov]

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 accessing a partially formed state - i.e. for prevention of touching a
moved-from object that had its d-ptr nulled. I don't have access to the
d-ptr from the outside.
___
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?

[André Pönitz]

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)
> version of Qt from the repo. Granted it may be my own fault, but in this
> case the assert isn't tripped and this code simply segfaults for reasons
> that aren't so obvious. Any suggestions how to mitigate that?

Use your own fallback code that does what you want.

If yoy drive the Mars Rover and have a backup system that can take over
when you fail, signalling your failure early and decisively might be the
way to go (and yes, Q_ASSERT doesn't help in that case).

If you are the only one around, you are the master of ceremony, and
"The Show Must Go On", then doing "something" (logging, returning 
something likely/not completely broken) might be the only way out
(and yes, Q_ASSERT doesn't help in that case either).

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

Andre'

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

Re: [Development] Views

[Mutz, Marc via Development]

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 use of a Qt
> > container and
> > that of an STL container.
>
> Exhibit A:
>
>  foo().contains(x)
>
>
> Exhibit B:
>
>  {
>  ... container = foo();
>  std::find(container.begin(), container.end(), x) !=
> container.end();
>  }

And now do the same thing [...]


No, I won't.

You were claiming something universally valid (\forall x "There is
no difference ...")


I never said that there's no difference. I said there's no difference in 
readability. Don't confuse familiarity with simplicity (or readability).



and when presented a counterexample you jumped
to a "but \exists "There is no difference ..." line of "reasoning".

This is a completely different statement.

Andre'
___
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] Views

[André Pönitz]

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
> > > that of an STL container.
> > 
> > Exhibit A:
> > 
> >  foo().contains(x)
> > 
> > 
> > Exhibit B:
> > 
> >  {
> >  ... container = foo();
> >  std::find(container.begin(), container.end(), x) !=
> > container.end();
> >  }
> 
> And now do the same thing [...]

No, I won't.

You were claiming something universally valid (\forall x "There is
no difference ...") and when presented a counterexample you jumped
to a "but \exists "There is no difference ..." line of "reasoning".

This is a completely different statement.

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

Re: [Development] Views

[Konstantin Shegunov]

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. E.g. QGradient could have
> inline storage for two or three stops to avoid allocating memory for the
> most-common cases. I mean, QPainter is full of (QPoint *, int nPoints)
> APIs that surely were added just for performance. Ditto for QString,
> btw. Nowadays, with views, we can have the same API, but have it accept
> many owning containers transparently. I'm not saying that there must be
> no owning containers in the API. But there is a lot of low-hanging fruit
> out there.
>

Okay, I can live with that, and I do see why it'd make sense in some cases
to iterate the data directly. But then as a container can have many
different iterables, it seems reasonable to consider adding a couple of
methods that return views and take it from there. Why the push to remove
the owning container(s) API? In time it may prove you're right, so then we
can migrate the getters to the view API and eventually deprecate these
methods. Or they could coexist, or w/e. The point is why reach for the top
if there's low-hanging fruit?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[André Pönitz]

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 STL container.
> >
> > Exhibit A:
> >
> > foo().contains(x)
> >
> >
> > Exhibit B:
> >
> > {
> > ... container = foo();
> > std::find(container.begin(), container.end(), x) != container.end();
> > }
> 
> AFAIK contains is now part of the STL.

Define "now"...

> But to show a pattern I see often with Qt container is the use of contains and
> then access the element with a key again. I that case the STL with iterators
> leads you to better performing code. Ranges hopefully make much of this code
> even more readable and performant.

Performance is always a combination of "raw run-time performance" and "time to
market".

There's no point in saving 30 processor cycles a day, even for a million users,
if that takes one hour of developer time to implement in a desktop application.

People who disagree wouldn't ever touch Java or JS or any interpreted language.
Or std::ostream for that matter.

You know as well as I do that e.g. QList is heavily used in e.g. the Qt Creator
code base, and that this is absolutely *no* performance problem. Sure, it's not
used in *really* time-critical parts, but for the 100%-\epsilon non-exceptional
stuff it's just "good enough".

Andre'
___
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 Shegunov]

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 assignment check for a nullptr d. I'd propose that on classes under
> > the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the
> > best balance between safety and speed.
>
> 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 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 the repo. Granted it may be my own fault, but in this
case the assert isn't tripped and this code simply segfaults for reasons
that aren't so obvious. Any suggestions how to mitigate that? Somehow
*suggest* to the user that [s]he's supposed to build in debug mode
otherwise they're on their own?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Mutz, Marc via Development]

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:

 {
 ... container = foo();
 std::find(container.begin(), container.end(), x) != 
container.end();

 }


And now do the same thing when you look for a given property's value: 
[name](auto ) { return e.name(); }


This is called Selective Perception.

Here's another one:

Exhibit A:

for (auto &[key, value] : map)
use(key, value);

Exhibit B:

for (auto it = map.cbegin(), end = map.cend(); it != end; ++it)
use(it.key(), it.value());

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

Re: [Development] Views

[Marco Bubke]

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:
>
> {
> ... container = foo();
> std::find(container.begin(), container.end(), x) != container.end();
> }

AFAIK contains is now part of the STL. But to show a pattern I see often with 
Qt container is the use of contains and then access the element with a key 
again. I that case the STL with iterators leads you to better performing code. 
Ranges hopefully make much of this code even more readable and performant.
>
>
>
>
> ___
> 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] Views

[Mutz, Marc via Development]

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 5% are in a given user's code, so Qt needs to assume of any of its 
functions that it may become the bottleneck in _some_ user's 
application. One might need to parse megabytes of JSON, the other might 
want to create 1000s of UUIDs per second. If Qt has ineffcient APIs, 
then the user cannot fix her performance problem, or needs to do so 
using a library other than Qt. Only by providing efficient APIs do we 
empower the user to fix her performance problem, while staying in Qt.


While it can be reasonably expected that users will only create O(100) 
widgets, any such limits simply cannot be assumed on any container.


I already cited the QRegion problem where there were multiple instances 
of


if (r.rectCount() == 1) {
   use(r.boundingRect());
} else {
   for (auto rect : r.rects())
   use(rect);
}

Nobody writes code like that unless it's needed. This all went away when 
QRegion became iterable. Now


for (auto rect : r)
use(r);

is maximally performant for all states of QRegion, the user code is 
simpler, and all cases are faster than the fastest case before.


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. E.g. QGradient could have 
inline storage for two or three stops to avoid allocating memory for the 
most-common cases. I mean, QPainter is full of (QPoint *, int nPoints) 
APIs that surely were added just for performance. Ditto for QString, 
btw. Nowadays, with views, we can have the same API, but have it accept 
many owning containers transparently. I'm not saying that there must be 
no owning containers in the API. But there is a lot of low-hanging fruit 
out there.


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

Re: [Development] Views

[Иван Комиссаров]

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 was back in Qt4 days.

If Qt wants to stay alive, it should adopt to the changes in C++ where 
reasonable. Sorry, I can’t buy an argument «we should always return a copy of a 
container because someday somewhere in KDE was a bug and the copy helped to 
solve it». Why we should force the way of doing things for the 1% case? Maybe 
we should force the way suitable for 99% cases and solve that 1% case in the 
other way? Like add a new function foo2 with new signature?

> 20 мая 2019 г., в 22:10, André Pönitz  написал(а):
> 
> At some time The Commitee decided to standardize auto_ptr, but not 
> {shared,unique,...}_ptr. People calling auto_ptr unusable for most
> practical purposed were chastised for not seeing the light. A while
> later The Committee changed their opinion...
> 
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

What’s wrong with

qFind(foo(), x);

? I actually have a strong feeling that Ranges will solve that problem too 
adding something like std::find(Range, T value);

Having std::begin(), std::visit() and std::get() it doesn’t seem that bad idea 
to have a free functions for *everything*

If someone don’t like the std::vector::empty() method, he can use qIsEmpty(T) 
function.

Problem solved?

> 20 мая 2019 г., в 22:18, André Pönitz  написал(а):
> 
> 
> Exhibit A:
> 
> foo().contains(x)
> 
> 
> Exhibit B:
> 
> {
> ... container = foo();
> std::find(container.begin(), container.end(), x) != container.end();
> }
> 
> 
> Andre'
> 
> 
> ___
> 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] Views

[André Pönitz]

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();
 std::find(container.begin(), container.end(), x) != container.end();
 }


Andre'


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

Re: [Development] Views

[André Pönitz]

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

"Qt is a C++ library, so you have to use all of C++, if you don't, you
cannot use Qt".

Does not make sense.

> No-one uses C++ unless they need the extra performance.

That's plainly wrong as well.

C++ can very well be used as a general purpose, convenient cross-platform
programming language that can be used in a way to get raw-metal performance
_when needed_. That's not true for the alternatives you mentioned, not does
that mean that one needs that performance in each and every line of code.

> It is not Qt's job to change the decisions made by the C++ standards
> committee. If you want to change the STL, submit a paper to WG21, not rant
> on a Qt mailing-list.

At some time The Commitee decided to standardize auto_ptr, but not 
{shared,unique,...}_ptr. People calling auto_ptr unusable for most
practical purposed were chastised for not seeing the light. A while
later The Committee changed their opinion...

> Thanks,

Not for that.

Andre'
___
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?

[Giuseppe D'Angelo via Development]

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 problem, as d will have
to be loaded into a register in any case.

In case someone submits such change I'd appreciate some performance
checking.


Not related to this email, but: please, we're switching from _what_ we 
want to _how_ we get it.


I understand the two are very tied (given the implicit sharing), but it 
seems to me that we are not agreeing on what a move constructor should 
do in the first place?


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] QList for Qt 6 (was: Re: Build system for Qt 6)

[Allan Sandfeld Jensen]

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 changes.
 
> I did some benchmarking (as we were worried about the different performance
> characteristics of QList and QVector) and with the exception of prepending
> in a loop pretty much all other operations gets faster with this change.
 
> So to re-iterate: We will not break SC in major ways. The goal is to make
> porting from Qt 5.x to 6 as easy as possible.
 
Would we have a different implementation for QQueue then? One of the few 
benefits of QList was the prepend optimization, which is mostly unused, except 
in QQueue. Perhaps the current QList definition could just become QQueue?

'Allan


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

[Allan Sandfeld Jensen]

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, 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: yes, move
> > constructors must
> > be noexcept. That might be the good reason why it can't reset to a
> > valid
> > state.
> 
> What a feat it would be if Qt celebrated the 10th anniversary of the
> publication of Elements of Programming with embracing the
> partially-formed state :)
> 
> So, we seem to agree that moved-from objects may have d == nullptr. In
> the following, let this be our premiss.
> 
> Where we still, maybe, disagree, is whether d == nullptr is a valid
> state. The difference is whether member functions other then destruction
> and assignment check for a nullptr d. I'd propose that on classes under
> the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the
> best balance between safety and speed.

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 would add though that if the class has an isValid() method that method 
should be callable, and must returns false.  Not sure about a possible 
isNull() method :/ That whole subject btw, probably needs some cleanup. 
Wrappers with undefined, invalid and null values have been getting a bit mixed 
up in Qt APIs, and that gets confusing when some the values we wrap are stuff 
like JSON and SQL that has defined null values.

Best regards
'Allan







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

[André Pönitz]

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 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 object without ill
> >>> effects. What they actually do, we can't tell, since the initial
> >>> state is unknowable. So apply the principle of GIGO.
> >> So basically the same stance as the Standard Library? One should be
> >> able to invoke any function without preconditions on a moved-from
> >> object?
> > 
> > Except that the standard library has an easy way of implementing
> > that, since there're no PIMPLs. For a PIMPLed class, it means that
> > the move constructor either must allocate memory or that each and
> > every PIMPLed value class needs to have a static unsharable null
> > instance. This is relatively easy for some, but try that for QBrush.
> > Or we litter all member functions with nullptr checks.
> > 
> > I agree that a moved-from object should be in the same state as a
> > default-constructed one. I disagree with that that state must always
> > be a valid value of the class. I agree with Stepanov that the
> > default constructor should be establishing the partially-formed
> > state, ie, only destruction and assignment are valid. It _can_ do
> > more, but only if it stays noexcept.
> > 
> > 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 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 problem, as d will have
> to be loaded into a register in any case.

In case someone submits such change I'd appreciate some performance
checking.

Andre'
___
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?

[Mutz, Marc via Development]

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 thought of noexcept, but let's be clear: yes, move 
constructors must
be noexcept. That might be the good reason why it can't reset to a 
valid

state.


What a feat it would be if Qt celebrated the 10th anniversary of the 
publication of Elements of Programming with embracing the 
partially-formed state :)


So, we seem to agree that moved-from objects may have d == nullptr. In 
the following, let this be our premiss.


Where we still, maybe, disagree, is whether d == nullptr is a valid 
state. The difference is whether member functions other then destruction 
and assignment check for a nullptr d. I'd propose that on classes under 
the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the 
best balance between safety and speed. I think it's important to make 
using moved-from objects an error, because it is. Trying to pamper it 
over by assigning some magic meaning to a nullptr d is going to cause 
more problems than it solves (std::variant::valueless_by_exception, 
anyone?).


If and when we accept this as policy going forward, the next question 
becomes: What does the default ctor do? I fully realize that after 
decades of constructing magic values at default construction time, Qt is 
in no position to make default constructors set d = nullptr. For 
existing classes, the documented behaviour of the default constructor is 
to establish a particular state (cf. QPen). But at least for new 
classes, we should really think about having the default ctor do nothing 
more than d = nullptr. And maybe deprecate the default constructor's 
value for Qt 7 or 8.


Why is a almost-no-op default ctor so important? Performance, yes. 
Noexcept, yes. And there's need for this. Grep Qt::Initialization. 
People _need_ the default ctors to do less work. Let's give it to them.


But I'd like to focus on something else here: Qt likes to pride itself 
for good API design. So let's look at it from that angle:


   QPen pen1 = ~~~;
   QPen pen2 = std::move(pen1);
   QPen pen3;

What's the state of 'pen1' now? Well, QPen is actually a class that sets 
d = nullptr in the moved-from object. So pen1 does not represent a 
value. This behaviour is in Qt for ten(!) minor releases now. I didn't 
find a bugreport about that. What about pen3? Well, black, solid, 
width=1 pen. Why do I know? Because I looked it up. It makes the code 
hard to understand, because for each class, you need to know what the 
default constructor does. Worse: We don't know what the intent of the 
developer is here. Does she want to create (a) a black pen, or does she 
(b) simply want to have _a_ pen, so she can specify later what it should 
be? We don't know. We need to scan the code further.


What is striking here is that a moved-from pen is _different_ than a 
default-constructed one. Wouldn't it be ore intuitive if the states were 
the same?


Under Stepanov's model

   QPen pen1 = Qt::black; // clearly (a)
   QPen pen2; // clearly (b)

it's 100% clear that pen2 is just there to be assigned to later. So, 
(b). It cannot possibly be (a), because a default-constructed QPen 
object does not represent a valid pen. Furthermore, when pen1 is moved 
from, it will end up in the same state as pen2 - partially-formed.


Can it get any simpler?

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

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

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 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 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.
>>
>> My understanding is that QVector requires contiguous memory, consuming a
>> giant block for all the items in the list. QList is just a linked list.
>> QVector will fail sooner when memory fragmentation is a problem. I would
>> expect systems with long-running processes and limited RAM (i.e. embedded,
>> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
>> especially when the size of each object is large. (You could always just
>> store pointers though)
>>
>>
>> ___
>> 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
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

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 configuration is supported in Gentoo out of the box.
>>>  Interesting, I would not have guessed. The way I currently do the
>>>  refactoring is breaking that possibility, though. It could be restored
>>>  (I guess) by moving that code into a WebKit based plugin. But I'm not
>>>  planning on installing Gentoo to implement and test that
>>  You actually don't need to install Gentoo. QtWebKit support is enabled
>>  automatically if you compile Assistant after installation of QtWebKit.
>
> But not on Windows, am I right?

Why not? Current version of QtWebKit from 5.212 works on Windows,
there are binaries at

http://download.qt.io/snapshots/ci/qtwebkit/5.212/latest/qtwebkit/

>
>>>  If continued WebKit support is desired, and the plugin idea is welcomed,
>>>  would you @Konstantin be able to help finish the WebKit plugin?
>>  Sure.
>
> Appreciated.
>>  However, it would better to avoid duplicating work with Qt Creator,
>>  which also implements HelpViewer interface with different backends.
>>  Some time ago there was a discussion that such shared interface & plugin
>>  system should belong to Qt Web View module. But that would probably
>>  require more work to be done.
>
> That would be nice. Do you have a pointer to that discussion? I only
> found
> https://lists.qt-project.org/pipermail/qt-creator/2017-September/006740.html.
> As you might have guessed, I am not a regular here.
>
>>>  Or do you think that removing WebKit support from Assistant completely
>>>  would be better, if WebEngine shows to be working well?
>>  As for me, I'm totally fine with QTextBrowser
>
> I wish that were true for me. We need colours in table cell borders and
> SVG images (and better CSS support would be real nice). This might help,
> but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256
>
> --
> Bastiaan.
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin

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

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 the overhead is a problem, as d
 will have to be loaded into a register in any case.

20.05.2019, 18:21, "Thiago Macieira" :
>>> It does introduce a compare-and-branch that wouldn't otherwise be
>>> there, but the cost is minimal compared to what most API would be
>>> doing, indeed.

In plenty of cases, it's just calling the same-named method on the d-ptr.

Result QThing::method(Type arg)
{
return Q_LIKELY(d) ? d->method(arg) : Result();
}

On 20.05.19 17:27, Konstantin Tokarev wrote:
>> We should wrap d == nullptr in Q_UNLIKELY() to make branch predictor
>> assume non-null path by default.

Olivier Goffart (20 May 2019 18:34) wrote:
> I would not do that. Q_UNLIKELY does very little to the branch
> predictor, it only tell the compiler to put that part of the branch in
> a cold area (and also optimize for size instead of for speed)
> Might not be a good idea considering that default constructed object
> is actually quite likely.

Is it ?  I would hope that code relatively seldom calls methods on
default-constructed objects or moved-from objects.  Is the behaviour
even well-defined ?  Aside, of course, from assignment and destruction,
the two places where I would indeed omit Q_UNLIKELY().

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

Re: [Development] Assistant WebKit/WebEngine support

[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 configuration is supported in Gentoo out of the box.

Interesting, I would not have guessed. The way I currently do the
refactoring is breaking that possibility, though. It could be restored
(I guess) by moving that code into a WebKit based plugin. But I'm not
planning on installing Gentoo to implement and test that

You actually don't need to install Gentoo. QtWebKit support is enabled
automatically if you compile Assistant after installation of QtWebKit.


But not on Windows, am I right?




If continued WebKit support is desired, and the plugin idea is welcomed,
would you @Konstantin be able to help finish the WebKit plugin?

Sure.

Appreciated.

However, it would better to avoid duplicating work with Qt Creator,
which also implements HelpViewer interface with different backends.
Some time ago there was a discussion that such shared interface & plugin
system should belong to Qt Web View module. But that would  probably
require more work to be done.


That would be nice. Do you have a pointer to that discussion? I only 
found 
https://lists.qt-project.org/pipermail/qt-creator/2017-September/006740.html. 
As you might have guessed, I am not a regular here.




Or do you think that removing WebKit support from Assistant completely
would be better, if WebEngine shows to be working well?

As for me, I'm totally fine with QTextBrowser


I wish that were true for me. We need colours in table cell borders and 
SVG images (and better CSS support would be real nice). This might help, 
but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256


--
Bastiaan.

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

[Olivier Goffart]

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,
  that means we need to check for d == nullptr in member functions, but I
  don’t think the overhead is a problem, as d will have to be loaded into a
  register in any case.


It does introduce a compare-and-branch that wouldn't otherwise be there, but
the cost is minimal compared to what most API would be doing, indeed.


We should wrap d == nullptr in Q_UNLIKELY() to make branch predictor assume
non-null path by default.


I would not do that. Q_UNLIKELY does very little to the branch predictor, it 
only tell the compiler to put that part of the branch in a cold area (and also 
optimize for size instead of for speed)
Might not be a good idea considering that default constructed object is 
actually quite likely.


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

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Edward Welbourne]

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
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

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 greater WebKit times, but that code remains unused after
>>>  WebKit was dropped from Qt.
>>  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, I would not have guessed. The way I currently do the
> refactoring is breaking that possibility, though. It could be restored
> (I guess) by moving that code into a WebKit based plugin. But I'm not
> planning on installing Gentoo to implement and test that

You actually don't need to install Gentoo. QtWebKit support is enabled
automatically if you compile Assistant after installation of QtWebKit.

> and without
> WebKit being part of mainline Qt I'm not sure such a plugin should be
> either, especially when things are working with WebEngine.

Probably so

>
> If continued WebKit support is desired, and the plugin idea is welcomed,
> would you @Konstantin be able to help finish the WebKit plugin?

Sure.

However, it would better to avoid duplicating work with Qt Creator,
which also implements HelpViewer interface with different backends.
Some time ago there was a discussion that such shared interface & plugin
system should belong to Qt Web View module. But that would  probably
require more work to be done.

>
> Or do you think that removing WebKit support from Assistant completely
> would be better, if WebEngine shows to be working well?

As for me, I'm totally fine with QTextBrowser


-- 
Regards,
Konstantin

___
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 Tokarev]

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 == nullptr in member functions, but I
>>  don’t think the overhead is a problem, as d will have to be loaded into a
>>  register in any case.
>
> It does introduce a compare-and-branch that wouldn't otherwise be there, but
> the cost is minimal compared to what most API would be doing, indeed.

We should wrap d == nullptr in Q_UNLIKELY() to make branch predictor assume
non-null path by default.

-- 
Regards,
Konstantin

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

Re: [Development] Assistant WebKit/WebEngine support

[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 greater WebKit times, but that code remains unused after
WebKit was dropped from Qt.

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, I would not have guessed. The way I currently do the 
refactoring is breaking that possibility, though. It could be restored 
(I guess) by moving that code into a WebKit based plugin. But I'm not 
planning on installing Gentoo to implement and test that, and without 
WebKit being part of mainline Qt I'm not sure such a plugin should be 
either, especially when things are working with WebEngine.


If continued WebKit support is desired, and the plugin idea is welcomed, 
would you @Konstantin be able to help finish the WebKit plugin?


Or do you think that removing WebKit support from Assistant completely 
would be better, if WebEngine shows to be working well?


--
Bastiaan.


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

Re: [Development] Proposal: Using Gerrit for new approver proposals?

[Thiago Macieira]

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 proposal is sent to 
the list first.

The list is the ultimate decision-making body in the Qt Project. Just as QUIPs 
record a decision made in the mailing list, the +1 for new approvers and 
maintainers can be recorded in Gerrit.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

[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 == nullptr in member functions, but I
> don’t think the overhead is a problem, as d will have to be loaded into a
> register in any case.

It does introduce a compare-and-branch that wouldn't otherwise be there, but 
the cost is minimal compared to what most API would be doing, indeed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

[Thiago Macieira]

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: yes, move constructors must 
be noexcept. That might be the good reason why it can't reset to a valid 
state.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] QList for Qt 6

[Jean-Michaël Celerier]

> 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 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.
>
> My understanding is that QVector requires contiguous memory, consuming a
> giant block for all the items in the list. QList is just a linked list.
> QVector will fail sooner when memory fragmentation is a problem. I would
> expect systems with long-running processes and limited RAM (i.e. embedded,
> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> especially when the size of each object is large. (You could always just
> store pointers though)
>
>
> ___
> 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

[Jason H]

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

My understanding is that QVector requires contiguous memory, consuming a giant 
block for all the items in the list. QList is just a linked list. QVector will 
fail sooner when memory fragmentation is a problem. I would expect systems with 
long-running processes and limited RAM (i.e. embedded, a Raspberry Pi, phone, 
etc) to encounter this sooner than other systems, especially when the size of 
each object is large. (You could always just store pointers though)


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

Re: [Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

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 greater WebKit times, but that code remains unused after
> WebKit was dropped from Qt. 

Note that it should be possible to rebuild QtTools with QtWebKit support,
for example this configuration is supported in Gentoo out of the box.

-- 
Regards,
Konstantin

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

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

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 if you create more
potential work for KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList
doesn't matter. Actually, I'd err on keeping QList, to minimize
porting. What I want to avoid is to break user code silently. Asan
is a runtime-checker, the code must actually be exercised, which is
trivial for QToolBox but might be problematic if it's in, say, error
handling code. And you rightfully pointed out that it's very hard
for a static checker to find cases where reference stability is
used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is
with deprecated implicit conversions to and from QVector, assuming
all Qt API that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own
leisure
* Receiving objects can be done with auto variables for optimal
performance
or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to
QVector
+ This might be slow, but you say yourself that speed doesn't
matter
for 95% of the code and it's easier to find and fix slow code in
the 5% than it is to find a silent reference stability breakage
in
the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from
and to QList
+ But using the 95/5-argument here, again: it's easier to find
where the app
got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in
which aspects inheriting QList from QVector fares better than this
proposal.


 I’m not proposing to make QList inherit QVector. Actually, I’m
making it an alias to QVector. See
https://codereview.qt-project.org/c/qt/qtbase/+/242692 .

With that, one option could be to make the alias dependent on a
compile time setting for the application code (ie. have a simple
define whether we do

using QList = QVector

Or

using QList = Qt5Support::QList


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.



My fear is that QList : QVector will lead to some of Qt's APIs
continuing to use QList, which would lock Qt into QList for another
major release cycle and only postpone the inevitable QList removal.


No, of course we need to get rid of all references to QList in our
APIs.


I appreciate that commitment very much.

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

Re: [Development] QList for Qt 6

[Jason H]

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 languages is, I think, important. This also applies to QML models, which use size() and not length. It;s rather leaky abstraction to allow JS arrays as models, which use length, and "proper" QML models which use size. This is friction that I don't think needs to exist?

 

 

 

Sent: Monday, May 20, 2019 at 9:52 AM
From: "Lars Knoll" 
To: "Mutz, Marc" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QList for Qt 6


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 if you create more potential work for KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't matter. Actually, I'd err on keeping QList, to minimize porting. What I want to avoid is to break user code silently. Asan is a runtime-checker, the code must actually be exercised, which is trivial for QToolBox but might be problematic if it's in, say, error handling code. And you rightfully pointed out that it's very hard for a static checker to find cases where reference stability is used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with deprecated implicit conversions to and from QVector, assuming all Qt API that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own leisure
* Receiving objects can be done with auto variables for optimal performance
 or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector
 + This might be slow, but you say yourself that speed doesn't matter
   for 95% of the code and it's easier to find and fix slow code in
   the 5% than it is to find a silent reference stability breakage in
   the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and to QList
 + But using the 95/5-argument here, again: it's easier to find where the app
   got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which aspects inheriting QList from QVector fares better than this proposal.



 
I’m not proposing to make QList inherit QVector. Actually, I’m making it an alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 . 

 

With that, one option could be to make the alias dependent on a compile time setting for the application code (ie. have a simple define whether we do

 

using QList = QVector

 

Or 

 


using QList = Qt5Support::QList

 






My fear is that QList : QVector will lead to some of Qt's APIs continuing to use QList, which would lock Qt into QList for another major release cycle and only postpone the inevitable QList removal.



 

No, of course we need to get rid of all references to QList in our APIs.
 



C++11 gave us the tools to make this transition now much smoother than it could have been done in Qt 4->5. Inheriting QList from QVector is both technically wrong (value classes inheriting each other) and just serves to confuse users (is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).



 
See above. The change where they inherit from each other is an intermediate change, not the final result.

 

Cheers,

Lars

 





Touché on the QStringView reference :)

Thanks,
Marc
___
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



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

Re: [Development] Gerrit is back

[Denis Shienkov]

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

[Lars Knoll]

> 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 (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 object without ill effects. What they actually do, we can't tell, 
>>> since
>>> the initial state is unknowable. So apply the principle of GIGO.
>> So basically the same stance as the Standard Library? One should be
>> able to invoke any function without preconditions on a moved-from
>> object?
> 
> Except that the standard library has an easy way of implementing that, since 
> there're no PIMPLs. For a PIMPLed class, it means that the move constructor 
> either must allocate memory or that each and every PIMPLed value class needs 
> to have a static unsharable null instance. This is relatively easy for some, 
> but try that for QBrush. Or we litter all member functions with nullptr 
> checks.
> 
> I agree that a moved-from object should be in the same state as a 
> default-constructed one. I disagree with that that state must always be a 
> valid value of the class. I agree with Stepanov that the default constructor 
> should be establishing the partially-formed state, ie, only destruction and 
> assignment are valid. It _can_ do more, but only if it stays noexcept.
> 
> 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 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 problem, as d will have to be loaded into a register in any 
case.

Cheers,
Lars

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

Re: [Development] Gerrit is back

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

[Lars Knoll]

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 you create more potential work for KDAB, but I'm 
actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't matter. 
Actually, I'd err on keeping QList, to minimize porting. What I want to avoid 
is to break user code silently. Asan is a runtime-checker, the code must 
actually be exercised, which is trivial for QToolBox but might be problematic 
if it's in, say, error handling code. And you rightfully pointed out that it's 
very hard for a static checker to find cases where reference stability is used. 
Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with 
deprecated implicit conversions to and from QVector, assuming all Qt API that 
uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own leisure
* Receiving objects can be done with auto variables for optimal performance
 or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector
 + This might be slow, but you say yourself that speed doesn't matter
   for 95% of the code and it's easier to find and fix slow code in
   the 5% than it is to find a silent reference stability breakage in
   the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and to QList
 + But using the 95/5-argument here, again: it's easier to find where the app
   got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which 
aspects inheriting QList from QVector fares better than this proposal.

I’m not proposing to make QList inherit QVector. Actually, I’m making it an 
alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 .

With that, one option could be to make the alias dependent on a compile time 
setting for the application code (ie. have a simple define whether we do

using QList = QVector

Or

using QList = Qt5Support::QList


My fear is that QList : QVector will lead to some of Qt's APIs continuing to 
use QList, which would lock Qt into QList for another major release cycle and 
only postpone the inevitable QList removal.

No, of course we need to get rid of all references to QList in our APIs.

C++11 gave us the tools to make this transition now much smoother than it could 
have been done in Qt 4->5. Inheriting QList from QVector is both technically 
wrong (value classes inheriting each other) and just serves to confuse users 
(is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? 
What do to if I target both Qt 5 and Qt 6?).

See above. The change where they inherit from each other is an intermediate 
change, not the final result.

Cheers,
Lars


Touché on the QStringView reference :)

Thanks,
Marc
___
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] Gerrit is back

[Tor Arne Vestbø]

> 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 https://bugreports.qt.io/issues/?filter=21020

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

[Development] Gerrit is back

[Jukka Jokiniva]

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] Assistant WebKit/WebEngine support

[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 greater WebKit times, but that code remains unused after 
WebKit was dropped from Qt. There have been talks about WebKit making a 
return[2], but it has been quiet on that front for some time. There has 
been an initiative for using WebEngine as an alternative, which mostly 
works[3]. However, that patch assumes the WebEngine build to have 
completed when Assistant is being built, which is not the case in a 
clean checkout. To resolve this dependency order problem, it has been 
suggested in its review to redo WebEngine support as a plugin to Assistant.


I have been looking into the plugin idea, and although it is not 
straight forward I think it is doable. Some larger refactoring is needed 
to achieve a clean border between Assistant and the viewer plugin 
interface. My goal is to eliminate calls from the viewer plugin back 
into the Assistant application, which would otherwise require some 
classes to be in a common shared library. I can implement the 
QTextBrowser based viewer in a plugin that is statically linked, so that 
Assistant will work out of the box whether it is being deployed with or 
without WebEngine. Plugins can be selected based on priority.


Having the viewer back end be separated from the application with a 
plugin interface may be an advantage regardless, whether WebKit comes 
back or WebEngine is being removed from the Qt distribution in the 
future. At least users will have a possibility to replace the default 
viewer with whatever alternative is available.


Does this sound like a good idea?

Thanks,
Bastiaan Veelo

[1] https://bugreports.qt.io/browse/QTBUG-55866
[2] https://forum.qt.io/topic/102816/webkit-status-2019
[3] https://codereview.qt-project.org/#/c/111559/

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

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

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,
>
> 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 each and every Qt API.
>
> Whether to call it Q5List or QArrayList or continue with QList doesn't
> matter. Actually, I'd err on keeping QList, to minimize porting. What I
> want to avoid is to break user code silently. Asan is a runtime-checker,
> the code must actually be exercised, which is trivial for QToolBox but
> might be problematic if it's in, say, error handling code. And you
> rightfully pointed out that it's very hard for a static checker to find
> cases where reference stability is used. Not impossible, but hard.
>
> I want to understand what problems you see with keeping QList as-is with
> deprecated implicit conversions to and from QVector, assuming all Qt API
> that uses QList is ported to QVector.
>
> The way I see it:
>
> Given:
> * QList stays as-is
> * No Qt API takes or returns QList anymore, but QVector
> * QList implicitly converts to QVector, and vice versa
> * These implicit conversions are marked as deprecated
>
> Pros:
> * Old (user) code doesn't silently change the meaning
> * Old (user) code continues to work, lets users port at their own
> leisure
> * Receiving objects can be done with auto variables for optimal
> performance
>or with QList for old code.
> * Users passing QLists into Qt APIs enjoy the implicit conversion to
> QVector
>+ This might be slow, but you say yourself that speed doesn't matter
>  for 95% of the code and it's easier to find and fix slow code in
>  the 5% than it is to find a silent reference stability breakage in
>  the 95%.
>
> Cons:
> * Unported code will get penalized by the implicit conversions from and
> to QList
>+ But using the 95/5-argument here, again: it's easier to find where
> the app
>  got slower in the 5% than to find a bug in the 95%.
>
> The pros far, far outweigh the cons. I'd very much like to know in which
> aspects inheriting QList from QVector fares better than this proposal.
>
> My fear is that QList : QVector will lead to some of Qt's APIs
> continuing to use QList, which would lock Qt into QList for another
> major release cycle and only postpone the inevitable QList removal.
> C++11 gave us the tools to make this transition now much smoother than
> it could have been done in Qt 4->5. Inheriting QList from QVector is
> both technically wrong (value classes inheriting each other) and just
> serves to confuse users (is it still ok to use QList? Is it now suddenly
> ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).
>
> Touché on the QStringView reference :)
>
> Thanks,
> Marc
> ___
> 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] What's the status of a moved-from object?

[Mutz, Marc via Development]

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 the accessor and mutation API in the class can 
operate
in the object without ill effects. What they actually do, we can't 
tell, since

the initial state is unknowable. So apply the principle of GIGO.


So basically the same stance as the Standard Library? One should be
able to invoke any function without preconditions on a moved-from
object?


Except that the standard library has an easy way of implementing that, 
since there're no PIMPLs. For a PIMPLed class, it means that the move 
constructor either must allocate memory or that each and every PIMPLed 
value class needs to have a static unsharable null instance. This is 
relatively easy for some, but try that for QBrush. Or we litter all 
member functions with nullptr checks.


I agree that a moved-from object should be in the same state as a 
default-constructed one. I disagree with that that state must always be 
a valid value of the class. I agree with Stepanov that the default 
constructor should be establishing the partially-formed state, ie, only 
destruction and assignment are valid. It _can_ do more, but only if it 
stays noexcept.


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?


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

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

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 each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't 
matter. Actually, I'd err on keeping QList, to minimize porting. What I 
want to avoid is to break user code silently. Asan is a runtime-checker, 
the code must actually be exercised, which is trivial for QToolBox but 
might be problematic if it's in, say, error handling code. And you 
rightfully pointed out that it's very hard for a static checker to find 
cases where reference stability is used. Not impossible, but hard.


I want to understand what problems you see with keeping QList as-is with 
deprecated implicit conversions to and from QVector, assuming all Qt API 
that uses QList is ported to QVector.


The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own 
leisure
* Receiving objects can be done with auto variables for optimal 
performance

  or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to 
QVector

  + This might be slow, but you say yourself that speed doesn't matter
for 95% of the code and it's easier to find and fix slow code in
the 5% than it is to find a silent reference stability breakage in
the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and 
to QList
  + But using the 95/5-argument here, again: it's easier to find where 
the app

got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which 
aspects inheriting QList from QVector fares better than this proposal.


My fear is that QList : QVector will lead to some of Qt's APIs 
continuing to use QList, which would lock Qt into QList for another 
major release cycle and only postpone the inevitable QList removal. 
C++11 gave us the tools to make this transition now much smoother than 
it could have been done in Qt 4->5. Inheriting QList from QVector is 
both technically wrong (value classes inheriting each other) and just 
serves to confuse users (is it still ok to use QList? Is it now suddenly 
ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).


Touché on the QStringView reference :)

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

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

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 qlist you are going to have a bad
time (tm) come Qt6"


On Mon, May 20, 2019 at 3:02 PM Иван Комиссаров  wrote:

> 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
>T has been declared to be either a Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE
> using Q_DECLARE_TYPEINFO
>. See the Pros
>and Cons of Using QList
> 
> for
>an explanation.
>
>
> Иван Комиссаров
>
> 20 мая 2019 г., в 13:40, NIkolai Marchenko 
> написал(а):
>
> 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 that were going on about "somehow saving
> the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
> bother.
>
> This *really* is not something I expected being thrown around as a serious
> argument here.
>
> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
> wrote:
>
>> 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 for a while (but declared it as auto)
>> you are introducing nasty bugs while maintaining SC.
>>
>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
>> wrote:
>>
>>> 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 more used then you
>>> are preventing ppl from "almost always auto"
>>>
>>> First: I don't believe we've committed to "almost always auto" as a Qt
>>> coding style (it leaves the reader to work out what everything is, which
>>> I - as a reviewer - really don't like).  Being explicit about what type
>>> of container you want to use has its virtues (albeit, as Marc points
>>> out, auto's ambiguity is good when the API is in flux).
>>>
>>> Second: if we return a container, the API designer has to decide which
>>> type of container to return, which forces the caller to do a conversion
>>> if that wasn't the type they wanted.  Returning a range lets the caller
>>> chose how to store the values.
>>>
>>> However, that's only a win if the supplier wasn't already holding the
>>> values in a container, which CoW lets us return cheaply.
>>>
>>> The win (assuming C++ ranges work enough like python generators) comes
>>> when you're traversing some population of things and selecting some to
>>> return, while skipping the rest; classically that might be implemented
>>> as a traversal with a call-back object to act on each item; but a range
>>> lets the caller just iterate over the results found, turning the
>>> call-back's code into a loop's body, which is far easier to follow; or
>>> collecting the results into a container of the caller's choosing.
>>>
>>> Eddy.
>>>
>> ___
> 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

[Иван Комиссаров]

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 T has been declared to be either a 
Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE using Q_DECLARE_TYPEINFO. See the Pros and 
Cons of Using QList for an explanation.

Иван Комиссаров

> 20 мая 2019 г., в 13:40, NIkolai Marchenko  
> написал(а):
> 
> 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 that were going on about "somehow saving 
> the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't 
> bother.
> 
> This *really* is not something I expected being thrown around as a serious 
> argument here.
> 
>> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko  
>> wrote:
>> 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 for a while (but declared it as auto) you 
>> are introducing nasty bugs while maintaining SC.
>> 
>>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne  
>>> wrote:
>>> 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 more used then you are 
>>> > preventing ppl from "almost always auto"
>>> 
>>> First: I don't believe we've committed to "almost always auto" as a Qt
>>> coding style (it leaves the reader to work out what everything is, which
>>> I - as a reviewer - really don't like).  Being explicit about what type
>>> of container you want to use has its virtues (albeit, as Marc points
>>> out, auto's ambiguity is good when the API is in flux).
>>> 
>>> Second: if we return a container, the API designer has to decide which
>>> type of container to return, which forces the caller to do a conversion
>>> if that wasn't the type they wanted.  Returning a range lets the caller
>>> chose how to store the values.
>>> 
>>> However, that's only a win if the supplier wasn't already holding the
>>> values in a container, which CoW lets us return cheaply.
>>> 
>>> The win (assuming C++ ranges work enough like python generators) comes
>>> when you're traversing some population of things and selecting some to
>>> return, while skipping the rest; classically that might be implemented
>>> as a traversal with a call-back object to act on each item; but a range
>>> lets the caller just iterate over the results found, turning the
>>> call-back's code into a loop's body, which is far easier to follow; or
>>> collecting the results into a container of the caller's choosing.
>>> 
>>> Eddy.
> ___
> 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

[NIkolai Marchenko]

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 that were going on about "somehow saving
the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
bother.

This *really* is not something I expected being thrown around as a serious
argument here.

On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
wrote:

> 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 for a while (but declared it as auto) you
> are introducing nasty bugs while maintaining SC.
>
> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
> wrote:
>
>> 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 more used then you
>> are preventing ppl from "almost always auto"
>>
>> First: I don't believe we've committed to "almost always auto" as a Qt
>> coding style (it leaves the reader to work out what everything is, which
>> I - as a reviewer - really don't like).  Being explicit about what type
>> of container you want to use has its virtues (albeit, as Marc points
>> out, auto's ambiguity is good when the API is in flux).
>>
>> Second: if we return a container, the API designer has to decide which
>> type of container to return, which forces the caller to do a conversion
>> if that wasn't the type they wanted.  Returning a range lets the caller
>> chose how to store the values.
>>
>> However, that's only a win if the supplier wasn't already holding the
>> values in a container, which CoW lets us return cheaply.
>>
>> The win (assuming C++ ranges work enough like python generators) comes
>> when you're traversing some population of things and selecting some to
>> return, while skipping the rest; classically that might be implemented
>> as a traversal with a call-back object to act on each item; but a range
>> lets the caller just iterate over the results found, turning the
>> call-back's code into a loop's body, which is far easier to follow; or
>> collecting the results into a container of the caller's choosing.
>>
>> Eddy.
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

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 for a while (but declared it as auto) you
are introducing nasty bugs while maintaining SC.

On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
wrote:

> 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 more used then you
> are preventing ppl from "almost always auto"
>
> First: I don't believe we've committed to "almost always auto" as a Qt
> coding style (it leaves the reader to work out what everything is, which
> I - as a reviewer - really don't like).  Being explicit about what type
> of container you want to use has its virtues (albeit, as Marc points
> out, auto's ambiguity is good when the API is in flux).
>
> Second: if we return a container, the API designer has to decide which
> type of container to return, which forces the caller to do a conversion
> if that wasn't the type they wanted.  Returning a range lets the caller
> chose how to store the values.
>
> However, that's only a win if the supplier wasn't already holding the
> values in a container, which CoW lets us return cheaply.
>
> The win (assuming C++ ranges work enough like python generators) comes
> when you're traversing some population of things and selecting some to
> return, while skipping the rest; classically that might be implemented
> as a traversal with a call-back object to act on each item; but a range
> lets the caller just iterate over the results found, turning the
> call-back's code into a loop's body, which is far easier to follow; or
> collecting the results into a container of the caller's choosing.
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

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 changes.
> [...]
>> So to re-iterate: We will not break SC in major ways. The goal is to
>> make porting from Qt 5.x to 6 as easy as possible.
> 
> It's technically SC alright, but silently breaking the reference stability 
> user code may rely on should be a complete no-no, considering how reluctant 
> Qt has been since the Qt 3->4 port with disruptive changes. I welcome the 
> openness to rethink the necessity of some of the plumbing infrastructure, but 
> it appears that you have come out far on the other side on this one.

I don’t think so. At least not if we provide a fully compatible QList in e.g. a 
Qt5Support module/namespace, and allowing the app to use it with a simple 
switch.
> 
> As I said a few years ago, QList in Qt 5 should have a warning if it keeps 
> reference stability (iow: if it's not already behaviour- if not 
> structure-compatible with QVector), indicting very strongly that by Qt 6, 
> this use-case will be gone. Then port all of Qt's own code away from QList, 
> either to QVector, or, say, std::vector, like in QToolBox 
> (https://codereview.qt-project.org/261943), which is a case where a user that 
> actually relies on the implicit reference-stability guarantee of current 
> QList, then deprecate QList.

This is our job now for 5.14/5.15. Make sure we add warnings for all use cases 
we don’t want to support in Qt 6 anymore. The problem with stability of those 
references is that it’s unfortunately rather hard to have them detected by the 
compiler.

Having said that, this is the only major source breakage, and it’s a relatively 
uncommon one. In addition, a build with address sanitiser enabled should 
quickly find those, so I don’t think it’s something we need to keep by default 
until everybody manually changed all their code to use QVector.

> 
> Back then I suggested to rename QList to QArrayList and have QList be a 
> deprecated template alias for _either_ QArrayList or QVector, depending on 
> whether Q5List would keep references stable or not.

That would be more source compatible. But I would really not want to continue 
to return and take QLists in our public APIs. And if we don’t do that Qt6 will 
basically incur a copy between (un-ported) user code and Qt code. The question 
is whether not having that overhead is more important than reference stability 
or not.
> 
> Please don't make QList an unconditional alias for QVector. You are silently 
> breaking Qt code (cf. QToolBox) along with an unknown amount of Qt-user's 
> code. Make the break non-silent.
> 
> I understand the desire to keep old code working that was written against Qt 
> 5. But to me, the better solution would be to have the Qt 6 API explicitly 
> return QVector and have implicit, but deprecated, conversions between QList 
> and QVector. The priority should be to not break code. It should not be a 
> priority to have unported code enjoy optimal speed. An actual copy on 
> implicit QVector -> QList conversion is acceptable, IMO, since the solution 
> for codebases targeting both Qt 5 and 6 is simple: use an auto variable.

Auto doesn’t always work. It works for return values, but it won’t work for 
objects the user creates and wants to pass into Qt API.

Another option (outlined above) could be a compile switch between your idea 
(fully SC, but performance penalty) and mine (slightly SIC, but no performance 
penalty). Users could then choose which way they want to go.
> 
> Going forward, we should be looking into removing more and more owning 
> containers from the interface and replace them with views. The standard is 
> working on a solution for the stale reference problem, and by the time Qt 7 
> comes around, it will be hopefully widely available.

Let’s keep that discussion separate. But if we’re going on that tangent, we 
should at least finish the QStringView related work for Qt 6.

Cheers,
Lars

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

Re: [Development] Views

[Lars Knoll]

> 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 more acceptable since these classes jump all over the
>>> memory anyhow. Basically "it worked", still requiring a few changes
>>> though, e.g. std::unordered_map iterators are forward, QHash ones are
>>> bidirectional. If the SIC is acceptable, something to consider for Qt 6.
>> Are there any plans/discussions how to procede with that experiment?
> 
> It was worth a try after we discussed this possibility a couple of years ago 
> at QtCS. I don't know if it's still interesting to pursue.

I’ve tried the same thing and it seems possible to implement this in a more or 
less source compatible way. One problem with QMap/QHash is the insertMulti() 
functionality and the fact that hash and multi_hash are not two separate types. 
But that is something I would very much like to deprecate in Qt 5.15 already 
(by deprecating insertMulti()).

Cheers,
Lars

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

Re: [Development] Views

[Lars Knoll]

> 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. 
> No-one uses C++ unless they need the extra performance.

That might be true for some people, but certainly not for everybody.

Qt has always had a somewhat different philosophy. Make C++ easy to use, no 
need to use Java. The fact is that 95% of the source code our users write will 
not be performance critical. You don’t want to make the pay the price of having 
a difficult to use API for those 95% of the code. 

That making expensive operations hard to use will lead to more performant code 
is something I don’t buy. A hard to use API will instead lead to programming 
mistakes and will simply lead to slower speed in implementing the features 
required.

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

> It is not Qt's job to change the decisions made by the C++ standards 
> committee. If you want to change the STL, submit a paper to WG21, not rant on 
> a Qt mailing-list.

It’s not. But it’s also not that we have to simply follow any decision the 
standards committee does. Design philosophies and priorities may differ and 
lead to different decisions.

Cheers,
Lars



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

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Timur Pocheptsov]

+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 Mikhail Svetkin for Approver status

+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. He’s been an active 
contributor since March 2018, working on C++11’ifying Qt, contributing to core 
QPA, network code, the QtHttpServer labs project, and right now the integration 
of changes for RTEMS into qtbase.

He’s also been actively helping others with reviews, and does so in a 
professional, respectful, and constructive way that complies with the Code of 
Conduct.

Here’s the list of changes under his current Gerrit account:

  
https://codereview.qt-project.org/#/q/owner:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,z

and a list of changes where he has been reviewing:

  
https://codereview.qt-project.org/#/q/reviewer:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,004c7463725f


Disclaimer: I’m sitting a few offices away from Mikhail in The Qt Company 
office in Oslo, and am also his line manager.


Cheers,
Volker

___
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] Nominating Mikhail Svetkin for Approver status

[Topi Reiniö]

+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. He’s been an active 
contributor since March 2018, working on C++11’ifying Qt, contributing to core 
QPA, network code, the QtHttpServer labs project, and right now the integration 
of changes for RTEMS into qtbase.

He’s also been actively helping others with reviews, and does so in a 
professional, respectful, and constructive way that complies with the Code of 
Conduct.

Here’s the list of changes under his current Gerrit account:

  
https://codereview.qt-project.org/#/q/owner:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,z

and a list of changes where he has been reviewing:

  
https://codereview.qt-project.org/#/q/reviewer:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,004c7463725f


Disclaimer: I’m sitting a few offices away from Mikhail in The Qt Company 
office in Oslo, and am also his line manager.


Cheers,
Volker

___
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

[Development] Qt Design Studio 1.2 is released

[Thomas Hartmann]

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
https://lists.qt-project.org/listinfo/development

Re: [Development] CI is down

[Heikki Halmet]

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 currently broken. We don't know exact problem yet. Hopefully 
we have more answers tomorrow.



Ystävällisin terveisin / Kind regards,

Heikki Halmet
Software Engineer | CI Lead
Release and Test Automation | CI Team
The Qt Company | Finland | Oulu


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

Re: [Development] QList for Qt 6

[Edward Welbourne]

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 more used then you are 
> preventing ppl from "almost always auto"

First: I don't believe we've committed to "almost always auto" as a Qt
coding style (it leaves the reader to work out what everything is, which
I - as a reviewer - really don't like).  Being explicit about what type
of container you want to use has its virtues (albeit, as Marc points
out, auto's ambiguity is good when the API is in flux).

Second: if we return a container, the API designer has to decide which
type of container to return, which forces the caller to do a conversion
if that wasn't the type they wanted.  Returning a range lets the caller
chose how to store the values.

However, that's only a win if the supplier wasn't already holding the
values in a container, which CoW lets us return cheaply.

The win (assuming C++ ranges work enough like python generators) comes
when you're traversing some population of things and selecting some to
return, while skipping the rest; classically that might be implemented
as a traversal with a call-back object to act on each item; but a range
lets the caller just iterate over the results found, turning the
call-back's code into a loop's body, which is far easier to follow; or
collecting the results into a container of the caller's choosing.

Eddy.
___
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?

[Giuseppe D'Angelo via Development]

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 object without ill effects. What they actually do, we can't tell, since
the initial state is unknowable. So apply the principle of GIGO.


So basically the same stance as the Standard Library? One should be able 
to invoke any function without preconditions on a moved-from object?


Cheers,
--
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] Proposal: Using Gerrit for new approver proposals?

[Volker Hilsheimer]

+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 saner than 
someone clicking on buttons somewhere (I don’t know how it is done today, but I 
assume it involves someone clicking on stuff in some admin console).


Cheers,
Volker


> On 20 May 2019, at 10:50, Florian Bruhin  wrote:
> 
> 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 proposal text)? Then people could +1 that
> change instead.
> 
> Just my $0.02 - it's not like I'd unsubscribe over this :)
> 
> Florian
> 
> -- 
> https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
>   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
> I love long mails! | https://email.is-not-s.ms/
> ___
> 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] Proposal: Using Gerrit for new approver proposals?

[Jesus Fernandez]

+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 new version. 
In the other hand, emails are far from optimal to discuss stuff.



Best regards,

Jesús


From: Development  on behalf of Florian 
Bruhin 
Sent: 20 May 2019 10:50
To: development@qt-project.org
Subject: [Development] Proposal: Using Gerrit for new approver proposals?

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 proposal text)? Then people could +1 that
change instead.

Just my $0.02 - it's not like I'd unsubscribe over this :)

Florian

--
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Proposal: Using Gerrit for new approver proposals?

[Florian Bruhin]

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 proposal text)? Then people could +1 that
change instead.

Just my $0.02 - it's not like I'd unsubscribe over this :)

Florian

-- 
https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


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

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Mårten Nordheim]

+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 status. He’s been an active 
contributor since March 2018, working on C++11’ifying Qt, contributing to core 
QPA, network code, the QtHttpServer labs project, and right now the integration 
of changes for RTEMS into qtbase.

He’s also been actively helping others with reviews, and does so in a 
professional, respectful, and constructive way that complies with the Code of 
Conduct.

Here’s the list of changes under his current Gerrit account:

  
https://codereview.qt-project.org/#/q/owner:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,z

and a list of changes where he has been reviewing:

  
https://codereview.qt-project.org/#/q/reviewer:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,004c7463725f


Disclaimer: I’m sitting a few offices away from Mikhail in The Qt Company 
office in Oslo, and am also his line manager.


Cheers,
Volker

___
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] Nominating Ryan Chu for Approvership

[Mårten Nordheim]

+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 of Jesus 
Fernandez 
Sent: Friday, May 17, 2019 8:57
To: development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

+1!




Best regards,

Jesús


From: Development  on behalf of Edward 
Welbourne 
Sent: 16 May 2019 10:58
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

Another +1.

Disclaimer: I was his mentor and office-mate for his first year and a bit.

Eddy.


From: Development  on behalf of Paul 
Wicking 
Sent: 15 May 2019 13:11
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
http://qt.io
___
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development