Re: [Development] Qt 6: Assigning QPalette to ApplicationWindow.palette no longer supported?

[Vitaly Fanaskov]

Hi Marcel,

> Is my use case no longer supported or is this a regression?

I don't think that this is a regression. Because the code you mentioned
relies on knowledge from the private headers. Please, correct me if I'm
mistaken, but it's not mentioned in the official documentation that palette
from QML is QPalette.
Qt developers always try to reduce inconvenience even for transitions
between major releases. Unfortunately, it's not always possible.

> And if not, what is the proposed way to do it? Preferrably compatible
with Qt 5.15 and Qt 6. Do I have to set every single colorrole of the
palette separately?

Well, I have no answer for a compatible solution. Only something in C++
involved using private headers, but I wouldn't recommend it.
The solution for QML looks good at a glance.


Vitaly

On Fri, Aug 21, 2020 at 10:26 PM Marcel Krems 
wrote:

> Hi,
>
> I recently implemented a theming system for my Qt Quick application.
>
> With Qt 6 I'm getting an error: "Unable to assign QPalette to
> QQuickPalette*"
> This was changed in the following commits:
>   - https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270097
>   - https://codereview.qt-project.org/c/qt/qtdeclarative/+/270092
>
> My Theme class looks like this:
> class Theme : public QObject
> {
>  Q_OBJECT
>  Q_PROPERTY(QPalette palette MEMBER _palette NOTIFY themeChanged)
>  ...
> };
>
> In my main.qml I'm setting the palette with:
> ApplicationWindow {
>  palette: Theme.palette
>  ...
> }
>
> My question is:
> Is my use case no longer supported or is this a regression?
> And if not, what is the proposed way to do it? Preferrably compatible
> with Qt 5.15 and Qt 6.
> Do I have to set every single colorrole of the palette separately?
> E.g.
> ApplicationWindow {
>  palette {
>  active {
>  buttonText: Theme.buttonText
>  button: Theme.button
>  ...
>  }
>
>  disabled {
>  buttonText: Theme.buttonTextDisabled
>  button: Theme.buttonDisabld
>  }
>  }
> }
>
>
> Kind regards,
> Marcel
> _______
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
Vitaly Fanaskov | Software Engineer
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Vitaly Fanaskov]

One year for a major Qt release and then break API?
I didn't say that.
The thing is that there will be much less changes for one year. It means that 
you need to do less job to switch a version. I hope it also will lead to more 
careful feature planning and API design. With shorter release cycle it also 
will be possible to faster adopt new best practices, approaches, and language 
standards. Especially for new API. All of these things make developers more 
productive and make it easier to hire a new people.
Just think when Qt and its user could make use of such a handy things like 
coroutines, ranges, modules, concepts and so on. In 3-5 years, with the current 
approach. Probably. These features is not something trendy, they are the real 
things that help solving regular software engineering tasks faster and more 
efficient.

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?
I guess this is a rhetorical question, right? The situation is the same with a 
refactoring. There are many books about it. All I want to say is that there is 
always should be a balance.

How often do you think we can play this game until people look for
something they consider more stable?
Moving to one year release approach doesn't equal to make Qt less stable.


From: André Pönitz 
Sent: Thursday, April 23, 2020 17:52
To: Vitaly Fanaskov 
Cc: Simon Hausmann ; development@qt-project.org 

Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
>
>I read the entire discussion, and I'd like to say this one more time:
>we don't have to fight the consequences. Better to eliminate a cause.
>There always will be a functionality to deprecate. There always will be
>controversial APIs, that, for example, contain a hard-coded type
>information in the name (e.g. "windowList()" instead of "windows()").
>Why not think about it instead? Today it QVector vs. QList, tomorrow
>something else...
>
>We can at least shorten release cycle to one year.

One year for a major Qt release and then break API?

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?

How often do you think we can play this game until people look for
something they consider more stable?

>Provide clang-based tools to (semi-)automatically port users' code
>bases to a new version of Qt.
>
>These tools might either fix a code or at
>least add a comment in potentially problematic places where a user
>should correct the code. A developer who changes API should also
>implement a rule for these tools.

This magic tool comes up over and over again, still no-one "just did it".
Maybe because it's not *that* trivial after all, maybe because doing that
actual porting ends up in real work, which is  much less fun than just
deciding that something needs to be changed, maybe something else.

Really: All this talk "this is bad, should be done differently, and
then it is better" would be much easier to believe if they were accompanied
by patches that implements that change for all of Qt. Or all of KDE.

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

Re: [Development] Clang-based refactoring to Qt 6 (Proposal: Deprecate QVector in Qt 6)

[Vitaly Fanaskov]

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot
work in all cases either.
That's true, but on the other hand, covering at least a half of code bases 
would be a huge progress. I don't have representative statistics, but I guess 
that the real percentage will be larger.

2) No one has volunteered to write such conversion scripts
Well, it could be a problem if there were no more or less commercially 
successful companies behind the Qt. There is a business value in such a tool. 
Of course providing porting as a service might bring more money, but it cannot 
be fully automated anyway.

And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.
Yes, sure. As I said before, it should be OK to automatically convert only the 
most straightforward cases and mark others. Even marking is already a very 
helpful thing.


Vitaly


From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, April 23, 2020 15:55
To: development@qt-project.org 
Subject: [Development] Clang-based refactoring to Qt 6 (Proposal: Deprecate 
QVector in Qt 6)

On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
> Provide clang-based tools to (semi-)automatically port users' code bases to
> a new version of Qt. These tools might either fix a code or at least add a
> comment in potentially problematic places where a user should correct the
> code. A developer who changes API should also implement a rule for these
> tools.

This was discussed in a QtCS two or three years ago. There are two huge
problems with that:

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot
work in all cases either.

2) No one has volunteered to write such conversion scripts.

And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.
--
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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Vitaly Fanaskov]

I think we should completely remove QList in Qt6. It was planned before, as far 
as I remember. The main reason is to be consistent with STL wording and do not 
violate POLA too much.

I read the entire discussion, and I'd like to say this one more time: we don't 
have to fight the consequences. Better to eliminate a cause. There always will 
be a functionality to deprecate. There always will be controversial APIs, that, 
for example, contain a hard-coded type information in the name (e.g. 
"windowList()" instead of "windows()"). Why not think about it instead? Today 
it QVector vs. QList, tomorrow something else...

We can at least shorten release cycle to one year.
Provide clang-based tools to (semi-)automatically port users' code bases to a 
new version of Qt. These tools might either fix a code or at least add a 
comment in potentially problematic places where a user should correct the code. 
A developer who changes API should also implement a rule for these tools.
And of course slightly adjust API design guides.


Vitaly


From: Development  on behalf of Simon 
Hausmann 
Sent: Thursday, April 23, 2020 09:43
To: development@qt-project.org 
Subject: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

(1) Use the same type throughout the public API of Qt.

(2) Make it easy for our users to maintain a code base that works with Qt 5 
and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to QVector. In the light of that, I would like to propose simply 
deprecating QVector and stick to QList everywhere.


What do you think?


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

Re: [Development] Make Qt6 JNI API safer to use

[Vitaly Fanaskov]

Regarding exceptions, I see your point. Personally I agree with using 
exceptions here. If there are no well justified objections, just go for it.


On 3/5/20 4:59 PM, Bogdan Vatra wrote:

Hi,

În ziua de joi, 5 martie 2020, la 17:14:44 EET, Vitaly Fanaskov a scris:

I think something like std::expected is a nice thing to have.

There is some experimental implementation of std::expected:
https://github.com/TartanLlama/expected.


That implementation is my favorite, I really like the map, map_error,
and_then, or_else additions ;-) .

[...]

Regarding using exceptions, well, I would vote for this option, but I
don't think that this is possible at all to convince people to use
exceptions in this module.


A single Qt JNI call might fail in different places, e.g.:
auto str1 = QAndroidJniObject::callStaticObjectMethod("MyClass",
"fromNumber",
"(I)Ljava/lang/String;",
10);

1. check if there is any pending exceptions on current JNI Env
2. check if the method signature is okay
3. check if the method call throw any exceptions

Using exceptions we can pinpoint what happened.

Imagine how hard will be without exceptions to pass as parameters more jni
methods/fields results ...

Cheers,
BogDan.


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company

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

Re: [Development] Make Qt6 JNI API safer to use

[Vitaly Fanaskov]

I think something like std::expected is a nice thing to have.

There is some experimental implementation of std::expected: 
https://github.com/TartanLlama/expected.

Another good example is Result 
(https://doc.rust-lang.org/std/result/index.html) type from Rust. But 
might look clumsy in C++, because there is neither pattern matching nor 
operator? 
(https://doc.rust-lang.org/std/result/index.html#the-question-mark-operator-) 
to handle this case gracefully.

Regarding using exceptions, well, I would vote for this option, but I 
don't think that this is possible at all to convince people to use 
exceptions in this module.

On 3/5/20 1:12 PM, Bogdan Vatra via Development wrote:
> Hi,
>
>I started to review and move androidextras to qtbase (qtbase/src/corelib/
> platform/android). Here we have a problem with our Qt JNI API. The problem is
> that in Java exceptions are (ab)used everywhere. Even if we have a way to
> check for exceptions after each call in Qt, it's not used (not even by us in
> Qt code itself), mostly because it's a little unwieldy to use it. To fix this
> issue I'd like to discuss with you a few options:
>
> 1 - add something similar to std::expected[0] or outcome[1] to Qt. We can't
> use std::optional because it doesn't work for void function e.g.
> std::optional callMethod(). std::expected allows our API users to
> handle the errors without try/catch. I think std::expected will be useful in
> many places not only for QtJNI e.g. QJsonDocument
> QJsonDocument::fromJson(const QByteArray , QJsonParseError *error =
> nullptr) or any other place where we pass the error result as an argument.
> Of course we still need to enable exceptions as if we try to access the
> returned value without checking its state first it will still throw an
> exception if the value is not valid.
>
> 2 - use exceptions (at least for android?). This means if a JNI call fails it
> will throw a C++ exception. IMHO this is by far the best, cleanest and easiest
> solution.
>
> 3 - I'm open for better ideas which makes the coding safer and *easier*.
>
> Cheers,
> BogDan.
>
> [0] https://wg21.link/P0323R9 sadly it's not in c++20 :( therefore we need to
> either use an existing implementation or implement one in Qt.
> [1] https://ned14.github.io/outcome/
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company

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

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Vitaly Fanaskov]

Sounds like a good idea.

It also would be nice to integrate this change with gerrit somehow. For 
example, if you push non-WIP changes and add reviewers, an associated 
task should be moved to "In Review" state automatically.

On 2/17/20 10:13 AM, Edward Welbourne wrote:
> Hi all,
>
> We currently have an "In Progress" state.  In practice when I work on an
> issue, I initially do the work, then put that up for review; the review
> phase takes up fragments of my time for a while, unlike the main work
> phase, which is closer to full-time.  I have more control over (and a
> better ability to estimate) how long the actual work takes, while review
> (and subsequent integration) depends on factors outside my control, that
> are harder to estimate.
>
> (Sometimes, under the present branching model, I also have to put work
> on hold until other work merges up for me to rebase it onto.  However,
> that complication shall go away soon, so I'll ignore it.)
>
> When my team is planning sprints, our scrum master wants to know what
> tasks I'll be working on, and what counts as "Done" for each of them.
> Having a separate state for "In Review", distinct from "In Progress",
> would let us distinguish the relatively plannable, and intense, part of
> the work from the part that (often happens in a later sprint, and)
> takes up a smaller proportion of my time but may take longer.
>
> So I'd like to modify our Jira work-flows to include a distinct "In
> Review" state for when I've completed the main work and am either
> waiting for review or responding to reviewers' comments.  Of course, if
> those comments prompt me to go back and start over, I'll also want to be
> able to go back to the "In Progress" state from it.
>
> Does anyone have any objection to this, or suggestions for a better way
> to handle the relevant work-flow transition ?  If not, I'm hoping Alex
> can work out how to implement what I want ...
>
>   Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

As far as I know, there are no tasks created so far. I agree that we need to 
create a separate task, but not until the final decision.

As it was mentioned in this thread, moving Qt smart pointers to Qt5Compat 
module is not discussed so far. What to do with existing public API that uses 
smart Qt smart pointers is also a question. The best solution, in this case, 
would be porting them to standard smart pointers, I think.

On 2/13/20 12:08 PM, Giuseppe D'Angelo via Development wrote:
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto:
I think that moving Qt smart pointers to Qt5Compat module creates almost
no hassle. For Qt users it should be a one line in the terminal to
replace includes in their code bases (probably also prepend a namespace
to classes' names, but I'm not sure if there is a namespace).

In general, I'd say that this is another problem should be addressed
separately. Feel free to kick off a new thread.

Is there a QTBUG tracking this idea?

It's not "so simple" because Qt smart pointers are being used in a couple of 
public APIs.




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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

I think that moving Qt smart pointers to Qt5Compat module creates almost 
no hassle. For Qt users it should be a one line in the terminal to 
replace includes in their code bases (probably also prepend a namespace 
to classes' names, but I'm not sure if there is a namespace).

In general, I'd say that this is another problem should be addressed 
separately. Feel free to kick off a new thread.

My personal opinion on this topic is that Qt has wrong release cycle 
now. We should make a major release each year (and this year is a good 
time in terms of marketing :) ). The text you quoted is about fighting 
with consequences rather than about fixing a cause.

