https://bugs.kde.org/show_bug.cgi?id=445119
--- Comment #3 from Robert Hairgrove <c...@roberthairgrove.com> --- I realize now, after looking through the source code and docs for QList and QPointer, that this would not work with signals and slots unless a completely different copying mechanism and/or redesign of UMLObjectList were implemented. Neither QList nor QPointer are descendents of QObject, so they emit no signals. UMLObjectList would most likely have to contain a QList<QPointer<UMLObject>> member instead of inheriting it directly. Read and write operations could be forwarded directly to the QList member, but adding and removing objects (pointers) should be controlled by UMLObjectList. What I can envision now, without knowing all of the details about how this class is used, is the following: 1. Class UMLObjectList should inherit from QObject, or possibly just implement signals and slots using the Q_OBJECT macro; 2. UMLObjectList should connect itself via slot to the "destroyed()" signal of each element added to its list which should only be permitted through its own "append()" function (and removal through a correlated "remove()" function); 3. Whenever a contained element is destroyed, the slot would have to find the pointer in its list and then remove it. Of course, the actual object deletion would be left to QPointer. -- You are receiving this mail because: You are watching all bug changes.
