Re: [Okular-devel] Review Request: Manage annotation objects with QSharedPointers to support future Undo/Redo framework
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106923/#review20514 --- To be honest i don't think this is a good idea. This is poors man solution for i don't know what do to with my memory. Personally i'd like to have a much more defined ownership model for annotations, e.g. annotations that *are* in the page belong to the page and the ones that are not in the page (i.e. they are in the undone actions) belong to whoever holds them (i.e. the actions). This is something similar to what i do in the KTuberling undo/redo actions http://quickgit.kde.org/index.php?p=ktuberling.gita=blobf=action.cpp What do you think of that? - Albert Astals Cid On Oct. 17, 2012, 2:24 a.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106923/ --- (Updated Oct. 17, 2012, 2:24 a.m.) Review request for Okular. Description --- The purpose of this patch is to shift the responsibility for explicitly deleting annotations away from the Page class. Prior to this patch the Page class would explicitly delete an annotations object that was removed from the page. However, in order to eventually support Undoing and Redoing the creation and removal of annotations from a page it is important that the annotation objects are not automatically deleted upon removal. The Page class now stores QSharedPointers to annotations rather than standard pointers. Page::addAnnotation and Document::addPageAnnotation now require a QSharedPointer rather than a standard pointer. The implication is that the deletion of annotation objects is now managed by the QSharedPointer class rather than the Page class. Currently the only QSharedPointer referencing a particular annotation will be the one help by the page class and so the removal of the annotaion from a page will automatically result in the deletion of the annotation object. However, in the future several QUndoCommands may also have QSharedPointer references to the annotation and in this case the annotation will not be deleted until all of those QUndoCommands have been been destroyed. Diffs - core/annotations.cpp 21114af core/document.h d47acec core/document.cpp bddef39 core/page.h a8f2761 core/page.cpp d746382 core/textdocumentgenerator.cpp f370ded generators/djvu/generator_djvu.cpp bc83ed7 generators/poppler/generator_pdf.cpp fcc8dc4 ui/annotationtools.h fdcae1b ui/annotationtools.cpp f2db355 ui/pagepainter.cpp 916a0ab ui/pageviewannotator.cpp 4488639 Diff: http://git.reviewboard.kde.org/r/106923/diff/ Testing --- Added a kDebug() statement to the destructor of the Annotation class. For both annotations loaded from disk and annotations created during the current session the removal of the annotation from a page still results in the destruction of the annotation object (no annotation memory leak). This is the same behavior as before, only now it is accomplished through the use of QSharedPointers rather than an explicit delete call. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
Re: [Okular-devel] Review Request: Manage annotation objects with QSharedPointers to support future Undo/Redo framework
On Oct. 17, 2012, 5:41 p.m., Albert Astals Cid wrote: To be honest i don't think this is a good idea. This is poors man solution for i don't know what do to with my memory. Personally i'd like to have a much more defined ownership model for annotations, e.g. annotations that *are* in the page belong to the page and the ones that are not in the page (i.e. they are in the undone actions) belong to whoever holds them (i.e. the actions). This is something similar to what i do in the KTuberling undo/redo actions http://quickgit.kde.org/index.php?p=ktuberling.gita=blobf=action.cpp What do you think of that? Jon Mease wrote: Thanks for the feedback. I started with the idea of a more defined memory management model. But once I realized that multiple undo command objects will need to reference the same annotation I had trouble envisioning what this model might be. But your implementation in KTuberling makes sense. So the idea is that an annotation would be owned by the createAnnotation command only if it in the 'undone state'. An annotation belongs to the removeAnotation command only if it is in the 'redone state'. Annotations being displayed on the page are owned by the page. And all of the other undo commands that don't create or remove an annotation never have ownership. Does this sound like what you're thinking? Exactly :-) - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106923/#review20514 --- On Oct. 17, 2012, 2:24 a.m., Jon Mease wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106923/ --- (Updated Oct. 17, 2012, 2:24 a.m.) Review request for Okular. Description --- The purpose of this patch is to shift the responsibility for explicitly deleting annotations away from the Page class. Prior to this patch the Page class would explicitly delete an annotations object that was removed from the page. However, in order to eventually support Undoing and Redoing the creation and removal of annotations from a page it is important that the annotation objects are not automatically deleted upon removal. The Page class now stores QSharedPointers to annotations rather than standard pointers. Page::addAnnotation and Document::addPageAnnotation now require a QSharedPointer rather than a standard pointer. The implication is that the deletion of annotation objects is now managed by the QSharedPointer class rather than the Page class. Currently the only QSharedPointer referencing a particular annotation will be the one help by the page class and so the removal of the annotaion from a page will automatically result in the deletion of the annotation object. However, in the future several QUndoCommands may also have QSharedPointer references to the annotation and in this case the annotation will not be deleted until all of those QUndoCommands have been been destroyed. Diffs - core/annotations.cpp 21114af core/document.h d47acec core/document.cpp bddef39 core/page.h a8f2761 core/page.cpp d746382 core/textdocumentgenerator.cpp f370ded generators/djvu/generator_djvu.cpp bc83ed7 generators/poppler/generator_pdf.cpp fcc8dc4 ui/annotationtools.h fdcae1b ui/annotationtools.cpp f2db355 ui/pagepainter.cpp 916a0ab ui/pageviewannotator.cpp 4488639 Diff: http://git.reviewboard.kde.org/r/106923/diff/ Testing --- Added a kDebug() statement to the destructor of the Annotation class. For both annotations loaded from disk and annotations created during the current session the removal of the annotation from a page still results in the destruction of the annotation object (no annotation memory leak). This is the same behavior as before, only now it is accomplished through the use of QSharedPointers rather than an explicit delete call. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] Review Request: Manage annotation objects with QSharedPointers to support future Undo/Redo framework
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106923/ --- Review request for Okular. Description --- The purpose of this patch is to shift the responsibility for explicitly deleting annotations away from the Page class. Prior to this patch the Page class would explicitly delete an annotations object that was removed from the page. However, in order to eventually support Undoing and Redoing the creation and removal of annotations from a page it is important that the annotation objects are not automatically deleted upon removal. The Page class now stores QSharedPointers to annotations rather than standard pointers. Page::addAnnotation and Document::addPageAnnotation now require a QSharedPointer rather than a standard pointer. The implication is that the deletion of annotation objects is now managed by the QSharedPointer class rather than the Page class. Currently the only QSharedPointer referencing a particular annotation will be the one help by the page class and so the removal of the annotaion from a page will automatically result in the deletion of the annotation object. However, in the future several QUndoCommands may also have QSharedPointer references to the annotation and in this case the annotation will not be deleted until all of those QUndoCommands have been been destroyed. Diffs - core/annotations.cpp 21114af core/document.h d47acec core/document.cpp bddef39 core/page.h a8f2761 core/page.cpp d746382 core/textdocumentgenerator.cpp f370ded generators/djvu/generator_djvu.cpp bc83ed7 generators/poppler/generator_pdf.cpp fcc8dc4 ui/annotationtools.h fdcae1b ui/annotationtools.cpp f2db355 ui/pagepainter.cpp 916a0ab ui/pageviewannotator.cpp 4488639 Diff: http://git.reviewboard.kde.org/r/106923/diff/ Testing --- Added a kDebug() statement to the destructor of the Annotation class. For both annotations loaded from disk and annotations created during the current session the removal of the annotation from a page still results in the destruction of the annotation object (no annotation memory leak). This is the same behavior as before, only now it is accomplished through the use of QSharedPointers rather than an explicit delete call. Thanks, Jon Mease ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