On 2/12/20 7:37 PM, André Pönitz wrote:
> On Wed, Feb 12, 2020 at 11:13:17AM +0000, Vitaly Fanaskov wrote:
>>>> We should also move Qt smart pointers to Qt5Compat module. The
>>>> destiny of QPointer is not well defined so far.
>>> This was not part of the research and should probably discussed
>>> separately.
>> I agree. But if we decide using standard smart pointers, why
>> should we keep Qt smart pointers as a part of Qt6?
> https://www.qt.io/blog/2019/08/07/technical-vision-qt-6
>
>   "Compatibility with older versions is extremely important and is a
>major requirement when we develop Qt 6. There are billions of lines
>of code written using our framework and any incompatible change we
>do will thus have a cost for our users. Furthermore, the more work
>the change to Qt 6 requires from our users the slower the adoption
>will be, which leads to more cost on our side to maintain the last
>version of Qt 5."
>
> Already now the jump from, say, 5.12 to Qt dev is way bigger than
> the whole Qt 4 -> Qt 5 upgrade was, adding more to that does
> definitely not help with Qt 6 adoption.
>
> Andre'

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Yes, I see your point. The thing is that we need to narrow this 
discussion down and make a decision. Creating something like a wiki page 
would take a long time, I'm afraid. I think that there is should be a 
balance between collecting all possible opinions and trying to 
understand what contributors tend to.

When I was creating the summary, I took into account all opinions and 
arguments of participants. I had to filter out some alternatives or 
suggestions and less sensible and less relevant things. Not doing this 
leads to long and counter-productive discussions.

On 2/12/20 3:42 PM, Alberto Mardegan wrote:
> On 12/02/20 15:20, Vitaly Fanaskov wrote:
>>> AFAIK, we don't have a procedure to make project-level decisions by 
>>> majority vote.
>> True. We're discussing now. The goal here is to take people opinions and
>> arguments into account before making a decision.
> The problem I see, is that in your summary you are only reporting those
> options that have had more consensus (or at least, according to the way
> you perceived the discussion going); but in doing so, you are already
> filtering out the alternatives, and therefore paving the road for a
> decision.
>
> Maybe what we should do is to collect all the different proposals and
> let people fill them with pros and cons (wiki style) and then you can
> proceed with a decision?
> In this way, you'd also avoid people repeating the same positions over
> and over the place.
>
> (not that I have a positive experience with the wiki approach either;
> but at least you are sure that all people taking the decision will be
> aware of all the points for and against every alternative).
>
> Ciao,
>Alberto
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> AFAIK, we don't have a procedure to make project-level decisions by majority 
> vote.
True. We're discussing now. The goal here is to take people opinions and 
arguments into account before making a decision.

We have intermediate results of the discussion now. Next step is 
collecting the rest of feedback we can. Only after we should make a 
decision and define resulting artifacts (docs, recommendations, user 
stories, blog posts, etc.).

On 2/12/20 12:42 PM, Konstantin Tokarev wrote:
>
> 12.02.2020, 12:36, "Vitaly Fanaskov" :
>>>   You seem to repeat your initial statements.
>> Yes, because most of the participants of this discussion tend to agree,
>> as far as I can see.
> AFAIK, we don't have a procedure to make project-level decisions by majority 
> vote.
>
> If we want to achieve anything more constructive than just summarizing 
> opinions, these
> ways are possible:
> 1) discuss Daniel's patch in Gerrit and get it approved or rejected;
> 2) someone could come up with another proposal in of form of (possibly WIP) 
> patch
> and get it formally reviewed in the same way;
> 3) someone could come up with a text of QUIP and get it formally reviewed
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

>> We should also move Qt smart pointers to Qt5Compat module. The destiny
>> of QPointer is not well defined so far.
> This was not part of the research and should probably discussed separately.
I agree. But if we decide using standard smart pointers, why should we 
keep Qt smart pointers as a part of Qt6? It would be a duplication in 
this case. I thought that it is just a logical consequence.

On 2/12/20 11:57 AM, Karsten Heimrich wrote:
> Many thanks Vitaly for taking the time and effort to get the discussion going.
>
> -Original Message-
>> From: Development On Behalf Of Vitaly 
>> Fanaskov
>> Sent: Dienstag, 11. Februar 2020 16:15 Uhr
>> To: development @qt-project.org
>> Subject: Re: [Development] The future of smart pointers in Qt API
>>
>> I want to summarize intermediate results of the discussion and return it 
>> back to the track.
>>
>>
>> Subject: using smart pointers in the API.
>> Good idea.Better to use than not because of automatic lifetime
>> management, explicit ownership semantics, and code base maintainability
>> is simpler.However, it doesn’t mean that this is a mandatory choice for
>> all API, just a recommended way so far.
> If the outcome of this discussion is to not use/ introduce smarter pointers 
> in our public API's right now, it's still worth considering an update to our 
> API design principles for new modules.
>
>> Subject: standard smart pointers vs. Qtish wrappers.
>> In general, people want to use standard smart pointers.There are a few
>> main reasons: std-things are already in Qt API, this is a part of C++
>> language standard, it requires almost no maintainability, people outside
>> of Qt ecosystem most likely get used to standard smart pointers for nine
>> years.
> I can only second that, we should not invent our own wrappers around std:: 
> smart pointers just for the shake of typography.
>
>> We should also move Qt smart pointers to Qt5Compat module. The destiny
>> of QPointer is not well defined so far.
> This was not part of the research and should probably discussed separately.
>
>> Subject: raw pointers for passing mandatory parameters vs. using
>> references.
>> Allow both approaches, recommend using references (and/or smart
>> pointers) when acceptable. Not too many arguments collected here, just
>> try to make Qt API more modern.
> I think because most of the discussion has been centered around the use of 
> smart pointers in widgets/layouts/ui centric stuff, we might have lost view 
> on the way more generic uses of raw pointers in our API. Some of our classes 
> return raw pointers (QModbusReply and things like that come to my mind), 
> where ownership is not clear/ now well documented/ not documented at all; and 
> I can clearly see said API's benefit of the introduction of smart pointers.
>
>> There are a few irrelevant discussions. Start a new thread if you want
>> to continue discussing them, please.
>>
>>
>> Irrelevant subject: smart pointers vs.parent-child lifetime management
>> model.
>> It’s too fragile to touch in Qt6.Adding smart pointers around is
>> questionable solution, it’s unclear whether it worth doing or not.
>> Having two different but coupled mechanisms for lifetime management is
>> not such a good idea.
> True. We might not be able to address it for Qt6, but I think it's still 
> worth to keep in mind and re-question the current approach. Daniels patch 
> seems to be the best starting point so far.
>
> -- Karsten

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> You seem to repeat your initial statements.
Yes, because most of the participants of this discussion tend to agree, 
as far as I can see.

On 2/11/20 8:19 PM, André Pönitz wrote:
> On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote:
>> I want to summarize intermediate results of the discussion and return it
>> back to the track.
>>
>>
>> Subject: using smart pointers in the API.
>> Good idea. Better to use than not because of automatic lifetime
>> management,
> *shrug*
>
> You seem to repeat your initial statements.
>
> QObject parents _do_ manage lifetime to start with.
>
>> Subject: raw pointers for passing mandatory parameters vs. using
>> references.
>> Allow both approaches, recommend using references (and/or smart
>> pointers) when acceptable.
>> Not too many arguments collected here, just
>> try to make Qt API more modern.
> Again only your statement.
>
> The issue itself has been discussed over and over again.
>
> Allowing _both_ I have not seen actively endorsed by anyone,
> this only makes a messy incosnsistent API.
>
>> There are a few irrelevant discussions. Start a new thread if you want
>> to continue discussing them, please.
>>
>> Irrelevant subject: smart pointers vs. parent-child lifetime management
>> model.
> Sure. Because it would void the 'lifetime management' line of reasoning.
>
> Andre'

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

I want to summarize intermediate results of the discussion and return it 
back to the track.


Subject: using smart pointers in the API.
Good idea. Better to use than not because of automatic lifetime 
management, explicit ownership semantics, and code base maintainability 
is simpler. However, it doesn’t mean that this is a mandatory choice for 
all API, just a recommended way so far.


Subject: standard smart pointers vs. Qtish wrappers.
In general, people want to use standard smart pointers. There are a few 
main reasons: std-things are already in Qt API, this is a part of C++ 
language standard, it requires almost no maintainability, people outside 
of Qt ecosystem most likely get used to standard smart pointers for nine 
years.
We should also move Qt smart pointers to Qt5Compat module. The destiny 
of QPointer is not well defined so far.


Subject: raw pointers for passing mandatory parameters vs. using 
references.
Allow both approaches, recommend using references (and/or smart 
pointers) when acceptable. Not too many arguments collected here, just 
try to make Qt API more modern.


There are a few irrelevant discussions. Start a new thread if you want 
to continue discussing them, please.


Irrelevant subject: smart pointers vs. parent-child lifetime management 
model.
It’s too fragile to touch in Qt6. Adding smart pointers around is 
questionable solution, it’s unclear whether it worth doing or not. 
Having two different but coupled mechanisms for lifetime management is 
not such a good idea.

Irrelevant subject: something about Qt containers.

On 1/31/20 11:07 AM, Vitaly Fanaskov wrote:
> Hello everyone,
>
> We’ve been discussing for a while how Qt6 API can be improved with using
> smart pointers. Recently we came into some conclusions and want to
> discuss them with the community.
>
> Smart pointers are for sure much better to use than raw pointers for
> many reasons. They manage lifetime automatically, show ownership
> semantic, and make code safer. It’s planned to officially recommend them
> to use in Qt6 API instead of raw pointers whenever this is possible. For
> sure, it should only be a choice for newly designed API.
>
> But how to use them in the API and which way is preferable is still
> unclear. There are two main options we have:
>
> 1) Use std::*  smart pointers as-is.
>
> 2) Add Qt-style wrappers around std::* smart pointers and move old
> implementations of Qt smart pointers to the Qt5Compact module.
>
> Both options have pros and cons. It would be useful to hear your
> thoughts on it. It’s worth mentioning that some other options, like
> using Qt smart pointers as-is, were also discussed. They were found less
> suitable, but feel free to share your opinion if you disagree.
>
> Another thing to discuss is whether we should use raw pointers in the
> API at all or not. There are a few options again:
>
> 1) Yes
>
> 2) No. Use “modern” approaches instead (pass mandatory dependencies by
> either reference or const reference when using smart pointers makes no
> sense, use something optional-like or tuples to return extra data from
> functions, and so on)
>
> 3) Mix 1 and 2.
>
> There are pros and cons for all options. Share your opinion once again,
> please.
>
> If there are any related things to discuss, let’s do that in this thread.
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> Annotations could be used on the header files, and qdoc
> could be smart enough to present them in a clear way.
It could be a solution. However, I don't think that this is possible to 
have annotations for all objects passed or returned by raw pointers.

Another thing is that you usually need to perform some action to see an 
annotation (hover-over, for example) and it usually provides more 
information than you need for case we're discussing.

I think that having annotations is a good but optional thing and cannot 
solve identified issues with raw pointers. There are many tools that 
might help you fight various issues, but probably this is worth not 
having issues when it possible, rather than create them and then fight?

> But this seems to be a point for *not* using std::, isn't it? We also
> want Qt to be used with a program that does *not* use exceptions.
>
> What would happen if one of the STL classes publicly used in the Qt API
> gained some method that can throw an exception (not just in OOM cases,
> but as part of a common scenario)?
Well, this is another issue, which should probably be addressed 
separately for each new std:: type added to the API. But on the other 
hand, we have some recommendations how to deal with exceptions at some 
cases: https://doc.qt.io/qt-5/exceptionsafety.html. Perhaps we will have 
to extend documentation.

I also don't think that this is something we should worry about when 
discussing adding smart pointers.

