Re: [Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

[Friedemann Kleint]

Hi,

 > But the case of linear arrangement of screens can be solved. The only 
questions are whether it's necessary to  solve it to get the 
currently-broken applications fixed and if it is, how to detect the 
cases where we can and when to give up.

Just for the record: If you switch Windows to DPI awareness = 1 (system 
DPI aware) as opposed to Qt's default (2, per monitor DPI aware), you 
will also get screen arrangements with gaps from the system when 
differently sized monitors are connected.

So, Qt needs to deal  with that situation and I don't think we should be 
trying to rearrange screens.

Regards, Friedemann

-- 

Friedemann Kleint
The Qt Company GmbH

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

[Development] Nominating Jan Arve Sæther as maintainer for accessibility

[Frederik Gladhorn]

Hi all,

I'd like to pass on the torch and step down as maintainer for accessibility in 
Qt.
I haven't been very active in the area lately. Jan Arve has been involved in 
most improvements and been much more active in reviews and improving our 
offering. I'd like to nominate him as new maintainer.

I'm currently also listed as Qt Speech maintainer, I'm unsure how much time 
I'll spend on it in the future, so if someone wants to take over, I'd be happy 
to give up that maintainer role as well.

Greetings,
Frederik

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

Re: [Development] Changes to Qt offering

[Mark De Wit]

I'm guessing the Qt installer has now been updated in line with the licensing 
changes?  

I've just had the first developer in our team come up to me to complain that 
they can't install Qt My usual response of click the skip button appears to 
no longer work.  And no, I'm not going to ask 45 developers in this company to 
create Qt accounts, that's a non-starter... 

Mark

> -Original Message-
> From: Development  On Behalf Of
> Mark De Wit
> Sent: 28 January 2020 11:38
> To: Lars Knoll ; Qt development mailing list
> 
> Subject: Re: [Development] Changes to Qt offering
> 
> I've been working really hard over the past few years to get Qt used more 
> within
> my organisation.  However, mandating that our 45 developers all register Qt
> accounts is a complete non-starter, especially if only 2 or 3 of them actually
> work with UI on a day-to-day basis.   For the rest of them, Qt is a tool 
> that's
> required to build the software, the same as every other 3rd party module that
> they're forced to install & endure.
> 
> This may well be a show-stopper for future adoption of Qt for me.  (on top of 
> Qt
> Widget issues/limitations that turn into blocking issues which isn't helping 
> my
> cause either...)
> 
> Mark
> 
> -Original Message-
> From: Development  On Behalf Of Lars
> Knoll
> Sent: 27 January 2020 14:35
> To: Qt development mailing list 
> Subject: [Development] Changes to Qt offering
> 
> Hi all,
> 
> The Qt Company has done some adjustments to the Qt will be offered in the
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
> 
> The change consists of three parts.
> 
> One is a change in policy regarding the LTS releases, where the LTS part of a
> release is in the future going to be restricted to commercial customers. All 
> bug
> fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting
> bug fixes is something that the Qt Company will take care of for these LTS
> branches. We’ve seen over the past that LTS support is something mainly
> required by large companies, and should hopefully help us get some more
> commercial support for developing Qt further.
> 
> The second change is that a Qt Account will be in the future required for 
> binary
> packages. Source code will continue to be available as currently. This will
> simplify distribution and integration with the Marketplace. In addition, we 
> want
> open source users to contribute to Qt or the Qt ecosystem. Doing so is only
> possible with a valid Qt Account (Jira, code review and the forums all 
> require a
> Qt Account).
> 
> The third change is that The Qt Company will in the future also offer a lower
> priced product for small businesses. That small business product is btw not
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for
> Device Creation.
> 
> None of these changes should affect how Qt is being developed. There won’t be
> any changes to Open Governance or the open development model.
> 
> Best regards,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Jan Arve Sæther as maintainer for accessibility

[Volker Hilsheimer]

> On 31 Jan 2020, at 09:50, Frederik Gladhorn  wrote:
> 
> Hi all,
> 
> I'd like to pass on the torch and step down as maintainer for accessibility 
> in Qt.
> I haven't been very active in the area lately. Jan Arve has been involved in 
> most improvements and been much more active in reviews and improving our 
> offering. I'd like to nominate him as new maintainer.
> 
> I'm currently also listed as Qt Speech maintainer, I'm unsure how much time 
> I'll spend on it in the future, so if someone wants to take over, I'd be 
> happy to give up that maintainer role as well.
> 
> Greetings,
> Frederik


+1

Thanks for your work in the accessibility area, Frederik!


Volker


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

Re: [Development] Changes to Qt offering

[Tino Pyssysalo]

The problem must be somewhere else. There are no installer changes in 
production yet. 
--
Tino Pyssysalo
Qt Installer Product Owner 


On 31.1.2020, 11.09, "Development on behalf of Mark De Wit" 
 wrote:

> I'm guessing the Qt installer has now been updated in line with the 
licensing changes?  
>
> I've just had the first developer in our team come up to me to complain 
that they can't install Qt My usual response of click the skip button 
appears to no longer work.  And no, I'm not going to ask 45 developers in  
> this company to create Qt accounts, that's a non-starter... 
>
> Mark

 

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

Re: [Development] Changes to Qt offering

[Mark De Wit]

Ah, you are right, thanks for your help.  It turns out, accidentally entering a 
character in the email field does indeed remove the Skip button, but I spotted 
the issue for them and was able to guide them through the rest of the 
installation.

Mark

> -Original Message-
> From: Tino Pyssysalo 
> Sent: 31 January 2020 09:32
> To: Mark De Wit ; Qt development mailing list
> 
> Subject: Re: [Development] Changes to Qt offering
> 
> The problem must be somewhere else. There are no installer changes in
> production yet.
> --
> Tino Pyssysalo
> Qt Installer Product Owner
> 
> 
> On 31.1.2020, 11.09, "Development on behalf of Mark De Wit"  boun...@qt-project.org on behalf of mark.de...@iesve.com> wrote:
> 
> > I'm guessing the Qt installer has now been updated in line with the 
> licensing
> changes?
> >
> > I've just had the first developer in our team come up to me to complain 
> that
> they can't install Qt My usual response of click the skip button appears 
> to no
> longer work.  And no, I'm not going to ask 45 developers in
> > this company to create Qt accounts, that's a non-starter...
> >
> > Mark
> 
> 

___
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] Nominating Jan Arve Sæther as maintainer for accessibility

