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
> 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é
> 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
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
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
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
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
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
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)
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
>
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 :)
>
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
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
>
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
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
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
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
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
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
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
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
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
> 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.
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
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
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
> 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 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
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
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
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
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
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
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
>
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
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
> 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
Take me off this list
Sent from my iPhone
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
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
> -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
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
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
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
> 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
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
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.
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
47 matches
Mail list logo