On 2/4/20 4:16 PM, Alberto Mardegan wrote:
> On 04/02/20 16:55, Vitaly Fanaskov wrote:
>> But if you see API like this:
>>
>> std::unique_ptr someAPI();
>>
>> You have much more information about managed object just by reading the
>> code. This is also much easier to understand what can or cannot be done
>> with the returned value in the example above.
> True. I still think that the benefit it's not worth the imposition of
> smart pointers. Annotations could be used on the header files, and qdoc
> could be smart enough to present them in a clear way.
>
>> There also were good arguments about exceptions. We shouldn't forget
>> that Qt can be used with a program that uses exceptions.
> But this seems to be a point for *not* using std::, isn't it? We also
> want Qt to be used with a program that does *not* use exceptions.
>
> What would happen if one of the STL classes publicly used in the Qt API
> gained some method that can throw an exception (not just in OOM cases,
> but as part of a common scenario)?
>
> Ciao,
>Alberto
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> Not using smart pointers in our API (neither the Qt's or the std:: ones)
> allows each developer to use his own preferred solution with a minimal
> effort. People might want to use boost smart pointers, SaferCPlusCplus,
> or even their own handcrafted smart pointer templates. I don't think
> that Qt should make a choice for them.
The huge integration problem is that it's not always clear which object 
handles lifetime of which object and when ownership is transferred. It 
makes a process of integration with smart pointers painful and hardly 
possible.

For example what can you tell about object's lifetime if you see a code 
like this:

Foo *someAPI();

or

someAPI(Foo *ptr);

Usually, not too much. You need to either read a documentation or an 
implementation. This is also not that easy to catch a moment when object 
is deleted.

But if you see API like this:

std::unique_ptr someAPI();

You have much more information about managed object just by reading the 
code. This is also much easier to understand what can or cannot be done 
with the returned value in the example above.

There also were good arguments about exceptions. We shouldn't forget 
that Qt can be used with a program that uses exceptions.

On 2/4/20 12:24 PM, Alberto Mardegan wrote:
> Going back to the original question again, as I'm not sure I agree with
> this claim:
>
> On 31/01/20 13:07, Vitaly Fanaskov wrote:
>> Smart pointers are for sure much better to use than raw pointers for
>> many reasons. They manage lifetime automatically, show ownership
>> semantic, and make code safer. It’s planned to officially recommend them
>> to use in Qt6 API instead of raw pointers whenever this is possible. For
>> sure, it should only be a choice for newly designed API.
> I ran a quick grep over QtBase's source code, and indeed it looks like
> QSharedPointer and QScopedPointer are not used in the public API. But is
> this bad?
>
> Just imagine if we had been spreading Q{Shared,Scoped}Pointer all over
> Qt's API in Qt4 times: we probably would not even be having this
> conversation now, as switching from the Qt pointer classes to the std::
> ones might have been way too problematic.
>
> So, if, from this perspective, it's good that Qt has not embraced (Qt)
> smart pointers before, I'm tempted to draw the conclusion that it would
> be a wise idea to continue avoiding embracing a specific smart pointer
> implementation.
>
> Not using smart pointers in our API (neither the Qt's or the std:: ones)
> allows each developer to use his own preferred solution with a minimal
> effort. People might want to use boost smart pointers, SaferCPlusCplus,
> or even their own handcrafted smart pointer templates. I don't think
> that Qt should make a choice for them.
>
> Ciao,
>Alberto
>
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

I think that this case might be handled by using a smart pointer with a custom 
empty deleter. In this case we have absolutely the same potential issues as 
with a raw pointer to a stack object. Strictly speaking, something like that 
requires a great care and I'd recommend avoiding such approach.

On 2/4/20 1:22 PM, Konstantin Shegunov wrote:
On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov 
mailto:vitaly.fanas...@qt.io>> wrote:
I think, if we decide to re-implement parent-child model using smart
pointers, we would not use unique pointers at all. Even in a methods
like QObject::makeChild (because ownership is already defined). Shared +
weak pointers make perfect sense here.

You have to be really crafty. Allocating on the stack is a thing, you know, 
even for parent-child trees, so how do you intend to handle that? Are we again 
in "forget the stack and new everything" land?

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

I think, if we decide to re-implement parent-child model using smart 
pointers, we would not use unique pointers at all. Even in a methods 
like QObject::makeChild (because ownership is already defined). Shared + 
weak pointers make perfect sense here. The main reason is that many 
other objects might need to store weak references to a child of QObject, 
and I don't see how to properly utilize unique pointer in this case.

Just in case, it was only my assumptions. No decisions were made, no 
proper experiments were performed.

On 2/4/20 9:28 AM, Fawzi Mohamed wrote:
> Hi Daniel,
> I agree with most of your choices, and yes there will be cases where a change 
> in QT is required.
> What I did not fully understand is why you did not go the whole way and used 
> unique_ptr also  in QObject, as Vitaly suggested: your invariant is either 
> owned by a unique_ptr or a QObject, if QObject uses unique_ptr then it 
> reduces to unique_ptr ownership.
> Do you get too much boilerplate, or need to continuously get the raw pointer?
> Maybe you told already, and I missed it, but that could also show the issues 
> of using unique_ptr.
> To me it seems that it makes ownership in our API clearer, and that is a win, 
> but André’s comments I think show his concern with bloating up code and 
> conceptual burden for little or no gain.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Yes in a current architecture it could be complicated. But if case of 
layouts, ownership is transferred to a layout. Other items might keep a 
weak references to a widget. Removing a widget invalidates all weak 
references. But, again, this only an assumption how it could be implemented.

I actually tend to agree that parent-child relationship model is 
fundamentally wrong, at least as it implemented now. It responsible for 
different things: memory management, event handling, and visual 
positioning. Memory management could be handled by smart pointers, and 
if we really need using trees for two other things, that it should be 
explicit models based on n-ary tree. In this case, I think we won't have 
this confusing definitions like "visual parent" and "just a parent" 
(that we have in controls).

Unfortunately, writing Qt (at least UI part) from scratch might be 
easier than implementing something like that :) Start using smart 
pointers sounds more realistic.

On 2/3/20 3:33 PM, Konrad Rosenbaum wrote:
> On 2020-02-03 15:04, Vitaly Fanaskov wrote:
>> We don't need this method at all if everything is implemented with using
>> smart pointers.
>
> What about the case when I want to delete a Widget from my window 
> without closing the window?
>
> I often use deleteLater() because it is much easier than remembering a 
> dozen layers of layouts and widgets that simply serve some 
> layouting-purpose.
>
>
> Konrad
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

We don't need this method at all if everything is implemented with using 
smart pointers.

On 2/2/20 6:17 PM, Иван Комиссаров wrote:
> Can we please return to the discussion about QObject parent/child with smart 
> pointers rather than discussing Qt/stl naming?
>
> No one answered my question about QObject::deleteLater:
>
>> And what about the QObject::deleteLater() method? Any ideas how this should 
>> look like with smart pointers?
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

If we're going for this logical fallacy, then let's up the ante: a unique 
pointer is just a shared pointer without copy semantics. Why not using shared 
pointers everywhere?
Well, I hope it was rhetorical question, please, let me know if not.

The difference between shared pointer and unique pointer is fundamental. But 
there is no fundamental difference between unique pointer and scoped pointer. 
The both uniquely own a resources and resource lifetime is equal to smart 
pointer lifetime unless it explicitly prolonged. The only difference is a way 
how you can do that. In case of scoped pointer you can invoke method "take", in 
case of unique pointer you can also use move semantic. Looks like that scoped 
pointer is just yet another redundant entity.

Introducing an alias should satisfy some people who used to use scoped pointer.

And an example where I cannot replace a unique pointer with a shared pointer 
without losing readability and maintainability?
A straw man? Please, stop.

Like this?

std::unique_ptr ptr = ~~~;
return ptr;
For example. With a scoped pointer it's a bit harder to do that, but also 
possible, I think, for example:

QScopedPointer ptr = ~~~;
return QScopedPointer(ptr.take());

Which one would be the redundant one?
Obviously scoped pointer. I've described why.

What? This is absurdly false -- the Standard Library is part of the C++ 
standard itself.
Which doesn't mean that this is a part of the programming language. If you read 
carefully some parts of the standard, you can notice that, for example smart 
pointers or containers are not mandatory. For example:

"This Clause describes components that C ++ programs may use to organize 
collections of information."

Just a recommendation or an assumption. But this is a rabbit hole. I don't want 
to argue here. This is not related to the main topic.

Please also see this from the eyes of someone else who comes from a general 
purpose C++ background, where usage lock() is established (for how much absurd 
that naming choice is); then gets the Qt equivalent, and wonders why it 
_hasn't_ got lock(), despite Qt having 0.something% of the C++ market share.
Yes, I see what you mean and I entirely agree. We should think how to have some 
compromise here.

And again see this the other around too: many C++ users get used to the 
C++/Boost/Abseil/... naming convention and may find Qt ones "unusual".
Possible. But we're discussing Qt and its ecosystem and we also have to care 
about Qt users.

Changing the interface in any way which are incompatible with the Standard 
counterparts is a _terrible_ idea. It kills the principle of least surprise; it 
makes such facilities incompatible with the STL counterparts, preventing 
interexchange of data and code; and come Qt (N+1), it will prevent a clean pass 
of s/QtFoo/std::foo/g over the codebase.
It's not a big issue if we have Qt wrappers around std smart pointers. A 
standard smart pointer that is under the hood should be easily accessible.

Regarding POLA, it works both ways. If you have Qtish something you usually 
don't expect that this is fully compatible with STL counterpart. Which is 
probably not good, but here we are. In case of Qt wrappers around smart 
pointers, having them at least easily convertible to std pointers is a good 
move.

This is wishful thinking, or, famous last words.

First: it costs in terms of development bandwidth that is NOT being used to 
improve the areas where Qt should shine; it's instead used for reinventing 
wheels.

Second: history proves this false. See for instance the story with Qt 
containers, which are *still* missing range insertion (C++98) (and some range 
construction), emplacement (C++11), support for move-only types (C++11), and so 
on. On what grounds should one believe that after 9 years suddenly Qt will 
catch up with the development of these building blocks?
Well, yes, I tend to agree here. At least with the last paragraph for sure.

How do you integrate QSharedPointer with std::shared_ptr exactly?
If QSharedPointer is just a wrapper around std::shared_pointer it should be 
easy. Adding one more constructor and an operator to the wrapper.

On 2/2/20 12:12 AM, Giuseppe D'Angelo wrote:
Hi,

Il 01/02/20 22:55, Vitaly Fanaskov ha scritto:
   The consensus was reached against such a decision. A scoped pointer
   should not be able to escape scope. Yes, in C++17 this is now not
   entirely true, but the name strongly implies it.

Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity 
in light of modern C++. It's just an unique pointer without move semantic.

If we're going for this logical fallacy, then let's up the ante: a unique 
pointer is just a shared pointer without copy semantics. Why not using shared 
pointers everywhere?


Please, give me at least one example when I cannot replace scoped pointer with 
unique pointer without losing readability and maintainability.

And an example where I c

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

>   The consensus was reached against such a decision. A scoped pointer 
>   should not be able to escape scope. Yes, in C++17 this is now not 
>   entirely true, but the name strongly implies it.

Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity 
in light of modern C++. It's just an unique pointer without move semantic. 
Please, give me at least one example when I cannot replace scoped pointer with 
unique pointer without losing readability and maintainability. Unique pointer 
could "escape a scope" only explicitly. So I'm still not convinced that we need 
to have one more redundant entity. We have more than enough. This is possible 
to introduce an alias just to keep naming convention people get used to, I 
guess, but I'm not sure if this is really required.

> About QUniquePointer: what's the point of reinventing std::unique_ptr 
> under a different name?

So, first of all, not reinventing. I'd say adopting. The main question I see 
through some your posts in this thread is "why do we need Qtish wrappers at 
all?". Correct me if I'm mistaken, please. Until that I'll answer this question 
__
There are a few pros of having Qt wrappers around std smart pointers. To make 
it clear, saying "Qt wrapper" I mean a class that contains std smart pointer as 
a field and has more Qtish interface. Not inherits a std smart pointer.

Pros I can see:
1) Qt style
STL has different naming convention that looks alien to Qt API. It leads to 
inconsistency. STL is not a part of C++ language itself and cannot be 
considered as a default standard.
The fact that some people might get used to some names doesn't mean that these 
names are good in terms of self-explanatory. For example, how do I understand 
without documentation what does "weak_ptr::lock" do? Something like 
"asStrongRef" is easily understandable just by reading code.
I'm not 100% sure who is responsible for naming STL classes and methods, but 
this person(s) did really good job in terms of reducing symbols count. I'm just 
wondering why not "w_p::l" instead of "weak_ptr::lock", it looks much shorter!  
In my opinion, we shouldn't sacrifice readability to reduce symbols count.
After all, many Qt users get used to Qt naming convention and style.

2) Flexibility
It will be much easier to extend or reduce interface if we need it. Changing 
implementation is also will be easier if someone needs to have a different 
smart pointers under the hood on some platforms.

3) Low maintenance costs
We just need to replicate an API at first implementation. After that, 
introducing new methods that might occur in an upcoming standards should be 
easy enough.

4) Easy to integrate with std smart pointers
A few constructors/operators/methods could solve this problem. It means that it 
should be possible to integrate with a code written with using std pointers.

Finishing this, I'd like to say that having consistent APIs that don't violate 
principle of less astonishment is important thing. That's the main reason why 
personally I vote for the option with Qt wrappers.

On 01/02/2020, 00:48, "Giuseppe D'Angelo via Development" 
 wrote:

On 31/01/2020 23:46, Vitaly Fanaskov wrote:
> I'd suggest QUniquePointer. Honestly, I don't think we have too many 
alternatives here. We can try Rust-like naming (something like QBox), but it 
just looks weird and tells nothing about ownership semantics.
> 
> After that we can write "using QScopedPointer = QUniquePointer" 

The consensus was reached against such a decision. A scoped pointer 
should not be able to escape scope. Yes, in C++17 this is now not 
entirely true, but the name strongly implies it.

About QUniquePointer: what's the point of reinventing std::unique_ptr 
under a different name?

* Is it just going to be an alias, to be more Qtish? Then why 
QSharedPointer is NOT going to be an alias?

* Is it not going to be an alias? NIH all over again?

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



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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

 > Can you maybe show some proof-of-concept pseudo-code how the typical
 >  current user code looks like that you intent to improve, and how
 > it will look like afterwards?

Sound like a good idea. I'll try to implement something to demonstrate this 
approach.

On 31/01/2020, 22:11, "André Pönitz"  wrote:

On Fri, Jan 31, 2020 at 03:27:29PM +0000, Vitaly Fanaskov wrote:
> Not abandoning, I think, but re-implementing properly. Raw pointers 
> cause some certain problems here and changing them to something more 
> smart would be nice. But it doesn't mean that we should get rid of 
> parent-child model entirely. The point is that we can make it more 
> explicit just by using smart pointers.

Can you maybe show some proof-of-concept pseudo-code how the typical
current user code looks like that you intent to improve, and how
it will look like afterwards?