[Alex Blasche]

> -Original Message-
> From: Development  On Behalf Of
> Frederik Gladhorn
> I'd like to pass on the torch and step down as maintainer for accessibility 
> in Qt.
> I haven't been very active in the area lately. Jan Arve has been involved in 
> most
> improvements and been much more active in reviews and improving our
> offering. I'd like to nominate him as new maintainer.

+1

Thank you for your work and dedication.

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

[Development] Qt 5.12.7 Released

[Jani Heikkinen]

Hi Everyone!

We have released Qt 5.12.7 today, see https://www.qt.io/blog/qt-5.12.7-released

Thanks to everyone involved!

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] (no subject)

[Emily Kaizer]

Take me off this list 

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

Re: [Development] Nominating Jan Arve Sæther as maintainer for accessibility

[Lars Knoll]

> On 31 Jan 2020, at 11:51, Alex Blasche  wrote:
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Frederik Gladhorn
>> I'd like to pass on the torch and step down as maintainer for accessibility 
>> in Qt.
>> I haven't been very active in the area lately. Jan Arve has been involved in 
>> most
>> improvements and been much more active in reviews and improving our
>> offering. I'd like to nominate him as new maintainer.
> 
> +1
> 
> Thank you for your work and dedication.

Another +1.

Thanks for all the work and contributions!

Cheers,
Lars

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

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

[Bogdan Vatra via Development]

Hi,

  It seem the community it's still pissed off on TQC, so I'm going to break the 
ice here :).
  I'll personally go with std::* (not only for smart ptrs but for everything 
else (e.g. containers), except QString of course). QPointer still needs to 
stay as there is nothing in std:: which we can use (unless it's not needed 
anymore).
  Regarding the second issue, I'd like to have (const) references & shared 
ptrs only and to avoid raw pointers. 

Cheers,
BogDan.

În ziua de vineri, 31 ianuarie 2020, la 12:07:52 EET, Vitaly Fanaskov a scris:
> 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



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

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

