Well, it appears that reparenting in the QObject is not possible in pure
QML right now. Not sure why something like this isn't part of the standard
QQuickItem repertoire. If you implement your own QQuickItem, it is trivial.
E.g. using PyQt5:
class FosterParent(QtQuick.QQuickItem):
@pyqtSlot(QtQuick.QQuickItem)
def adopt(self, item):
item.setParentItem(self)
item.setParent(self)
Now, from QML I can call:
newParent.adopt(target);
oldParent.destroy();
And everything appears to work as desired.
Best regards,
kloffy
On Mon, Dec 21, 2015 at 2:44 AM, Elvis Stansvik <elvst...@gmail.com> wrote:
> 2015-12-20 17:27 GMT+01:00 Peter Klosowski <klo...@gmail.com>:
> > Just to let you know, quick attempts to hack it such as...
> >
> > newParent.data[0] = target;
> >
> > ... or...
> >
> > newParent.data = [target];
> >
> > ... run without errors, but behavior is unchanged (i.e. the blue
> rectangle
> > gets destroyed with oldParent).
>
> Yea, I tried and got the same result. So strange, the docs clearly
> speaks of assigning to the data property.
>
> Elvis
>
> >
> >
> > On Mon, Dec 21, 2015 at 2:13 AM, Peter Klosowski <klo...@gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Mon, Dec 21, 2015 at 2:03 AM, Elvis Stansvik <elvst...@gmail.com>
> >> wrote:
> >>>
> >>> 2015-12-20 16:39 GMT+01:00 Peter Klosowski <klo...@gmail.com>:
> >>> > Unfortunately, the solution Elvis provided does not work for me.
> >>> > Instead, I
> >>> > get the following error:
> >>> >
> >>> > TypeError: Property 'push' of object [object Object] is not a
> function
> >>> >
> >>>
> >>> Aha, I only tested it briefly in qmlviewer, so I didn't see those
> >>> errors. So then it only seemingly worked for me.
> >>
> >>
> >> No worries, it would have been awesome if the solution was that simple.
> >>
> >>>
> >>> > Of course, that means the blue rectangle stays on the screen, but
> only
> >>> > because the code after the error never gets executed (i.e. oldParent
> >>> > never
> >>> > gets destroyed).
> >>> >
> >>> > Nevertheless, I believe this would be the right track, if it is
> >>> > possible at
> >>> > all.
> >>>
> >>> Yes I think from the docs I found ("Any object assigned to an item's
> >>> data property becomes a child of the item within its QObject hierarchy
> >>> [...]"), it should be possible somehow. Question is how to do that
> >>> assignment. Or perhaps the docs are a little misleading, and by
> >>> "assignment" they simply mean declaring an item inside another, and
> >>> there's no way to do this dynamically..? Would be kind of weird if it
> >>> wasn't possible though.
> >>
> >>
> >> I agree, that seems like a pretty glaring omission. Digging into the
> >> sources (qt/qdeclarativelist.cpp), it appears that lists have a method
> for
> >> appending items, but as far as I can tell it looks like it is not
> accessible
> >> via QML. In the worst case, I could probably implement the newParent in
> C++
> >> and wrap the call to append in a custom Q_INVOKABLE function. So at
> least I
> >> have a contingency plan now...
> >>
> >>>
> >>> Elvis
> >>>
> >>> >
> >>> > Best regards,
> >>> > kloffy
> >>> >
> >>> >
> >>> > On Mon, Dec 21, 2015 at 1:28 AM, Peter Klosowski <klo...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Thank you all for your suggestions. This is an artificial example to
> >>> >> illustrate the behavior that I am having problems with. I could also
> >>> >> dynamically create the parent, that is not of relevance to my
> problem.
> >>> >>
> >>> >> On the other hand, the information that Elvis provided about the
> >>> >> distinction between visual parent and QObject parents seems to hit
> the
> >>> >> nail
> >>> >> on the head. I will test and report back!
> >>> >>
> >>> >> Best regards,
> >>> >> koffy
> >>> >>
> >>> >> On Mon, Dec 21, 2015 at 1:10 AM, Elvis Stansvik <elvst...@gmail.com
> >
> >>> >> wrote:
> >>> >>>
> >>> >>> 2015-12-20 16:05 GMT+01:00 Personal Gmail
> >>> >>> <siamak.rahimi.mo...@gmail.com>:
> >>> >>> > Hi Elvis ,
> >>> >>> > Can we destroy() old parent which is not a component ? In other
> >>> >>> > words,
> >>> >>> > Is
> >>> >>> > not the destroy only for component created dynamically ?
> >>> >>> > I think oldParent.destory is problematic.
> >>> >>>
> >>> >>> Aha, now I see what you mean. I've never actually used QML myself,
> >>> >>> and
> >>> >>> didn't know this (and that setting transparency to 0 is actually
> the
> >>> >>> recommended way to remove it from the visual scene hierarchy).
> >>> >>>
> >>> >>> But I think you're right, and that Peter should probably do that
> >>> >>> instead, or otherwise make sure his old parent is created
> >>> >>> dynamically.
> >>> >>>
> >>> >>> In any case, I tried
> >>> >>>
> >>> >>> newParent.data.push(target);
> >>> >>>
> >>> >>> and it seems to work, the blue rect remains. But I realize now that
> >>> >>> .push is not documented in Qt 5 documentation
> >>> >>> (http://doc.qt.io/qt-5/qml-list.html) so perhaps this is not
> >>> >>> guaranteed to be supported. In the old 4.x docs, it says there are
> >>> >>> limitations on .push (it'll only create a new list, not modify an
> >>> >>> existing, but don't know if this holds for 5.x).
> >>> >>>
> >>> >>> Elvis
> >>> >>>
> >>> >>> >
> >>> >>> > On 20 Dec 2015, at 17:02, Elvis Stansvik <elvst...@gmail.com>
> >>> >>> > wrote:
> >>> >>> >
> >>> >>> > Elvis
> >>> >>> >
> >>> >>> >
> >>> >>> _______________________________________________
> >>> >>> Interest mailing list
> >>> >>> Interest@qt-project.org
> >>> >>> http://lists.qt-project.org/mailman/listinfo/interest
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Interest mailing list
> >>> > Interest@qt-project.org
> >>> > http://lists.qt-project.org/mailman/listinfo/interest
> >>> >
> >>
> >>
> >
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