> To make it clear, there is no decision made. We're just discussing.

Right.

And thank you for doing that.

I was already becoming afraid that we might be running out of
disputable items lately.

Andre'


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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> What would you then name a Qt counterpart of std::unique_ptr, considering that
>  QScopedPointer is not such a counterpart?

I'd suggest QUniquePointer. Honestly, I don't think we have too many 
alternatives here. We can try Rust-like naming (something like QBox), but it 
just looks weird and tells nothing about ownership semantics.

After that we can write "using QScopedPointer = QUniquePointer" for people who 
get used to old scoped pointer and want to highlight the fact that a resource 
will be released at the end of the scope. But personally I think we don't need 
to have one more entity without a real reason to do that.

On 31/01/2020, 21:07, "Development on behalf of Ville Voutilainen" 
 
wrote:

On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan
 wrote:
>
> Old man here:
>
> On 31/01/20 13:07, Vitaly Fanaskov wrote:
> > But how to use them in the API and which way is preferable is still
> > unclear. There are two main options we have:
> >
> > 1) Use std::*  smart pointers as-is.
> >
> > 2) Add Qt-style wrappers around std::* smart pointers and move old
> > implementations of Qt smart pointers to the Qt5Compact module.
>
> 2.
>
> I still have trouble understanding why std::unique_ptr is called like
> this, whereas I could immediately understand what QScopedPointer does
> even before reading its documentation.

What would you then name a Qt counterpart of std::unique_ptr, considering 
that
QScopedPointer is not such a counterpart?
___
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] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Well, I think there are at least two cases.

1) Objects managed by smart pointers not necessary to be QObjects. In 
this case, everything is clear. We can use smart pointers without any 
issues.

2) Current implementation of parent-child relationships. Daniel's patch 
mentioned earlier in this thread is an example of how we can use smart 
pointers with current parent-child model.

My personal opinion regarding 2, that it should be just properly 
implemented with using smart pointers. However, it will be tough for 
existing code bases to adopt it.

On 1/31/20 4:23 PM, Matthew Woehlke wrote:
> On 31/01/2020 05.07, Vitaly Fanaskov wrote:
>> We’ve been discussing for a while how Qt6 API can be improved with using
>> smart pointers. Recently we came into some conclusions and want to
>> discuss them with the community.
>>
>> Smart pointers are for sure much better to use than raw pointers for
>> many reasons. They manage lifetime automatically, show ownership
>> semantic, and make code safer.
> QObject already has these features since forever. How do you plan for
> this to interact with existing lifetime and ownership management via
> QObject?
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Not abandoning, I think, but re-implementing properly. Raw pointers 
cause some certain problems here and changing them to something more 
smart would be nice. But it doesn't mean that we should get rid of 
parent-child model entirely. The point is that we can make it more 
explicit just by using smart pointers.

To make it clear, there is no decision made. We're just discussing.

On 1/31/20 4:13 PM, Eric Lemanisser wrote:
> Are we really considering abandoning the parent-child ownership for
> qt6 ? that would be a huge breaking change
>
>>  I would like to separate pointers with simple ownership and complicated 
>>  ownership. We could solve passing of raw pointers with simple ownership 
>>  first using standard smart pointers. Where as the more complicated 
>> pointers  would require special classes like those Daniel Teske has been 
>> working on. I'm not sure how to properly identify what is the "complicated 
>> ownership". I don't think that there are places in Qt API where we really 
>> need something more complicated than regular shared/weak/unique pointers. 
>> Even intrusive pointers are not required I guess. When you think about 
>> something more complicated, this is probably an architectural problem (like 
>> with parent-child) or bad API design. Can you provide some real examples 
>> where we need something more complicated than regular smart pointers, please?

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> I would like to separate pointers with simple ownership and complicated
> ownership. We could solve passing of raw pointers with simple ownership
> first using standard smart pointers. Where as the more complicated pointers
> would require special classes like those Daniel Teske has been working on.
I'm not sure how to properly identify what is the "complicated 
ownership". I don't think that there are places in Qt API where we 
really need something more complicated than regular shared/weak/unique 
pointers. Even intrusive pointers are not required I guess. When you 
think about something more complicated, this is probably an 
architectural problem (like with parent-child) or bad API design.

Can you provide some real examples where we need something more 
complicated than regular smart pointers, please?

On 1/31/20 3:30 PM, Allan Sandfeld Jensen wrote:
> On Friday, 31 January 2020 11:07:52 CET Vitaly Fanaskov wrote:
>> Hello everyone,
>>
>> We’ve been discussing for a while how Qt6 API can be improved with using
>> smart pointers. Recently we came into some conclusions and want to
>> discuss them with the community.
>>
>> Smart pointers are for sure much better to use than raw pointers for
>> many reasons. They manage lifetime automatically, show ownership
>> semantic, and make code safer. It’s planned to officially recommend them
>> to use in Qt6 API instead of raw pointers whenever this is possible. For
>> sure, it should only be a choice for newly designed API.
>>
>> But how to use them in the API and which way is preferable is still
>> unclear. There are two main options we have:
>>
>> 1) Use std::*  smart pointers as-is.
>>
>> 2) Add Qt-style wrappers around std::* smart pointers and move old
>> implementations of Qt smart pointers to the Qt5Compact module.
>>
> I would like to separate pointers with simple ownership and complicated
> ownership. We could solve passing of raw pointers with simple ownership
> first using standard smart pointers. Where as the more complicated pointers
> would require special classes like those Daniel Teske has been working on.
>
> An example is water testing change I made: https://codereview.qt-project.org/
> c/qt/qtbase/+/284769
>
> The ownership is simple, and the std api supplementing the existing one,
> without needed ABI or API changes.
>
> best regards
> 'Allan
>
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Hi Daniel,

I'm confused that there's zero discussion of the work I have done in showing 
how adding unique_ptr apis would look like. Surely, you have internally 
discussed that approach.
Yes, I saw this patch (https://codereview.qt-project.org/c/qt/qtbase/+/260618). 
It looks good as an example of using unique pointers.

My personal opinion that we have another fundamental problem in the 
implementation of parent-child relationship in Qt. Ditto for the related 
interfaces. The problem is that everything is implemented with using raw 
pointers and some implicit contracts (like, "a parent removes its children").  
The proper solution is re-implement it using smart pointers. For example, each 
QObject stores a vector of shared pointers to children and a weak pointer to 
its parent. With this "simple" approach we can implement proper API and get rid 
of entities we don't really need, like QPointer for example.

I don't think that adding another level of abstraction and introducing new 
entities is such a good solution here. Better to solve a cause rather than 
fight consequences.

How did you come to this conclusion?
Let me elaborate a bit. My suggestion was in using smart pointers for newly 
added API and transfer old API when we have time for it. It makes sense if we 
decide using smart pointers, I think.

* There's existing tooling around unique_ptr, and there would be none for any 
wrappers.
Which tooling do you mean?

On 1/31/20 2:23 PM, Daniel Teske wrote:
Hi,

I'm confused that there's zero discussion of the work I have done in showing 
how adding unique_ptr apis would look like. Surely, you have internally 
discussed that approach.

Also I'm sad to see that instead of using public mailing lists, you seem to 
have discussed this extensively internally.

For sure, it should only be a choice for newly designed API.
How did you come to this conclusion?

1) Use std::*  smart pointers as-is.

2) Add Qt-style wrappers around std::* smart pointers and move old
implementations of Qt smart pointers to the Qt5Compact module.

Both options have pros and cons. It would be useful to hear your
thoughts on it. It’s worth mentioning that some other options, like
using Qt smart pointers as-is, were also discussed. They were found less
suitable, but feel free to share your opinion if you disagree.

Using a standard class as is the right answer, because:

* Qt should position itself so that it benefits from innovation happening in 
the standard. Greater interoperability should be a goal. (Not just for smart 
pointers, but in general.)
* There's existing tooling around unique_ptr, and there would be none for any 
wrappers.
* Mixing std code and qt code is easier when they use the same vocabulary types.
* The existing smart pointers in qt have less capable API than the std ones.
   Expecting this to be different the next time seems foolish.
* unique_ptr is 9 years old. It's behaviour is well understood in the wider C++ 
community.
* There's a feeling that Qt has a NIH problem in the wider C++ community

daniel



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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

Hello everyone,

We’ve been discussing for a while how Qt6 API can be improved with using 
smart pointers. Recently we came into some conclusions and want to 
discuss them with the community.

Smart pointers are for sure much better to use than raw pointers for 
many reasons. They manage lifetime automatically, show ownership 
semantic, and make code safer. It’s planned to officially recommend them 
to use in Qt6 API instead of raw pointers whenever this is possible. For 
sure, it should only be a choice for newly designed API.

But how to use them in the API and which way is preferable is still 
unclear. There are two main options we have:

1) Use std::*  smart pointers as-is.

2) Add Qt-style wrappers around std::* smart pointers and move old 
implementations of Qt smart pointers to the Qt5Compact module.

Both options have pros and cons. It would be useful to hear your 
thoughts on it. It’s worth mentioning that some other options, like 
using Qt smart pointers as-is, were also discussed. They were found less 
suitable, but feel free to share your opinion if you disagree.

Another thing to discuss is whether we should use raw pointers in the 
API at all or not. There are a few options again:

1) Yes

2) No. Use “modern” approaches instead (pass mandatory dependencies by 
either reference or const reference when using smart pointers makes no 
sense, use something optional-like or tuples to return extra data from 
functions, and so on)

3) Mix 1 and 2.

There are pros and cons for all options. Share your opinion once again, 
please.

If there are any related things to discuss, let’s do that in this thread.

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] Changes to Qt offering

[Vitaly Fanaskov]

> That fork will be necessary because you can't just switch
> projects like KDE from Qt 5 to Qt 6 overnight, it will take years to do it!
In light of this, it's probably worth thinking about releasing a new 
major version of Qt each year. It also might solve some other problems. 
So, how about Qt 2020 instead of Qt6? :)

On 1/28/20 8:46 AM, Bogdan Vatra via Development wrote:
> În ziua de marți, 28 ianuarie 2020, la 08:37:47 EET, Benjamin TERRIER a scris:
>> Le mar. 28 janv. 2020 à 03:22, Thiago Macieira 
>>
>> a écrit :
>>> On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko
>>>
>>> wrote:
 Assuming we have a VM that is restricted to connecting to the internet,
>>> we
>>>
 previously could dump the installer there and install Qt.
 Now, we need to have an intermediary PC with the same OS to first
 install
 the binaries via online installer and then copy those binary files to
>>> that
>>>
 first VM.

 This is an extraneous and completely artificial step for absolutely no
 reason other than TQtC paywalling them, which is ridiculous.
>>> Previously, you anonymously downloaded the offline installer from another
>>> machine, then copied it over to the VM, and installed there.
>>>
>>> Now you're going to download the offline installer from another machine
>>> after
>>> typing your password, then copy over to the VM and install there.
>>>
>>> What's the hurdle?
>> You might have missed the info because it is in the blog post, but not in
>> Lars email:
>>
>> There will be no more open source offline installer.
>>
>> For binaries, open source users will only have access to the online
>> installer that will require a Qt Account.
>Folks, you have to understand that The Qt Company must pay its developers!
>I really don't bother if there will be offline installers only for 
> commercial
> customers. Or if they will require an username to download from the
> online installer. Right now I'm not typing my user & pass just because the
> pass it's randomly generated and I'm too lazy to open my passwords app to get
> it.
>
>What I'm worried about is that there will be a 5.15 fork after TQC will
> close that branch. That fork will be necessary because you can't just switch
> projects like KDE from Qt 5 to Qt 6 overnight, it will take years to do it!
> In all these years, all linux distributions that will ship Qt 5, will need
> regular updates with bug fixes, and because Qt 5.15 branch it's closed they
> will have to use either a "community" fork where all these distros will share
> their bugfixes or they will have their own patches. This means, it will be bad
> for TQC, because if these patches are not contributed via gerrit (CLA), TQC
> can't use them for commercial customers.
>
> Cheers,
> BogDan.
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] QHash for Qt 6

[Vitaly Fanaskov]

> I'm not totally sure I understand this point. What do you mean by 
> "memory management"? 
Inside of containers you need to allocate and de-allocate memory. If 
container is passed across a library boundary, there is a question what 
version of new/delete should be used. But this can be "easily" solved by 
providing allocators. Probably.

> Binary compatibility of stdlib is not an issue
So, you think that this is easy to achieve binary compatibility with 
many C++ compilers and standard libraries we have? For example, if Qt is 
built with one version of MSVC, but used in a program build with another 
version of MSVC. This is nice if there are some guarantees at least for 
main platforms. I heard that gcc and clang give some guarantees, but 
this not enough, I think.

> consistency for containers shouldn't really be either
Regarding consistency, it's not only containers' implementation. This is 
also about Qt APIs consistency: if it will be decided using std::* 
containers, they should be used instead of all Qt containers, but not 
instead of some of them. I guess, we should provide more or less solid 
user experience.