[Daniel Teske]

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

Re: [Development] (no subject)

[Jenifer Lambert]

Take me off this list

Sent from my iPhone

> On Jan 31, 2020, at 5:02 AM, Emily Kaizer  wrote:
> 
> Take me off this list 
> 
> Sent from my iPhone
> ___
> 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]

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

Re: [Development] (no subject)

[Tuukka Turunen]

Hi Emily and Jenifer,

If you wish be removed from the mailing list, you can unsubscribe via: 
https://lists.qt-project.org 

Do not send requests asking to be removed from the list, just unsubscribe 
following the instructions online.

Yours,

Tuukka

On 31.1.2020, 15.29, "Development on behalf of Jenifer Lambert" 
 wrote:

Take me off this list

Sent from my iPhone

> On Jan 31, 2020, at 5:02 AM, Emily Kaizer  wrote:
> 
> Take me off this list 
> 
> Sent from my iPhone
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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


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

Re: [Development] (no subject)

[Florian Bruhin]

Emily, Jenifer,

Every post to this list has a link to the list information page in the footer:

On Fri, Jan 31, 2020 at 12:02:25PM +, Emily Kaizer wrote:
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

You can unsubscribe at the bottom of that page.

Florian

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


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

Re: [Development] (no subject)

[Brook Cronin]

Additionally, if you’re reading and replying on your iPhone (as the signatures 
suggest) there is the option to unsubscribe in the header of every email in the 
mail app.

Sent from my iPhone

> On 31. Jan 2020, at 15:23, Florian Bruhin  wrote:
> 
> Emily, Jenifer,
> 
> Every post to this list has a link to the list information page in the footer:
> 
>> On Fri, Jan 31, 2020 at 12:02:25PM +, Emily Kaizer wrote:
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> You can unsubscribe at the bottom of that page.
> 
> Florian
> 
> -- 
> m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
>   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
>   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
> I love long mails! | https://email.is-not-s.ms/
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Allan Sandfeld Jensen]

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


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

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

[Giuseppe D'Angelo via Development]

On 31/01/2020 11: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.

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.


Here it seems we're just talking about the std smart pointers: 
unique_ptr, shared_ptr and weak_ptr.


My take for Qt 6 should be:

* use them as-is;
* move the Qt implementations to Qt5Compat (the Qt5 implementations are 
strictly inferior in their feature set);
* adjust the few places where a Qt smart pointer can be used to also 
take a std:: one (QVariant? C++ <-> QML bridging?)


AFAIK, there's only 2-3 usages in public APIs of Qt smart pointers, that 
would therefore need to be ported away (from the back of my mind: 
QtQuick, Qt3D in quite some deep API. Maybe QtWebEngine?)



The last smart pointer in Qt is QPointer, which is a special case, 
having obviously no std equivalent. IMO it should


1) be renamed to something more clear (suggestions welcome, or it'll be 
QObjectWeakPointer)

2) be still available under the QPointer name in Qt5Compat.



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.


2) is impossible as stated, if you want to keep any amount of source 
compatibility.


Many more examples are needed, to discuss each case and eventually grasp 
some "rules".


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Development] The future of smart pointers in Qt API

[Eric Lemanisser]

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?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Matthew Woehlke]

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?

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

[Volker Hilsheimer]

> On 31 Jan 2020, at 16:27, Vitaly Fanaskov  wrote:
> On 1/31/20 4:13 PM, Eric Lemanisser wrote:
>>> > 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?
>> Are we really considering abandoning the parent-child ownership for
>> qt6 ? that would be a huge breaking change
>> 
> 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.
> 


Parent-child relationship is not going to go away, it has purpose beyond object 
lifetime: the visual hierarchy is encoded in the parent/child relationship of 
widgets, for example.

Making ownership of objects, and assumptions regarding their life-cycle, 
explicit in code is a good thing though. Using smart pointers is the idiomatic 
C++ way to do so. But it doens’t have to be the only way; a call to 
QObject::setParent is IMHO just as explicit, and parent/child in Qt is a 
concept you have to learn either way.

