Hi Daniel,
On 29-10-2025 12:00, Daniel Schürmann wrote:
> On 29 Oct 2025, at 01:42, Ville Voutilainen
<[email protected]> wrote:
>
One thing to consider in this context is if/how we’d like QLayout
to be part of this logic. When building a widget UI, QLayout is
ultimately responsible for taking core of the correct parent/child
relationships etc. Opinions vary on that topic, but I typically
create child widgets without parent and rely on the layout. So, we
might find out that a QLayout::makeChildWidget makes sense.
Maybe...? I mean, does it need it's own, given that it is a QObject already?
Volker
that sounds great. I am happy to help. I will need a helping hand
since I have no experience with the Qt contribution process.
I am happy that it fits to my summary here:
https://lists.qt-project.org/pipermail/development/2025-October/046669.html
Listing things we have agreed with incorporated semantics (please
correct me or confirm):
QParentedPointer: A new pointer that points to a QObject with some
parent != nullptr.
QObject::makeChildObject(): That creates a parented Objects.
I would suggest you split these into separate commits. Neither depends
on the other, though they _can_ be used together. Full disclosure: I
still doubt the usefulness of the specific pointer type.
Borrow case (pChild must not outlive pDialog):
Child *pChild = pDialog->makeChildObject<Child>()
Member variable case (m_pChild is never dangling because the parent ==
this)
QParentedPointer<Child> m_pChild = makeChildObject<Child>()
Open Ideas:
· Make QParentedPointer<Child> QObject::makeChildObject() protected
No, please don't have your parented pointer be the return type of
makeChildObject. And making it protected won't work. There are many
cases where you want to "attach" children to a parent object. Making it
a protected method will severely limit the usefulness of the method.
· Add a QObject::addChild(std::unique_ptr<QObject *> child)
Start simple, I would suggest. Do you really think that this will bring
a lot of value? Introduce the basic version, see how it actually impacts
your code base and collect feedback, and then see if an overload like
this really would bring value. One problem I see is that, AFAIK, a
std::unique_ptr<QObject> is a distinct type from a
std::unique_ptr<SomethingDerivedFromQObject>, so the signature above
won't work. Something _like_ this can of course be done, using a
template and casting, but it won't be as pretty.
· Ideas around UniqueObjectPtrDeleter() which can be better
implemented by Qt Object tree allowing shared ownership
· makeQSharedPointer / makeQPointer …
I think we have two interpretations we need to be explicit on to avoid
later discussions:
1. QParentedPointer: Object has any parent -> there where objections,
we already have QPointer()
2. QParentedPointer: Object has “this” parent -> some implicit
lifetime guarantees
The latter seems really weird. Given that pointers are value types and
can thus be copied, there is no way to guarantee the pointer belongs to
the current object. I would object to such a thing.
Cheers,
André
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