On 12/20/19 3:10 PM, Giuseppe D'Angelo wrote:
> Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
>> This is not that easy to use std::* containers because at least the 
>> following issues have to be addressed:
>>
>>   * Memory management
>>   * Binary compatibility
>>   * Implementation consistency
>>
>> You probably can provide, for example, some allocators, relax 
>> compatibility requirements and so on...  The question only is whether 
>> this is worth doing or not.
>
> I'm not totally sure I understand this point. What do you mean by 
> "memory management"? (Binary compatibility of stdlib is not an issue, 
> and implementation consistency for containers shouldn't really be 
> either).
>
>>
>> Personally I tend thinking that this is better to maintain, extend 
>> and improve what we already have rather than address the issues 
>> listed above. Again, this is just a personal opinion.
>>
>
> It's just a problem of "who does the work", and we've got a terrible 
> track record at that.  But I grant that implementing containers is 
> fun, and I'm not doing the work, so I shut up :)
>
> Thanks,

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] QHash for Qt 6

[Vitaly Fanaskov]

This is not that easy to use std::* containers because at least the following 
issues have to be addressed:

  *   Memory management
  *   Binary compatibility
  *   Implementation consistency

You probably can provide, for example, some allocators, relax compatibility 
requirements and so on...  The question only is whether this is worth doing or 
not.

Personally I tend thinking that this is better to maintain, extend and improve 
what we already have rather than address the issues listed above. Again, this 
is just a personal opinion.

We should probably perform some research here.

On 12/20/19 11:47 AM, Giuseppe D'Angelo via Development wrote:
Il 20/12/19 09:23, Lars Knoll ha scritto:
The result was that QHash has clear weaknesses compared to other 
implementations. It uses too much memory and certainly isn’t the fastest 
implementation. But std::unordered_map is just as bad, so there’s no point in 
using that to implement QHash.

Just to be devil's advocate, there is... As much as it's fun and everything 
implementing a container, just using std::unordered_map would have minimal 
effort on our side ("someone else's problem", and it's not even a random 3rd 
party, but a mandatory prerequisite for building Qt), and we can put in our API 
move-conversion between QHash / std::unordered_map.

I stopped thinking that Qt should provide "special" data structures (and for 
sure we should kill any QHash/QMap usage in our APIs); QHash can be as bad (or 
as good) as std::unordered_map, and if people need something more tailored for 
their use cases, there's plenty of 3rd parties to choose from. Or is there a 
political agenda here trying to promove QHash usage? :-)

Is the plan to also have QMap be backed by an hybrid solution (array-backed, 
etc.), or std::map, or something else?

My 2 c,




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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The age-old T* foo vs. T *foo

[Vitaly Fanaskov]

Hi,


I think that this discussion is pointless. Style is mostly the matter of 
preferences, but:

1) We have a huge code base with the certain code style.

2) We have official guidelines.

3) We have a tool for auto code formatting.


I don't see any good reasons to change the entire code base or make it 
inconsistent, and adjust docs and tools. If a person is not used to the 
Qt style, he or she might use clang formatting tool for this.

On 10/17/19 8:04 PM, Ville Voutilainen wrote:
> Since we are about to do a major version upgrade, should be stop being
> a special snowflake in the C++ world and start attaching pointer-stars
> and reference-ampersands to the type instead of to the variable?
>
> As a quick example of how our current style is just odd, consider
>
> for (auto & : oink)
>
> Sure, that's in accordance with our style. It looks very out of place when
> coming back to our code after adventures in other code. Quick reading
> of it tends to suggest that it's a by-value thing since quick eyes see
> auto without any decorations.
>
> I don't expect the transition, should we agree to have it, to be easy
> for people accustomed to the Qt style. I also don't have any sort of numbers
> about whether our style is used elsewhere. In contrast, people with lots
> of exposure to non-Qt style tend to have to fight ours, it just doesn't come
> naturally.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] Qt 6: inline namespace Qt

[Vitaly Fanaskov]

Hi Marc,

Could you elaborate a bit, what the real value of this change?

I'm asking, because there are only cons I see now:

1) Adding inline after namespace *implicitly* throws all symbols to the 
global (or outer) namespace, which, potentially might lead to name 
clashes. For example, the following code won't be compiled:

inline namespace foo { void bar() {} };

void bar() {}

// ...

bar();

2) Negative user experience especially when moving to a fresh Qt 
version: some names are implicitly appears.

3) Potentially force users to compile Qt in a namespace. This is not 
required in a lot of cases, really. One of the cases might be when your 
app is a plugin and a host app also uses Qt of the same version. But 
it's rarely.

On 9/6/19 11:26 AM, Mutz, Marc via Development wrote:
> Hi,
>
> I would like to propose to make the existing Qt namespace inline and 
> move all of Qt's declarations into it.
>
> == TL;DR: ==
>
> Qt can already, optionally, be configured into a user-specified 
> namespace (QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -qtnamespace), and 
> this is one of the build configurations in the CI, so we're reasonably 
> sure it works. The change would be very limited (via existing macros). 
> Only pre-existing declarations of "namespace Qt" would have to be 
> touched. The change is SC, and makes namespaced and non-namespaced 
> builds behave the same.
>
>
> == Rationale ==
>
> As we see with the introduction of Qt::endl, a SiC change, we have a 
> problem in that we have existing Qt API that traditionally (dare I say 
> "for decades") doesn't have a Q/q prefix. Adding Qt:: in front now is 
> a massive SiC change. Making the Qt namespace inline allows users to 
> continue to write << endl; while we still have the symbol moved out of 
> the global namespace.
>
> Furthermore, the global namespace is special in that ADR does "not 
> work in it"[1]; [1] can be summarized as "C++ just works better when 
> all types are in some namespace". This means that we have very subtle 
> differences in name lookup, depending on whether Qt is compiled with 
> -qtnamespace or without. I remember having hit these multiple times in 
> the past, but can't remember details anymore (and one or the other 
> might have had to do more with two-phase name lookup in templates, and 
> not with ADR).
>
> [1] 
> https://groups.google.com/forum/#!msg/comp.lang.c++.moderated/1Qz71aFnXlI/Gd71gwRaWssJ
>
> The language has also started stipulating in a few places that certain 
> functions are only found via ADR, not by ordinary name lookup (the 
> begin() and end() functions called by ranged-based loop for non-array 
> types that don't have a .begin()/.end() come to mind). There seems to 
> be some confusion[2] over whether that means that functions in the 
> global namespace would be found at all under such circumstances (I 
> guess Ville could confirm or deny), and vice versa: when functions are 
> defined as friends in the body of types (in which case they're only 
> found via ADL and not via ordinary name lookup) in the global 
> namespace, do they exist at all? But we can do very well without such 
> dipping into C++'s dark corners: if we are always in a namespace, ADL 
> always works.
>
> [2] 
> https://stackoverflow.com/questions/25133383/does-adl-work-for-the-global-namespace
>
> Thus, I'd like to propose to move all of Qt into an inline namespace 
> Qt. Any user namespace would be wrapping it:
>
>   inline namespace Qt {
>   class QString;
>   }
>
> without `-qtnamespace` and
>
>   namespace TestNamespace {
>   inline namespace Qt {
>   class QString;
>   }
>   }
>
> with `-qtnamespace TestNamespace`.
>
> Because the namespace is inline, existing code will just have to be 
> recompiled to pick it up. In particular, no `using namespace Qt` is 
> needed anywhere to still use QString etc unqualified, yet, the 
> executable would refer to Qt::QString everywhere. Even 
> Q_DECLARE_TYPEINFO would continue to work unchanged, since you don't 
> need to open an inline namespace to specialise templates from it.
>
> It's a BiC change, though, so it's for Qt 6.0, if ever.
>
>
> == Design Decisions ==
>
> === inline Qt::Qt3D or inline Qt3D ? ===
>
> Some Qt modules have started using a (non-inline) namespace, often 
> derived from the module or library name, since Qt 4 (QtPatternist, 
> QtConcurrent, Qt3D, ...). A legitimate design would leave the Qt 
> namespace alone, and put each library Lib into an inline namespace 
> QtLib instead. This would solve the same problems, and could be used 
> to unify the different libraries' choices of handling naming. The 
> reason that it's not proposed here is that it's a much grander scheme 
> than just wrapping everything into `inline namespace Qt` - all the Qt 
> modules are already known to work with the user namespace feature and 
> this proposal simply suggests to append `inline namespace Qt {` to 
> QT_BEGIN_NAMESPACE so that this macro always expands to at least one 
> namespace 

[Development] Regarding using C++20 ranges in Qt

[Vitaly Fanaskov]

Hello everyone!


I think, we can use range-based approach to improve a lot of things in 
Qt classes interfaces. I've performed some experiments and implemented 
an access to children of QObject with this approach: 
https://git.qt.io/vifanask/qobject-with-ranges . All details, pros and 
cons are in the readme file.

As mentioned above, this is only a proof of concept. So there are a 
plenty of ways how to improve implementation. Please, look at the 
examples in the test folder and share your opinion about the approach 
itself, its perspective, and any suggestions you like.

The same approach might be applied for some other classes. For example, 
to QString for splitting and operations like that. It looks nicer to 
provide some simple functors that might be composed to a pipeline rather 
than have everything in a class interface.


I hope you follow modern C++ and know a bit of ranges. If not, feel free 
to explore it:

Documentation: https://en.cppreference.com/w/cpp/ranges

Experimental implementation: https://github.com/ericniebler/range-v3

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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

Re: [Development] Views

[Vitaly Fanaskov]

Well, my point was: there always should be a trade off. I've never wrote 
that Qt should be slow. I just wanted to point out that understanding of 
performance might be different for different sort of libraries (and for 
different cases).

I hope, you filed a ticket or fixed this problem yourself. This looks 
like a corner case.

On 6/6/19 11:09 AM, Иван Комиссаров wrote:
> I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should 
> perform well.
> Take a look at Qt Item Views. They really sucks in terms of performance.
> QAbstractItemModel can have any number of rows/columns (that fits in 
> MAX_INT), but which view can really handle that? None of them!
> I had to use a model with 3kk rows in it. Guess what I used to display it? 
> Custom item view.
> AFAIK Qt item views still use vectors internally and simply changing the 
> internal container to an std::deque can (needs profiling, though) improve 
> performance since it stores data in chunks. Imagine prepending a row to a 
> table with 3kk rows... well, good luck reallocating a vector in QHeaderView.
>
> Иван Комиссаров
>
> 6 июня 2019 г., в 10:17, Vitaly Fanaskov  написал(а):
>
>>> As a library implementer, you are simply not _allowed_ the freedom to
>>> use a convenient tool over the most efficient one. That is, to put it
>>> mildly, a disservice to users and a disgrace to the profession of
>>> programmers.
>> Well, optimization is probably good, but not always, I would say. If
>> your app takes 0.001% less memory and works 0.001% faster then before in
>> some certain configurations... Well, it's probably worthless, unless
>> you've improved google search engine or something like that.
>>
>> Qt is GUI framework. Not only, yes, but this is the main purpose. +/-
>> 10MB is almost nothing for GUI apps. Slightly faster lookup/insertions,
>> cache line, proper alignment... Well, nice to have, but when an app
>> spends most of the time on rendering something, it doesn't matter.
>> Highly unlikely will it be a bottle neck.
>>
>> The thing is, that we should keep in mind what kind of library Qt is.
>> And also on what devices it runs.
>>
>> I would rather have readable code than tiny bit optimized code, but much
>> less readable. Simple and readable code => easy to maintain => easy to
>> extend => easy to add new features. If you app is something for
>> high-frequency trading or should run on devices with super limited
>> resources, just don't use Qt containers. It's not appropriate tool for
>> these cases.
>>
>> I don't want to encourage people to write, for example, O(n^2) code
>> instead of O(n). But if you want to "improve" something which is working
>> more or less acceptable... Probably you should put your effort on
>> something else.
>>
>>> On 6/6/19 9:05 AM, Mutz, Marc via Development wrote:
>>>> On 2019-06-06 08:24, Joerg Bornemann wrote:
>>>>> On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
>>>>>
>>>>> As a library implementer, you are simply not _allowed_ the freedom to
>>>>> use a convenient tool over the most efficient one. That is, to put it
>>>>> mildly, a disservice to users and a disgrace to the profession of
>>>>> programmers. 8KiB just to look up a pointer in a map of {string, int}?
>>>>> That's 1/4th of the icache size of many processors!
>>>> [...]
>>>>
>>>> While I agree with this in general... every time we use a sorted vector
>>>> as a dictionary replacement we're scattering implementation details all
>>>> over the place, creating code that's much harder to read and easier to
>>>> make mistakes in (*).
>>>>
>>>> Maybe it's time for a general purpose dictionary class based on a sorted
>>>> vector?
>>> FTR: More of the same:
>>> https://codereview.qt-project.org/c/qt/qtbase/+/264128 and
>>> https://codereview.qt-project.org/c/qt/qtbase/+/264129
>>>
>>> I very strongly object to the notion that a find_if or lower_bound is
>>> harder to read. More code does _not_ equate to less readable, as Qt
>>> over and over has shown. There are different patterns involved than in
>>> using Qt containers, sure, and by all means, if find_if frightens you,
>>> then use a raw for loop, but this stuff is not rocket science. And
>>> depending on how you define 'mistakes', it's just as easy to make a
>>> mistake by forgetting qAsConst() on a Qt container than it is to, say,
>>> combine iterators from different containers.
>>>
>

Re: [Development] Views

[Vitaly Fanaskov]

> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers.
Well, optimization is probably good, but not always, I would say. If 
your app takes 0.001% less memory and works 0.001% faster then before in 
some certain configurations... Well, it's probably worthless, unless 
you've improved google search engine or something like that.

Qt is GUI framework. Not only, yes, but this is the main purpose. +/- 
10MB is almost nothing for GUI apps. Slightly faster lookup/insertions, 
cache line, proper alignment... Well, nice to have, but when an app 
spends most of the time on rendering something, it doesn't matter. 
Highly unlikely will it be a bottle neck.

The thing is, that we should keep in mind what kind of library Qt is. 
And also on what devices it runs.

I would rather have readable code than tiny bit optimized code, but much 
less readable. Simple and readable code => easy to maintain => easy to 
extend => easy to add new features. If you app is something for 
high-frequency trading or should run on devices with super limited 
resources, just don't use Qt containers. It's not appropriate tool for 
these cases.

I don't want to encourage people to write, for example, O(n^2) code 
instead of O(n). But if you want to "improve" something which is working 
more or less acceptable... Probably you should put your effort on 
something else.

On 6/6/19 9:05 AM, Mutz, Marc via Development wrote:
> On 2019-06-06 08:24, Joerg Bornemann wrote:
>> On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
>>
>>> As a library implementer, you are simply not _allowed_ the freedom to
>>> use a convenient tool over the most efficient one. That is, to put it
>>> mildly, a disservice to users and a disgrace to the profession of
>>> programmers. 8KiB just to look up a pointer in a map of {string, int}?
>>> That's 1/4th of the icache size of many processors!
>> [...]
>>
>> While I agree with this in general... every time we use a sorted vector
>> as a dictionary replacement we're scattering implementation details all
>> over the place, creating code that's much harder to read and easier to
>> make mistakes in (*).
>>
>> Maybe it's time for a general purpose dictionary class based on a sorted
>> vector?
>
> FTR: More of the same: 
> https://codereview.qt-project.org/c/qt/qtbase/+/264128 and 
> https://codereview.qt-project.org/c/qt/qtbase/+/264129
>
> I very strongly object to the notion that a find_if or lower_bound is 
> harder to read. More code does _not_ equate to less readable, as Qt 
> over and over has shown. There are different patterns involved than in 
> using Qt containers, sure, and by all means, if find_if frightens you, 
> then use a raw for loop, but this stuff is not rocket science. And 
> depending on how you define 'mistakes', it's just as easy to make a 
> mistake by forgetting qAsConst() on a Qt container than it is to, say, 
> combine iterators from different containers.
>
> As for QSortedVector/QFlatMap. There's a reason there's none in the 
> std, yet, and it has to do with when to sort. In one of the patches 
> above, we don't need to sort at all, because there're only ever O(10) 
> elements in there. Sorting, as performed by a QFlatMap would be 
> overkill there. In another, we don't even store the key, as it's equal 
> to the position of the element in the array. Sorting the key would be 
> nonsense. Oftem, you populate the data structure once and then only 
> perform lookups. In that case, a QFlatMap would waste time sorting 
> while you don't need it. So, yes, by all means, let's have a QFlatMap, 
> but it would just be another over-complicated container that people 
> misuse. Let's, as a community, learn how to use a raw vector (or 
> array) first, then introduce convenience.
>
> Don't pick a container by it's API. Pick it by how you use it. No-one 
> would use a RB tree for O(10) items if he had to implement it himself. 
> You wouldn't even implement one for O(1M) elements if insertions in 
> the middle are very infrequent. You are CS engineers. What would Knuth 
> say if he caught you using a RB tree with a static maximum of 10 
> entries? There's a reason for this. It's horribly slow, and only used 
> because in very limited circumstances, evenry other container is 
> _even_ slower. It's a very, very, complex beast. Just because the 
> compiler writes it for you at nothing more than a mention of 
> QMap, doesn't mean it's less complex. And that complexity doesn't 
> go away just because you wrap it in a nice API: the compiler has a 
> hard time with it, and so does the CPU, as evidenced by the O(KiB) 
> savings involved in each replacement of a QMap with a vector. Let's 
> also not forget the memory overhead: a QMap uses at least 24 
> bytes of of storage per element. Plus allocation overhead. Some 
> platforms (Windows? At some point 

Re: [Development] Deprecation/removal model going into Qt 6

[Vitaly Fanaskov]

> APIs in libraries are meant to be used. I consider it an entirely reasonable
> expectation by developers using the APIs that they will not be removed under
> them because the library developers consider them "obsolete". Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years. This is the standard
> software libraries should be held to, too.
This is common practice to mark API deprecated in one major release and 
remove them in the next one. It helps not clutter an interface and keep 
it fresh and updated. Yes, it might break some code, but people will be 
receiving compiler warnings that some functionality has been marked as 
not recommended for using, and will have a plenty of time to replace it 
with recommended solution.

Regarding CPU, this is another level. I don't think that this comparison 
is suitable.

I don't want Qt to be in C++ situation: some usable subset and a pile 
of... old things, left for backward compatibility. Fine, it's already 
in, but there are no reasons to make it worse. As the framework 
maintainers we have to be more reasonable, I would say.

> Qt has long reached a point where it can be considered complete. Its main
> selling point is portability to many different platforms rather than some
> specific feature. Additional features don't necessarily need to be in the
> main Qt library, but can be in community-developed addons such as KDE
> Frameworks or such as the many third-party Qt-based Free Software libraries
> out there. (They can also be in Qt-Company-developed Qt Solutions if there
> is manpower left for that.)
>
> Qt has also become larger and larger over time (despite the removal of APIs
> considered obsolete). Just compare the size of the Qt 3 tarball with the
> size of the Qt 5 monolithic tarball. This is not the result of keeping old
> APIs around, but of feature creep.
>
> So I disagree with the assertion that Qt needs more features to remain
> competitive.
Qt is modular and is going to be more modular. Are there any problems 
with not using/building/supplying some modules?

Introducing (and maintaining after) new features is cool. Old and unused 
should be eliminated without mercy :)