But sometimes our APIs are messy. QTabWidget::addTab transfers ownership of the 
QWidget*; QTabWidget::addAction does not transfer ownership of the QAction*. 
Unless you understand fairly well how QAction works, or unless you 
read/remember the documentation, it’s impossible to see from the code what 
happens wrt to object ownership.

API naming is not a scalable way to make the distinction, so finding how we can 
use smart pointers to make it clear in the code when ownership is transferred 
is a good idea.

Perhaps the pragmatic approach is to address this in those APIs that take a 
QObject* but don’t transfer ownership. I believe those are much fewer. 
Otherwise, the convention can be that any API that takes a raw pointer takes 
ownership. How this is implemented internally doesn’t matter.

Cheers,
Volker

___
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] Make a decision for asynchronous APIs

[Sona Kurazyan]

Hi everyone,

It's been a while since we've started discussions on this topic. I would like 
to summarize the outcome of these discussions and propose improvements to our 
asynchronous APIs based on the feedback we've received so far.

First of all, there was a question weather we should keep QtConcurrent and 
QFuture (and related classes) at all, and the answer seems to be "yes", because 
the corresponding STL alternatives are still lacking a lot of features: 
std::future still doesn't support continuations, its API is not finalized yet, 
no executors are supported for parallel algorithms in C++17, etc. Additionally, 
Qt's asynchronous APIs have extensions like cancelling, pausing, resuming and 
progress reporting (although not everyone agrees that these extensions fit with 
a typical future, but they can be useful in Qt-specific use-cases, for example 
GUI applications).

On the other hand, there are couple of improvements to be applied to 
QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. 
Here's the list of suggestions I've collected:

QFuture (and related classes)

  1.  Officially document QFutureInterface and rename it to QPromise 
