> On 3 Feb 2020, at 10:26, Ola Røer Thorsen wrote:
>
> - The biggest struggle I have with Qt currently regarding pointers is when
> you share a dynamic model of QObject* to qml. Here it would actually be
> useful to have shared_ptr, and I've solved this with some Q_GADGET-based
> wrappers.
> On 3 Feb 2020, at 17:59, Jason H wrote:
>
> Recently this has caused me much consternation. I think QtQuick everything
> should have a parent, and a visual parent, though I appreciate how tedious
> this would be. They should be the same except when they can't and having
> separate
On 1 Feb 2020, at 19:20, Daniel Teske mailto:q...@squorn.de>>
wrote:
Now to take your next example: setParent is not fine. setParent can be used in
4 different ways:
child->setParent(child->parent()): Invariant holds
child->setParent(newParent): Invariant holds
child->setParent(nullptr): Nope
Il 03/02/20 23:55, André Pönitz ha scritto:
On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
Il 03/02/20 20:38, André Pönitz ha scritto:
Directly affected are for instance functions operating on full containers in
https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
Just
Il 04/02/20 00:49, André Pönitz ha scritto:
I've asked "what's wrong with the C++ smart pointers" a dozen times and
never received a satisfactory answer.
Did you? I am - to some degree truly - afraid I didn't notice.
[snip]
I apologize, I should've asked more clearly: "what's wrong with the
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
André Pönitz
Sent: Monday, February 3, 2020 3:50 PM
To: Giuseppe D'Angelo
Cc: development@qt-project.org
Subject: Re: [Development] The future of smart pointers in Qt API
On Mon, Feb 03, 2020 at 10:25:40PM +0100,
On Mon, Feb 03, 2020 at 10:25:40PM +0100, Giuseppe D'Angelo via Development
wrote:
> I've asked "what's wrong with the C++ smart pointers" a dozen times and
> never received a satisfactory answer.
Did you? I am - to some degree truly - afraid I didn't notice.
Answer would have been easy: They
On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 20:38, André Pönitz ha scritto:
> > Directly affected are for instance functions operating on full containers in
> >
> >https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
>
> Just to set the record straight, the
On 01/02/2020 07.31, Allan Sandfeld Jensen wrote:
> It is still a terrible name. Unique pointer refers to something
> std::unique_ptr can abstractly achieve, but not what it actually is.
It refers to something that had *better* be achieved, or else you're
using it wrong.
The *ownership* is
Il 03/02/20 17:56, Jason H ha scritto:
As a result, the code of a Qt-using program should be readable by average developers not big into C++.
But no one is imposing super-advanced C++ features on Qt users and Qt
applications...
Meanwhile, it also does not serve anyone to duplicate stl. I
Il 03/02/20 20:38, André Pönitz ha scritto:
Directly affected are for instance functions operating on full containers in
https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
Just to set the record straight, the main reason why qAlgorithm(begin,
end) as well as qAlgorithm(container) have
+1 from me too.
On 31 Jan 2020, at 09:50, Frederik Gladhorn
mailto:frederik.gladh...@qt.io>> 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
On 03/02/20 19:56, Jason H wrote:
> [...] As a result, the code of a Qt-using program
> should be readable by average developers not big into C++.
[...]
I agree with all what you said; I'm just quoting this sentence because
it's easy to underestimate this.
Ciao,
Alberto
--
On Mon, 3 Feb 2020 at 16:17, coroberti . wrote:
>
> Jason,
> The main market for QtCompany is embedded, automotive, etc.
>
> Mobile is aside with no real sales there.
>
> So, unless community develops features required,
> do not expect to get new mobile features fast.
> Sorry to say that.
We
On Sun, Feb 02, 2020 at 11:32:02PM +0100, Giuseppe D'Angelo wrote:
> On 02/02/2020 22:45, André Pönitz wrote:
> > > This is a logical fallacy; "I don't need it, noone else does".
> > But this is the argument the de-Qt-ers use when it comes to Qt convenience
> > they don't need.
>
> Which Qt
I agree completely with Jason.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi Daniel,
I like many things in this proposal, especially the principles; thanks for that!
Where I’m on the fence is the replacing of setParent with “adoptChild”. I think
of “parent” as a property of an object, so setParent/parent accessors are the
API that fits into my mental model. I
Recently this has caused me much consternation. I think QtQuick everything
should have a parent, and a visual parent, though I appreciate how tedious this
would be. They should be the same except when they can't and having separate
properties would highlight that.
> Sent: Monday, February 03,
Well, I for one do not welcome our new std:: overlords. After many years of
using C++ (since 98) and diving deeper into it, I think Qt and the C++
committee are two completely separate audiences. I cringe at stl code. I once
asked a question on how to reverse something, and what followed was
> Vitaly Fanaskov
>
> [...] In this case, I think we won't have this confusing definitions like
> "visual
> parent" and "just a parent"
> (that we have in controls).
Sorry, couldn't resist: visual parent vs QObject parent is a distinction that
Qt Quick made, not Qt Quick Controls.
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
I just want to say that the qthttpserver is the most impactful contribution to
Qt for me in along time.
Having a http server in Qt has allowed saved me so much work, provide so many
additional integrations with ease.
* would use again.
Given hoe much positive impact it has had, I would like
Il 03/02/20 14:59, Vitaly Fanaskov ha scritto:
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.
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
> On 3 Feb 2020, at 08:15, Mikhail Svetkin wrote:
>
> Hello,
>
> I would like to make request to move qthttpserver from qt-labs namespace to a
> new namespace qt-addons or qt-extensions.
>
> The main reason is that it is not a research project anymore. I believe that
> the module is ready
> On 1 Feb 2020, at 19:20, Daniel Teske wrote:
>> 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
Jason,
The main market for QtCompany is embedded, automotive, etc.
Mobile is aside with no real sales there.
So, unless community develops features required,
do not expect to get new mobile features fast.
Sorry to say that.
Kind regards,
Robert
On Tue, Jan 28, 2020 at 7:37 PM Jason H wrote:
>
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
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
Hi,
The Qt CMake Port team would like to merge the wip/cmake branch of qtbase to
dev, soon™ (this week or next week).
This is mostly a heads up email, so that it doesn't come as a total surprise.
How this affects people:
1) The qmake Coin builds are still there and continue to work.
2) Soon
Mikhail Svetkin (3 February 2020 08:15) proposed:
> I would like to make request to move qthttpserver from qt-labs
> namespace to a new namespace qt-addons or qt-extensions.
>
> The main reason is that it is not a research project anymore. I
> believe that the module is ready to become a self
søn. 2. feb. 2020 kl. 00:15 skrev Giuseppe D'Angelo via Development <
development@qt-project.org>:
> 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?
>
>
I'm not sure if
> Anyway, how are we on Qt 6.0 future-compat features? Are they in 5.15?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
I've started moving things (QLinkedList for now) to Qt5Compat in dev branch,
5.15 is not affected.
Best
Hi Daniel,
Thanks for the nice work of looking to use unique_ptr, I like it, I think it
makes ownership clearer.
About having wrappers or not I am still on the fence, I think using stl when
possible is a good idea, but I see the advantage of having consistent naming,
so I am not sure about the
Hey,
On Monday, February 3, 2020 10:28:53 AM EET Ville Voutilainen wrote:
> On Mon, 3 Feb 2020 at 08:58, Bogdan Vatra wrote:
> > > Qt installer resumes downloads after a network connection break.
> > > apt-get does not. :)
> > >
> > You must be kidding, apt it's (one of) the best package
On Mon, 3 Feb 2020 at 08:58, Bogdan Vatra wrote:
> > Qt installer resumes downloads after a network connection break.
> > apt-get does not. :)
>
> You must be kidding, apt it's (one of) the best package manager! It resumes
> the download(s) from the same point from where the connection dropped.
36 matches
Mail list logo