On 6/3/19 1:34 PM, Kevin Kofler wrote:
> Giuseppe D'Angelo via Development wrote:
>
>> Il 03/06/19 00:08, Kevin Kofler ha scritto:
>>> What you call "obsolete functionality" is functionality that existing
>>> code relies on and rightfully expects to remain there.
>> Rightfully? By what right exactly?
> APIs in libraries are meant to be used. I consider it an entirely reasonable
> expectation by developers using the APIs that they will not be removed under
> them because the library developers consider them "obsolete". Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years. This is the standard
> software libraries should be held to, too.
>
>>> I'd rather get fewer (or even no) new features than losing existing ones.
>> How is this even an argument? Qt will need to evolve and acquire
>> features to remain competitive. Again, development bandwidth is finite:
>> either the overall quality decreases or some things have to get dropped.
> Qt has long reached a point where it can be considered complete. Its main
> selling point is portability to many different platforms rather than some
> specific feature. Additional features don't necessarily need to be in the
> main Qt library, but can be in community-developed addons such as KDE
> Frameworks or such as the many third-party Qt-based Free Software libraries
> out there. (They can also be in Qt-Company-developed Qt Solutions if there
> is manpower left for that.)
>
> Qt has also become larger and larger over time (despite the removal of APIs
> considered obsolete). Just compare the size of the Qt 3 tarball with the
> size of the Qt 5 monolithic tarball. This is not the result of keeping old
> APIs around, but of feature creep.
>
> So I disagree with the assertion that Qt needs more features to remain
> competitive.
>
>>> See also Boudewijn Rempt's blog post on the subject:
>>> https://valdyas.org/fading/hacking/happy-porting/
>> I agree with the principle (API breaks are painful), but I strongly
>> disagree with the idea that no API breaks can ever possibly happen. And
>> the specific example is a terrible one to make a point as the resulting
>> API break is trivial to work around (I defined such breakages
>> "scriptable").
> The Q_FOREACH to ranged for change is not as easy to port to as people
> think, because there are at least 2 pitfalls when porting to ranged for:
> 1. you have to add qAsConst or equivalent or you will be deep-copying your
> implicitly-shared CoW container,
> 2. code that was changing the container during the iteration, 

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Vitaly Fanaskov]

All these have the same issue: You are proposing to deprecate Qt types in
favor of STL types, which have a different naming convention (_ vs. camel
case) and often terse, harder to understand names (e.g., ptr vs. Pointer,
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support
CoW (all the container types in your list), nor Java-style iterators, for
that matter.

I think Qt should keep striving for completeness and not require its users
to mix Qt and STL usage with all the STL's ugliness.

This is also very good point. STL is definitely ugly, Qt provides much prettier 
API.
We actually can use std::* in implementation, but should provide Qtish 
interface. It also would be nice, because:
1) Avoid using std::* in interfaces
2) Keep API convention users get used to
3) Keep all Qt guarantees about compatibility
4) Give developers freedom in improvements API

After all, STL updates approximately once in three years. So, we can easily 
follow all changes and update Qt API accordingly. It’s probably worth reusing 
something (e.g. time suffixes from chrono), but carefully.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 19:42, Kevin Kofler 
mailto:kevin.kof...@chello.at>> wrote:

Mutz, Marc via Development wrote:
== QSharedDataPointer / QExplicitlySharedDataPointer ==

These are basically Qt-internals, and should never have been public in
the first place.

Why? They are essential to be able to implement one's own CoW types and thus
write idiomatic Qt code.

I use QSharedDataPointer a lot, and my code will likely be stuck on Qt 5 or
6 forever if they get removed resp. deprecated in Qt 6.

== Q_FOREACH -> ranged for loops
(https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==

As I already wrote when Q_FOREACH was deprecated to begin with, the problem
is that this replacement is dangerous because ranged for does not copy (so
legacy code that accidentally changed the container, which was harmless with
Q_FOREACH, will crash and burn with ranged for) and can be inefficient with
CoW types if done carelessly because ranged for does not automatically
constify the container (whereas Q_FOREACH made a const copy).

=== related: Q_FOREVER -> for(;;) ===

This just reduces readability for no maintainability gain whatsoever.

== Java-style iteration
(https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==

The Java-style iterators are much more convenient to use than the STL-style
ones, and quadratic loops can be accidentally written with both.

== QScopedPointer -> std::unique_ptr ==
== QLinkedList -> std::list
== qHash() -> std::hash ==
== MT plumbing ==
=== QAtomic -> std::atomic ===
=== QMutex / QReadWriteLock -> std::*mutex* ===
=== QMutexLocker -> std::unique_lock ===
=== QWaitCondition -> std::condition_variable(_any) ===
== QQueue / QStack -> std::queue, std::stack ==
== QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
== QSet / QHash -> std::unordered_set/map ==
== QMap -> std::map ==

All these have the same issue: You are proposing to deprecate Qt types in
favor of STL types, which have a different naming convention (_ vs. camel
case) and often terse, harder to understand names (e.g., ptr vs. Pointer,
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support
CoW (all the container types in your list), nor Java-style iterators, for
that matter.

I think Qt should keep striving for completeness and not require its users
to mix Qt and STL usage with all the STL's ugliness.

   Kevin Kofler
   (who thinks C++ is a great language except for its standard library)

___
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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Vitaly Fanaskov]

Well, but what about MSVC, for example, or some other compilers/|platforms? 
This is rhetorical question, of course. I just want to say, that we cannot 
guarantee this sort of compatibility for all build configurations. Hence, this 
is unreliable unless we have a sort of public contract like “we guarantee this, 
this, and that under some circumstances”.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 17:30, Olivier Goffart 
mailto:oliv...@woboq.com>> wrote:

On 29.05.19 17:17, Mutz, Marc via Development wrote:
But of course, that's a fallacy, because as soon as Qt internally uses said 
inline functions, every use of them by the user with a different STL is an ODR 
violation and therefore UB. So, again AFAICT, the decision was that we can use 
std types in the API now, even when not inline.
Someone correct me if I'm wrong.

I believe you are right. But binary compatibility, as a whole, is a ODR 
violation, and therefore is UB. (Unless we really do not touch any of the 
existing class in a public header files, not even to add a typedef or a method 
in them)

In practice, however, it works. Same as changing the stdlib, because they also 
keeps binary compatibility across version and libc++ and libstdcpp are in 
different namespace.

--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Vitaly Fanaskov]

Do you know is there is any official policy published? I’ve tried to look into 
both internet and intranet, but found pretty much nothing.

I entirely agree with increase of using new language features and STL, but it 
should be done wisely and under well-defined policy. If we don’t have one, we 
need to develop it. Without an official document users cannot rely on Qt. We 
also might easily violate ABI-compatibility policy and so on.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 17:17, Mutz, Marc via Development 
mailto:development@qt-project.org>> wrote:

On 2019-05-29 16:06, Vitaly Fanaskov wrote:
=== QAtomic -> std::atomic ===
It already is just a thin wrapper around std::atomic, so there's not
much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If so, how all related
mess is supposed to be handled? I know that we already use some of them,
for example, in QTimer and QString, but these cases are minor.
This decision should be very well justified and clearly defined
somewhere before making suggestions like above.

AFAIK, this was decided long ago (at least two years). The problem used to be 
that Qt, by coincidence, didn't care which std library the user application 
linked to, because all its STL use was either internal or in inline functions. 
This used to have some merit on OSX, and could have had some merit on Linux had 
distributions compiled libc++ against GCC's language library to make it 
compatible with libstdc++, which, however most didn't.

But of course, that's a fallacy, because as soon as Qt internally uses said 
inline functions, every use of them by the user with a different STL is an ODR 
violation and therefore UB. So, again AFAICT, the decision was that we can use 
std types in the API now, even when not inline.

Someone correct me if I'm wrong.

What changed since then is that we can now assume many more of the C++11 types 
to be available unconditionally.

Thanks,
Marc
___
Development mailing list
Development@qt-project.org<mailto: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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Vitaly Fanaskov]