(https://bugreports.qt.io/browse/QTBUG-81586)
  2.  Add support for continuations​ to QFuture 
(https://bugreports.qt.io/browse/QTBUG-81587)
  3.  Provide a way of integrating QFuture with signals 
(https://bugreports.qt.io/browse/QTBUG-81589)
  4.  Improve the error reporting of QFuture 
(https://bugreports.qt.io/browse/QTBUG-81588)

QtConcurrent

  1.  Rename QtConcurrent::run to qAsync() and modernize it 
(https://bugreports.qt.io/browse/QTBUG-81590)
  2.  Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to 
avoid exhausting all system threads.
  3.  Fix the algorithms which do not work with lambdas 
(https://bugreports.qt.io/browse/QTBUG-33735)
  4.  Add initial values to map/filter reduce 
(https://bugreports.qt.io/browse/QTBUG-73240)

It would be nice to hear some opinions, to see whether this is a right 
direction to go, and if it makes sense to put our effort on these improvements. 
Is there anything important I’m missing in the list? Or maybe some of these 
items do not add much value?

Additionally, there are some discussions about QFuture being a mix between a 
“Task” and a “Future”. One of the options of improving this situation is to 
make a QTask (or QJob) out of the current QFuture. But then the question is: 
should we also support a “classic” QFuture? Is there a value in having it, when 
there are already some very advanced implementations of a future?

Please share your thoughts!

Thanks,
Sona


From: Development  on behalf of Karsten 
Heimrich 
Sent: Thursday, December 19, 2019 2:12 PM
To: development@qt-project.org 
Subject: [Development] Make a decision for asynchronous APIs


Hi,

we are planning to continue some work on the QFuture, QtConcurrent APIs, either 
improve up on the existing implementation or deprecate and remove them 
completely for Qt6. We’ve created a user story in Jira and  like to gather some 
feedback here. So if this topic is of interest for you, I would like to point 
you to https://bugreports.qt.io/browse/QTBUG-80908 to place some comments there.



BR, Karsten


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

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

[André Somers]

On 31-01-20 15:14, Vitaly Fanaskov wrote:


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.



I agree that Qt suffers from a problem there, but I disagree on what the 
problem is.


I think it is quite strange that in 2020 we are still using an intrinsic 
data structure to structure our object trees. We stopped doing that for 
lists a long time ago. Instead of items in the list _being_ a node that 
can be in a list, we now have all kind of data structures at allow to 
manipulate our data in whatever data structure suits us for the task at 
hand. That may be node-based list structure, or whatever else. Yet, for 
our parent-child trees, we insist that this data needs to be represented 
as a pointers between QObject instances themselves.


In my opinion, Qt should have gotten rid of these instrinsic data 
structures a long time ago. If our object hierarchy is an n-ary tree, we 
should be using a type for the data structure that represents exactly 
that. We should not let the structure of our data be an incidental 
result of objects pointing to each other.


And yes, that is such a fundamental shift, there is no way it can be 
done (any time soon) I think. Still, I hope that for new API, it may be 
a consideration.


André


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

[Development] I do not know

[Karen]

What this is and do not want these e-mails.  Please remove my name for this 
site.

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

Re: [Development] I do not know

[Lisandro Damián Nicanor Pérez Meyer]

El vie., 31 ene. 2020 14:14, Karen  escribió:

> What this is and do not want these e-mails.  Please remove my name for
> this site.



For what it's worth: when I replied Thiago in the CVEs thread I also got
another mail from someone saying "I'm not Thiago". According to the headers
the mail was received trough the mailing list... Is there any chance that
someone started subscribing random people?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] I do not know

[Thiago Macieira]

On Friday, 31 January 2020 09:28:58 PST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El vie., 31 ene. 2020 14:14, Karen  escribió:
> > What this is and do not want these e-mails.  Please remove my name for
> > this site.
> 
> For what it's worth: when I replied Thiago in the CVEs thread I also got
> another mail from someone saying "I'm not Thiago". According to the headers
> the mail was received trough the mailing list... Is there any chance that
> someone started subscribing random people?

The list should ask for confirmation before actually subscribing. More likely, 
these emails are from dummy accounts.

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



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

Re: [Development] I do not know

[Giuseppe D'Angelo via Development]

On 31/01/2020 18:28, Lisandro Damián Nicanor Pérez Meyer wrote:
For what it's worth: when I replied Thiago in the CVEs thread I also got 
another mail from someone saying "I'm not Thiago". According to the 
headers the mail was received trough the mailing list... Is there any 
chance that someone started subscribing random people?


Doesn't the list send an activation link?

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Scott Bloom]

Re-reading Mark's initial post.  One thing, that I had requested from the 
trolls almost 20 years ago.. which Ill put out there again, is a 
"non-developer" license that allows people who don’t develop using Qt, but the 
product they work on uses it somewhere, and thus its required to build.

For a large company, (or even a small company) a license that was cheaper than 
full license (10% or so) would make deploying Qt on large projects a much 
easier pill to swallow.

I had worked with (in my consultant days) many a company, that loved the Qt 
containers over STL, but refused to allow them into the core code.  They split 
the tool between core and UI, and Qt was only allowed in the UI, no public APIs 
at all. Simply because they didn’t want to have to pay for a license for 
someone to iterate over a container, or to work with a QString

Scott

-Original Message-
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark 
De Wit
Sent: Friday, January 31, 2020 1:06 AM
To: Qt development mailing list 
Subject: Re: [Development] Changes to Qt offering

I'm guessing the Qt installer has now been updated in line with the licensing 
changes?  

I've just had the first developer in our team come up to me to complain that 
they can't install Qt My usual response of click the skip button appears to 
no longer work.  And no, I'm not going to ask 45 developers in this company to 
create Qt accounts, that's a non-starter... 

Mark

> -Original Message-
> From: Development  On Behalf Of 
> Mark De Wit
> Sent: 28 January 2020 11:38
> To: Lars Knoll ; Qt development mailing list 
> 
> Subject: Re: [Development] Changes to Qt offering
> 
> I've been working really hard over the past few years to get Qt used 
> more within my organisation.  However, mandating that our 45 
> developers all register Qt accounts is a complete non-starter, especially if 
> only 2 or 3 of them actually
> work with UI on a day-to-day basis.   For the rest of them, Qt is a tool 
> that's
> required to build the software, the same as every other 3rd party 
> module that they're forced to install & endure.
> 
> This may well be a show-stopper for future adoption of Qt for me.  (on 
> top of Qt Widget issues/limitations that turn into blocking issues 
> which isn't helping my cause either...)
> 
> Mark
> 
> -Original Message-
> From: Development  On Behalf Of 
> Lars Knoll
> Sent: 27 January 2020 14:35
> To: Qt development mailing list 
> Subject: [Development] Changes to Qt offering
> 
> Hi all,
> 
> The Qt Company has done some adjustments to the Qt will be offered in 
> the future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
> 
> The change consists of three parts.
> 
> One is a change in policy regarding the LTS releases, where the LTS 
> part of a release is in the future going to be restricted to 
> commercial customers. All bug fixes will (as agreed on the Qt 
> Contributor Summit) go into dev first. Backporting bug fixes is 
> something that the Qt Company will take care of for these LTS 
> branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
> 
> The second change is that a Qt Account will be in the future required 
> for binary packages. Source code will continue to be available as 
> currently. This will simplify distribution and integration with the 
> Marketplace. In addition, we want open source users to contribute to 
> Qt or the Qt ecosystem. Doing so is only possible with a valid Qt 
> Account (Jira, code review and the forums all require a Qt Account).
> 
> The third change is that The Qt Company will in the future also offer 
> a lower priced product for small businesses. That small business 
> product is btw not limited to mobile like the one Digia had some years 
> ago, but covers all of Qt for Device Creation.
> 
> None of these changes should affect how Qt is being developed. There 
> won’t be any changes to Open Governance or the open development model.
> 
> Best regards,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Make a decision for asynchronous APIs

[Elvis Stansvik]

Den fre 31 jan. 2020 kl 17:25 skrev Sona Kurazyan :
>
> Hi everyone,
>
>
>
> It's been a while since we've started discussions on this topic. I would like 
> to summarize the outcome of these discussions and propose improvements to our 
> asynchronous APIs based on the feedback we've received so far.
>
>
>
> First of all, there was a question weather we should keep QtConcurrent and 
> QFuture (and related classes) at all, and the answer seems to be "yes", 
> because the corresponding STL alternatives are still lacking a lot of 
> features: std::future still doesn't support continuations, its API is not 
> finalized yet, no executors are supported for parallel algorithms in C++17, 
> etc. Additionally, Qt's asynchronous APIs have extensions like cancelling, 
> pausing, resuming and progress reporting (although not everyone agrees that 
> these extensions fit with a typical future, but they can be useful in 
> Qt-specific use-cases, for example GUI applications).
>
>
>
> On the other hand, there are couple of improvements to be applied to 
> QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. 
> Here's the list of suggestions I've collected:
>
>
>
> QFuture (and related classes)
>
> Officially document QFutureInterface and rename it to QPromise 
> (https://bugreports.qt.io/browse/QTBUG-81586)
> Add support for continuations to QFuture 
> (https://bugreports.qt.io/browse/QTBUG-81587)
> Provide a way of integrating QFuture with signals 
> (https://bugreports.qt.io/browse/QTBUG-81589)
> Improve the error reporting of QFuture 
> (https://bugreports.qt.io/browse/QTBUG-81588)
>
>
>
> QtConcurrent
>
> Rename QtConcurrent::run to qAsync() and modernize it 
> (https://bugreports.qt.io/browse/QTBUG-81590)
> Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to 
> avoid exhausting all system threads.
> Fix the algorithms which do not work with lambdas 
> (https://bugreports.qt.io/browse/QTBUG-33735)
> Add initial values to map/filter reduce 
> (https://bugreports.qt.io/browse/QTBUG-73240)

Even if I've not read all the links, to me as a user of QtConcurrent
these all sounds like great improvements, bringing significant value.

>
>
>
> It would be nice to hear some opinions, to see whether this is a right 
> direction to go, and if it makes sense to put our effort on these 
> improvements. Is there anything important I’m missing in the list? Or maybe 
> some of these items do not add much value?
>
>
>
> Additionally, there are some discussions about QFuture being a mix between a 
> “Task” and a “Future”. One of the options of improving this situation is to 
> make a QTask (or QJob) out of the current QFuture. But then the question is: 
> should we also support a “classic” QFuture? Is there a value in having it, 
> when there are already some very advanced implementations of a future?

I don't have too much to comment on this. Would the alternative to
QFuture in this scenario be a future class from somewhere else
(std::future, ...)? And the Qt goodies like
cancel/pause/resume/progress API would be on QTask?

Elvis

>
>
>
> Please share your thoughts!
>
>
>
> Thanks,
>
> Sona
>
>
>
> 
>
> From: Development  on behalf of Karsten 
> Heimrich 
> Sent: Thursday, December 19, 2019 2:12 PM
> To: development@qt-project.org 
> Subject: [Development] Make a decision for asynchronous APIs
>
>
>
> Hi,
>
> we are planning to continue some work on the QFuture, QtConcurrent APIs, 
> either improve up on the existing implementation or deprecate and remove them 
> completely for Qt6. We’ve created a user story in Jira and  like to gather 
> some feedback here. So if this topic is of interest for you, I would like to 
> point you to https://bugreports.qt.io/browse/QTBUG-80908 to place some 
> comments there.
>
>
>
> BR, Karsten
>
>
>
> ___
> 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] Make a decision for asynchronous APIs

[Allan Sandfeld Jensen]

On Freitag, 31. Januar 2020 17:24:20 CET Sona Kurazyan wrote:
> Additionally, there are some discussions about QFuture being a mix between a
> “Task” and a “Future”. One of the options of improving this situation is to
> make a QTask (or QJob) out of the current QFuture. But then the question
> is: should we also support a “classic” QFuture? Is there a value in having
> it, when there are already some very advanced implementations of a future?
> 
As I have expressed earlier I would love the simplified QFuture, just a 
something that can hold the result of an async function, but no runtime 
controls. Just ways to test if the result is ready and to be notified when it 
is, like with a waitForResult blocking method and a signal emitter of some 
kind. 

I think there are many cases where such an API would be useful.

Best regards
'Allan


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

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

[André Pönitz]

On Fri, Jan 31, 2020 at 10:07:52AM +, Vitaly Fanaskov wrote:
> 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.

1)

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

[Simon Hausmann]

On 31.01.20 11:07, 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.


Thanks for taking the discussion here, Vitaly :)


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


I really relaly like the direction of the change that Allan proposes, so 
my opinion is (3). Introduce the use of std::unique_ptr overloads where 
applicable in our API, keep QObject parent/child as is and go with this 
and learn. The unique_ptr really _adds_ to our API here, makes it 
slightly "richer".

There is API that uses QSharedPointer today, some QPA platform dialog 
bits and for example QSharedPointer 
grabToImage(const QSize &targetSize = QSize());

I still believe that the less #ifdefs our users have to paste into their 
code base when using Qt 5 and 6, the more people will transition and I 
think that's critical to success. That is what makes me think we should 
keep existing QSharedPointer API. There might be more in "leaf" modules.


Simon

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

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

[Alberto Mardegan]

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.

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

1. (though of course, we should also use smart pointers where they bring
a clear advantage)

Ciao,
  Alberto


-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

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

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

[Allan Sandfeld Jensen]

On Freitag, 31. Januar 2020 21:04:58 CET 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?

QScopedPointer is exactly the counterpart to unique_ptr, the only difference 
is the decision not to provide a move constructor and assignment when we 
finally were allowed to use C++11,

'Allan


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

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

[Giuseppe D'Angelo via Development]

On 31/01/2020 21:09, Allan Sandfeld Jensen wrote:

QScopedPointer is exactly the counterpart to unique_ptr, the only difference
is the decision not to provide a move constructor and assignment when we
finally were allowed to use C++11,


"Only difference" is a major understatement here.

The question stays: how do we call a unique_ptr equivalent?

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Fri, 31 Jan 2020 at 22:09, Allan Sandfeld Jensen  wrote:

> > > 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?
>
> QScopedPointer is exactly the counterpart to unique_ptr, the only difference
> is the decision not to provide a move constructor and assignment when we
> finally were allowed to use C++11,

Which makes it not a counterpart.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[André Pönitz]

On Fri, Jan 31, 2020 at 03:27:29PM +, 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

[André Somers]

Hi,

Pure from a transitioning perspective: isn't it rather late for such a 
massive change? Wasn't it the idea that 5.15 would be the 
"transitioning" version that people could use to make their code 
Qt6-ready? In that case, should this not have already been implemented 
in Qt 5.15, as I think that one is FF now?


Cheers,

André

On 31-01-20 11:07, 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.


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

 > 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 +, 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

[Giuseppe D'Angelo via Development]

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development