> === QAtomic -> std::atomic ===
>
> It already is just a thin wrapper around std::atomic, so there's not 
> much point keeping it. 

There is the interesting question in light of this: are we really going 
to widely use std::* in public interfaces of Qt? If so, how all related 
mess is supposed to be handled? I know that we already use some of them, 
for example, in QTimer and QString, but these cases are minor.

This decision should be very well justified and clearly defined 
somewhere before making suggestions like above.

On 5/29/19 12:53 PM, Mutz, Marc via Development wrote:
> Hi,
>
> Here's a list of stuff I consider has served it's purpose and is no 
> longer needed, with respective replacements:
>
> = Priority 1 =
>
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in 
> the first place. It's _because_ they are public that we have two of 
> them, and soon a third one (properly non-public): 
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's 
> message also explains what's wrong with the QSDP and QESDP.
>
>
> == Q_FOREACH -> ranged for loops 
> (https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==
>
> Q_FOREACH is less readable (because it allows mutating the container 
> under iteration), and produces _a lot_ of code. It also is 
> intrinsically tied to just a few Qt containers (excluding QVLA). 
> Ranged for loops work on anything, incl. a C array. Also, as a macro, 
> it will continue to cause problems down the road (e.g. with modules). 
> Being a macro also means that it cannot deal with value_types that 
> contain a comma.
>
> === related: Q_FOREVER -> for(;;) ===
>
> Suggested by Lars in ibid. Basically because it's a macro.
>
>
> == Java-style iteration 
> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
>
> It's very easy to write quadratic loops with it.remove(), and a review 
> of Qt code has shown that some users still use container.remove(), 
> which is just as unsafe as with STL iterators. I also noted between 
> 100b/loop and 5KiB for four loops of text size savings.
>
>
> == QScopedPointer -> std::unique_ptr ==
>
> Suggested by Thiago on 
> https://codereview.qt-project.org/c/qt/qtbase/+/261553
>
> I agree. We now have std::unique_ptr, and it's movable. QScopedPointer 
> had the problem that it didn't know what it wanted to be: 
> boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not 
> offer release(), a unique_ptr would need to provide move semantics. 
> QScopedPointer has release(), but no moves (were proposed, but not 
> accepted).
>
>
> == QLinkedList -> std::list 
> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) ==
>
> Of the Qt containers, this one is the most-unused (in Qt code), as 
> well as the one that's furthest behind it's STL counter-part. Whenever 
> I use std::list, I use it for splice(), a function that just cannot be 
> added to a CoW container. Qt is already almost completely 
> QLinkedList-free. Let's bury QLinkedList.
>
>
> == qHash() -> std::hash ==
>
> Suggested by Lars in 
> https://codereview.qt-project.org/c/qt/qtbase/+/261819. To be precise, 
> he's suggesting to specialise std::hash and have qHash() call std::hash.
>
> Only problem I see so far is that std doesn't provide us with a tool 
> to hash composites. E.g. there's no std::hash for std::tuple (which 
> would mean we can std::tie the members and hash the result), and only 
> C++17 adds some kind of raw bits hashing (via std::string_view). We'd 
> need to provide these building blocks ourselves, which can be done, 
> but it means we'll have at least _some_ qHash()-like functions we need 
> for std::hash<> implementations.
>
> Actual problem?
>
>
> == QPaintDevice ==
>
> I'd like this to become a static interface. In very shortened terms: 
> everything that has a QPaintEngine *paintEngine() method is a paint 
> device. QPainter's ctor would become a template and do the virtual 
> dispatch internally, just like Sean Parent's document type in C++ 
> Seasoning.
>
> This would solve a lot of problems: QWidget would no longer need to 
> use multiple inheritance, and QImage and QPixmap would become proper 
> value types, without virtual functions that create problems with move 
> semantics and swapping.
>
>
> == QRegExp ==
>
> Is QRegularExpression good enough these days? :)
>
>
> == MT plumbing ==
>
> Let's make use of the std facilities to enable checkers such as TSAN 
> to work without hacks. It's not Qt's business to reimplement threading 
> primitives.
>
> Probably need to keep some stuff around, like QThread, because of the 
> interaction with event processing, but before we add a lot of time 
> making the following classes play nice with the std, let's 
> perspectively remove them:
>
> === QAtomic -> std::atomic ===
>
> It already is just a thin wrapper around std::atomic, so there's not 
> much point keeping it.
>
> === QMutex / QReadWriteLock -> std::*mutex* 

Re: [Development] QList for Qt 6

[Vitaly Fanaskov]

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.

This is good direction. But I would suggest something based on ranges (accepted 
for C++ 20 and there is already ranges-v3 on github or ranges in boost). What 
we should return in our API is lazy range object. This is actually a sort of 
view or chain of nested views with some conditions. If a user needs a regular 
container, range might be simply assigned to it.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 16 May 2019, at 15:05, Mutz, Marc via Development 
mailto:development@qt-project.org>> 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.

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.

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.

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.

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.

Thanks for considering,
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] Requesting a module for Qt Quick Timeline Implementation

[Vitaly Fanaskov]

Hi,


Sounds good. This module might be useful for some companies that develop VFX 
software.


On 5/9/19 10:21 AM, Thomas Hartmann wrote:
Hi,

I would like to request for a new module:

Name of the repository: qt/qtquicktimeline.git
Description: Module for keyframe-based timeline construction.
Responsible person: Thomas Hartmann
Gerrit user/email: thomas.hartm...@qt.io

The module is already on gerrit and is in a mature state by now.
The timeline module is used by Qt Design Studio and Qt Quick Designer
but there are use cases independent from tooling.

One use case is defining 'animations' not in time, but depending on an 
expression.
This way it is very easy to create complex progress bars or gauges.

Best Regards,
Thomas Hartmann




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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Vitaly Fanaskov]

Well, it should be possible, to support parents, created on the stack. We 
already have the code to do it. The code is private, unfortunately, but it 
doesn't matter. In the following file:

qtbase/src/corelib/tools/qsharedpointer_impl.h

We have the following constructor, used by QPointer:

template  inline QWeakPointer(X *ptr, bool) : d(ptr ? 
Data::getAndRef(ptr) : nullptr), value(ptr) { }

That's it. We can use it for both case. There are some changes in QObject 
interface:

QObject(QWeakPointer parent = {})

// Use casting operator instead?

QWeakPointer asWeakRef() { return {this, true}; } QWeakPointer asWeakRef() const { return {this, true}; } QWeakPointer 
parent;

And some usage examples:

 auto o1 = QSharedPointer(new QObject);

auto o2 = new QObject(o1);

// Or...



QObject o1;

QObject o2(o1.asWeakRef());

I compiled and tested after patching Qt, works fine. Of course, I didn't 
implement full functionality, just a shallow example. QWeakPointer also 
gracefully handles the case if a user tries to invoke something like 
toStrongRef() in the second example. Some reasonable warning will be put to the 
terminal and an empty QSharedPointer returned.

This also means that we will have to use our own smart pointers everywhere in 
the interface (for consistency). We will also have to change some things (e.g., 
make QScopePointer movable), but this is the matter of another discussion. 
Which is not bad, because it'll help to avoid some well-known problems of using 
std::* in library interfaces, along with memory allocation/cleaning issues. And 
again, this is much better than having raw pointers.

On 5/6/19 12:04 PM, Lars Knoll wrote:

On 6 May 2019, at 10:27, Konstantin Shegunov 
mailto:kshegu...@gmail.com>> wrote:

On Mon, May 6, 2019 at 10:42 AM Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:
Not sure whether it’s most projects, but there certainly are users doing it. 
And we’ve been using the pattern in our examples in some cases as well. But I 
can relate to Allan that creating widgets on the stack is bad style (as it 
conflicts with the way we memory manage them), and if I’d have a choice today, 
I would probably prefer to enforce them to be created on the heap by some means.

Fine, there seems to be somewhat of an argument in that regard. I'd raise the 
question then, what should be done for QObject derived classes, and I don't 
mean the ones that come from Qt (i.e. QFile, which Thiago mentioned), but the 
ones the user defines. In the end QObject is for us to derive from - get 
signals and slots and all those goodies. But then if one restricts QObject to 
be on the heap how do we treat the user classes? What I mean is - you can 
control how allocations happen in the library, say you provide custom 
new/delete for QObject and/or QWidget and restrict the stack (presumably 
through some trickery that disables the constructor), does this mean we are to 
force the user to write their own allocation operators for their classes? This 
doesn't really sound practical to say the least. Moreover there's really little 
reason (from the user's point of view) to have something in the heap if it can 
go on the stack. What do we do with QCoreApplicaiton, force the heap on it?

It’s somewhat of a philosophical discussion now, as we are where we are and 
users can and are creating QObject’s on the stack. I don’t think we can change 
that now (even for Qt 6), and restricting it would lead to rather ugly syntax 
in C++ (as the language doesn’t really help enforcing something like this). So 
that means we’ll have to continue to support it.

Cheers,
Lars




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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake Workshop Summary

[Vitaly Fanaskov]

Hi Simon,


Thank you for the update.


It's not clear why you included version to a package name (e.g. Qt5/Qt6). With 
CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)

Perhaps it would be better, what do you think?


On 2/13/19 10:33 AM, Simon Hausmann wrote:
Hi,

On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the 
attempt of building Qt with CMake. I'd like to give a brief summary of this 
workshop.

Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert.

A very early visible artifact was the creation of a wiki page (like all good 
workshops ;-)

https://wiki.qt.io/CMake_Port

With such a large group, we were able to make good progress:

* We were able to fix the artifacts of "make install" in qtbase to allow 
for building an external module (qtsvg) and sample apps. The plan for allowing 
people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:

(1) In your application use either find_package(Qt5) or 
find_package(Qt6)
(2) Always use Qt::Core, Qt::Gui, etc. for linkage
(3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to Qt5's 
cmake support

* The script to converting .pro files to CMakeLists.txt is becoming really 
good. The goal is to convert all scopes and (source) file names correctly. 
Right now the repo contains incremental conversions with hand-edits.

* We're working on installing the latest cmake (as required) in the 
provisioning setup, so that we can get a building CI as soon as possible.

* We were able to verify that cross-compilation works well. The main 
challenge is ensuring that third-party libraries that used to be copied in 
src/3rdparty are either installed in the sysroot or can be found outside.

* We discussed and experimented with different ways of making static builds 
robust. So static builds themselves work already, but what we're looking into 
in particular is an automatic way of propagating Qt internal dependencies (such 
as double-conversion) correctly to the build process of the application that is 
not fragile.

* We added a lot more plugins and platform support libraries to the build 
process and did many improvements to the finding of external libraries.


Our overall next goal is completing the build on Linux, macOS and Windows, 
cross-compilation, static builds and basic CI build support.


Simon



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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Vitaly Fanaskov]

Hi Volker,
The question for me is: why would an application (that is not a file explorer) 
want to do any of this? I honestly don’t see the use case.
I think in order to provide a user some useful information or suggest to 
perform some actions. For example, "moveToTrash" operation might fail for some 
reason. If you don't have a separate class for trash bin you can only report 
this error to a user, but neither fix a cause nor do something useful. For 
example, what if there is not enough space in the trash bin, or what if the 
trash bin configured to remove files without keeping them and so on... Wouldn't 
this sort of API useful for a developer who wants to use move-to-trash 
operation?

On 2/11/19 1:22 PM, Volker Hilsheimer wrote:
Hey Vitaly,

See inline.

On 11 Feb 2019, at 11:42, Vitaly Fanaskov 
mailto:vitaly.fanas...@qt.io>> wrote:
Making QFile::remove(bool toTrash=false); is tempting, but I think Thiago has a 
valid point about providing a dedicated file system operation abstraction, 
rather than cramming a mix of simple and complex file operations into QFile and 
QDir.
I agree that creating separate abstraction for file operations is an acceptable 
option. Although, I don't think that there is should be any difference between 
"simple"/"complex" or "long"/"short" or "atomic"/"non-atomic" operation in 
terms of user. As an API user I want to just perform some actions and don't 
care what is the under the hood; I also want all available operations to be 
presented in one place based on global classification feature (e.g., "file 
operation"). Of course, some things like "this is potentially long 
operation..." should be mentioned in the documentation.


Indeed, I don’t want application developers to have to use fundamentally 
different approaches based on the under-the-hood complexity of the operation. 
Either do it synchronously, and accept that the calling thread will be blocked; 
or do it asynchronously, and provide whatever plumbing you might need to have 
control over the process.

I see how my statement above can be misleading; what I wanted to say is that 
adding an “asynchronous file operations” design to QFile and QDir is cluttery, 
and instead of adding it there, I’d rather move *all* file system ops into a 
new class.


I also think that we should have a look into some options for file operations 
from C++ 17: https://en.cppreference.com/w/cpp/filesystem/copy_options . 
Something similar is worth adding to the new API.

Yes, absolutely.


A dedicated operations interface that can work with both QFile and QDir (but 
essentially only cares about file paths) would be nice; that doens’t mean we 
can’t keep a QFIle API for the simple stuff, ideally one that doesn’t 
accidentially block your UI event loop because the user selected a 5 GB file 
for copying.
But in this case, QFile and QDir interfaces should be shorten by removing some 
unnecessary methods. Ideally this operations interface should depend on paths 
only and shouldn't have any knowledge about QFile and QDir classes.

Agree that duplicate functionality in QDir and QFile should become deprecated.

Perhaps; overloads that QDir might make sense, as QDir could be seen as a class 
that operates on a string implementing path semantics in the context of the 
actual file system (e.g “cdUp” removes the last segment; cd(“foo”) adds “/foo” 
if foo exists). So, it provides perhaps at least input validation.

Hard to make a point for using QFile in the APIs though, at least not as input.


For the last point: Moving a file to a trash is something an application would 
want to do (for previous versions of saved files, for instance; for old 
save-games; for old downloads; for deleted workspaces etc); I absolutely see 
the usecases here. But I see no value in an API that provides comprehensive 
access to the system trash. Unless you use Qt to build a desktop environment or 
a file manager, you don’t need any of this. If you do the former, then you have 
done this already; hello KDE. If you do the latter, then that code should be in 
your app, and not in everyone’s Qt library.
Ok, I see your point. But imagine the situation when you need to restore a file 
from the trash, or get list of files in the trash, or check a space in the 
trash, or cleanup the trash... Wouldn't it be more convenient to have a 
separate class for all of this operations? In might be useful even if you have 
a separate operation for moving files to the trash, because you can make an 
operation undoable but the thing is that your program is not an exclusive owner 
of files. The trash bin can be re-created/moved/removed and so on. How would 
you locate your files in this case?


The question for me is: why would an application (that is not a file explorer) 
want to do any of this? I honestly don’t see the use case.


Cheers,
Volker



On 2/8/19 11:08 PM, Volker Hilsheimer wrote:
On

Re: [Development] New API design for file system operations

[Vitaly Fanaskov]

Hi Volker,

Making QFile::remove(bool toTrash=false); is tempting, but I think Thiago has a 
valid point about providing a dedicated file system operation abstraction, 
rather than cramming a mix of simple and complex file operations into QFile and 
QDir.
I agree that creating separate abstraction for file operations is an acceptable 
option. Although, I don't think that there is should be any difference between 
"simple"/"complex" or "long"/"short" or "atomic"/"non-atomic" operation in 
terms of user. As an API user I want to just perform some actions and don't 
care what is the under the hood; I also want all available operations to be 
presented in one place based on global classification feature (e.g., "file 
operation"). Of course, some things like "this is potentially long 
operation..." should be mentioned in the documentation.

I also think that we should have a look into some options for file operations 
from C++ 17: https://en.cppreference.com/w/cpp/filesystem/copy_options . 
Something similar is worth adding to the new API.


A dedicated operations interface that can work with both QFile and QDir (but 
essentially only cares about file paths) would be nice; that doens’t mean we 
can’t keep a QFIle API for the simple stuff, ideally one that doesn’t 
accidentially block your UI event loop because the user selected a 5 GB file 
for copying.
But in this case, QFile and QDir interfaces should be shorten by removing some 
unnecessary methods. Ideally this operations interface should depend on paths 
only and shouldn't have any knowledge about QFile and QDir classes.


For the last point: Moving a file to a trash is something an application would 
want to do (for previous versions of saved files, for instance; for old 
save-games; for old downloads; for deleted workspaces etc); I absolutely see 
the usecases here. But I see no value in an API that provides comprehensive 
access to the system trash. Unless you use Qt to build a desktop environment or 
a file manager, you don’t need any of this. If you do the former, then you have 
done this already; hello KDE. If you do the latter, then that code should be in 
your app, and not in everyone’s Qt library.
Ok, I see your point. But imagine the situation when you need to restore a file 
from the trash, or get list of files in the trash, or check a space in the 
trash, or cleanup the trash... Wouldn't it be more convenient to have a 
separate class for all of this operations? In might be useful even if you have 
a separate operation for moving files to the trash, because you can make an 
operation undoable but the thing is that your program is not an exclusive owner 
of files. The trash bin can be re-created/moved/removed and so on. How would 
you locate your files in this case?


On 2/8/19 11:08 PM, Volker Hilsheimer wrote:
On 8 Feb 2019, at 10:43, Vitaly Fanaskov 
mailto:vitaly.fanas...@qt.io>> wrote:

On 2/7/19 5:03 PM, Volker Hilsheimer wrote:

Hi all,


TL;DR; we are considering moving file system operations from QFile into a 
seperate class (or set of classes) for a more consistent and flexible way of 
moving, copying etc files and directories.


The conversation around the design and implementation of an API to move file or 
directory to the trash in https://bugreports.qt.io/browse/QTBUG-47703 has 
during the last days moved somewhat beyond that rather straight-forward task, 
and has become a broader discussion around making file operations accessible 
outside of the existing set of classes.



[…]

Hi,

I've read QTBUG-47703 very carefully and I think that adding some file managers 
is overkill in this particular case. I would suggest the following changes:

  1.  Extract an abstract class (i.e., interface) for common file operations
  2.  Both QFile and QDir should implement this interface
  3.  Unify QDir API, e.g.,  QDir::remove -> QDir::removeFile, in order to 
match newly-extracted interface
  4.  Add a separate class which represents system trash bin and contains 
appropriate methods (e.g., functionality to check files inside, restore files, 
empty trash etc.)

Also in my point of view, it's not necessary to introduce a new method like 
"moveToTrash". We can extend method "remove" adding a new parameter that might 
be either a bool flag or some enum.

Hi Vitaly and Tor Arne,

Making QFile::remove(bool toTrash=false); is tempting, but I think Thiago has a 
valid point about providing a dedicated file system operation abstraction, 
rather than cramming a mix of simple and complex file operations into QFile and 
QDir.

Looking at the documentation, QFile is an interface for reading from and 
writing to files; QDir provides access to directory structures and their 
contents. I’d like it if they were simple interfaces focusing on those specific 
tasks.

But in addition, they provide a mix of file path operations (ie purely string 
operation

Re: [Development] New API design for file system operations

[Vitaly Fanaskov]

Hi,

I've read QTBUG-47703 very carefully and I think that adding some file managers 
is overkill in this particular case. I would suggest the following changes:

  1.  Extract an abstract class (i.e., interface) for common file operations
  2.  Both QFile and QDir should implement this interface
  3.  Unify QDir API, e.g.,  QDir::remove -> QDir::removeFile, in order to 
match newly-extracted interface
  4.  Add a separate class which represents system trash bin and contains 
appropriate methods (e.g., functionality to check files inside, restore files, 
empty trash etc.)

Also in my point of view, it's not necessary to introduce a new method like 
"moveToTrash". We can extend method "remove" adding a new parameter that might 
be either a bool flag or some enum.

On 2/7/19 5:03 PM, Volker Hilsheimer wrote:

Hi all,


TL;DR; we are considering moving file system operations from QFile into a 
seperate class (or set of classes) for a more consistent and flexible way of 
moving, copying etc files and directories.


The conversation around the design and implementation of an API to move file or 
directory to the trash in https://bugreports.qt.io/browse/QTBUG-47703 has 
during the last days moved somewhat beyond that rather straight-forward task, 
and has become a broader discussion around making file operations accessible 
outside of the existing set of classes.

The relevant disussion starts here:

https://bugreports.qt.io/browse/QTBUG-47703?focusedCommentId=445952=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-445952

and I’d like to have a few more eyeballs on that (that ticket is already being 
watched by 30+ people, so I do anticipate some interest).

I’d like to strike the balance between an API that’s easy to use, can deal with 
both atomic (delete a file) and complex operations (such as copying a file, or 
moving files between file systems), but that at the same time allows Qt users 
to control how operations are performed (batching jobs, executing 
synchronously, or asynchronously with progress updates, perhaps the ability to 
cancel, rate limit in case of network traffic being involved etc).

Thoughts, ideas, and pointers to other frameworks that you believe provide a 
good API are welcome here in this email thread before moving to a dedicated 
JIRA ticket. Thiago mentioned the KIO framework as a source for inspiration; I 
had to deal with IFileManager when implementing moving to trash on Windows.

Would be great if we can come up with something that allows us to include the 
move-to-trash functionality in Qt 5.14.


Cheers,
Volker



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


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Vitaly Fanaskov]

>Why not X instead?
>--
>
>- GitFlow, GitHub <= both are based on feature branches, that doesn't work
> well with gerrit.
So, the only problem here is gerrit (aside from personal preferences and 
habits of course). The question is shouldn't we abandon gerrit as this 
tool doesn't feet with the needs well? Inventing new approaches is of 
course super cool... But not always necessary.

What's wrong with using, say, gitflow + gitlab + upsource? Upsource is 
optional, but it's the way better for code review than gerrit.

On 1/23/19 4:51 PM, Jedrzej Nowacki wrote:
> Hi,
>
>It is time to rethink our branch model. We are approaching Qt6 development
> and I'm worried that what we have now, will simply not scale. As you know, our
> branch model is mainly(*) based on merging from stable up to development
> branches. In general, it is a very good model, which make sure that release
> branches are not getting obsolete too quickly, that most of the fixes are in
> the right places, that every commit is only once in the git history. It is a
> very clean model. It is also a very slow model, with a single point of
> failure.
>
>It is hard to maintain:
>My impression is that the current model works great for a single release
> branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is without
> counting temporary patch level branches. Merging through them is hard, we
> already had to use "cherry-pick mode" in some places. When we add to the
> picture dev and qt6 branches, merging will be very, very hard. It is
> practically a full time job to update qt5 repository and coordinate all the
> merges now (thank you Liang!), shortly after qt6 branch opening amount of work
> will be much bigger.
>It is slow:
>The merges take time. We produce a lot of code, we have a lot of tests that
> needs to pass. Even single failure delays merge propagation by at least one
> day. If by bad luck, the merge contains some API incompatible changes an
> intermediate jump through Qt5 integration is required, that adds at least 3
> days of delay.
>
>--
>
>Proposal in short: let's use cherry-pick mode everywhere.
>
>All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch cherry-
> pick, would be taken based on a tag in the commit message. We could add a
> footer that marks the change risk level as in quip-5 
> (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
> "stable", "LTS". By
> default everything would be cherry-picked to qt6 branch unless "no-future" tag
> would be given. Of course we can bike-shed about the tag names.
>
>Advantages:
>- no waiting for merges, a fix can be used right away after integration
>- faster propagation of fixes targeting all branches, as there are no 
> merges
> of merges
>- simpler for new contributors, always push to dev
>- in most cases a reviewer does no need to know what the current version
> number is
>- conflict resolution is distributed and affects mostly the author of the
> change
>- documents a change intent, which may be useful for people keeping own
> forks
>- over time with increased amount of conflicts old branches, in natural 
> way,
> stay untouched
>
>Disadvantages:
>- git history would be a bit wilder, "git branch --contains" would not work
>- commit messages in some branches would have kind of ugly footer as an
> effect of "cherry-pick -x"
>- there is a chance, that some cherry-picked commits may be left forgotten
> in gerrit after a failed integration
>
>Bot details:
>
>The bot would listen only for changes in dev, in some unusual cases one
> could target an other branch directly, but bot would not trigger automatic
> cherry-pick(***). The bot would wait for a successful dev integration before
> creating cherry-picked changes. The bot would use cherry-pick -x to annotate
> the origin patch. After the cherry-pick creation, it would push it to gerrit,
> +2 and stage once. It would be up to the author to re-stage in case of
> flakiness. In case of a cherry-pick conflict it should push unresolved 
> conflict
> to gerrit and add all reviewers and author to handle the issue.
>
> The list below shows branch targets for automatic cherry-pick based on given
> tag.
>
> dev (qt6)
> stable (qt6, 5.13)
> stable, no-future (5.13)
> LTS (qt6, 5.13, 5.12)
> LTS-strict (qt6, 5.13, 5.12, 5.9)
> LTS, no-future (5.13, 5.12)
>
> That is assuming that we have branches: qt6  dev  5.13  5.13.q  5.12  5.12.w
> 5.9  5.9.e  5.6  5.6.r
> I think we should assume that patch level branches, as well LTS in very strict
> state, are handled manually.
>
>
>Creation of new branches:
> We would branch more or less as usual. The only difference from the current
> system is that we would not need the back merge / soft branching 

Re: [Development] Coding style for lambdas with empty parameter list

[Vitaly Fanaskov]

I vote for shorter form as well.

But the documentation should be extended with the Philippe's second 
example. Trailing return type is rarely required, but we cannot omit 
parameters list in this case, because it leads to compilation error.

On 1/9/19 8:31 PM, Philippe wrote:
> I like the shorter form, but keep in mind that when the return type
> needs to be specified,
>
> [] ->foo { // lambda content }
>
> is not possible, and following is needed:
>
> []() -> foo { // lambda content }
>
> Philippe
>
> On Wed, 9 Jan 2019 19:08:46 +0100
> "André Hartmann"  wrote:
>
>> Hi all,
>>
>> I recently found an inconsistency regarding empty lambda parameter lists
>> between [1] and [2]. While the first states, that parentheses have to be
>> written always, the latter is missing this section.
>>
>> My request to syncronize both [3] lead to the conclusion, to change the rule,
>> so that empty parameter lists should be written as
>>
>>   [] { // lambda content }
>>
>> instead
>>
>>   []() { // lambda content }
>>
>> If anyone has objections against this change, please vote at [3].
>> I'll keep this commit open a while and adopt the Wiki [1] once the change
>> is approved without objections.
>>
>> Thanks and regards,
>> André
>>
>> [1] https://wiki.qt.io/Coding_Conventions#Lambdas
>> [2] https://code.woboq.org/qt5/qt-creator/doc/api/coding-style.qdoc.html#772
>> [3] https://codereview.qt-project.org/249192
>> ___
>> 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

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

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