Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix removing watching for file modifications #965

Open
wants to merge 3 commits into
base: 5.8
Choose a base branch
from

Conversation

dfries
Copy link

@dfries dfries commented Sep 3, 2024

Description

This depends on (and contains the commits) for pull request Ultimaker/Urandium#964.

If the file is no longer part of the scene graph no longer watch it
for file modifications. This had been triggered from MeshData when it
was deleted, but _application was no longer populated so it was not
being called.

_application could be replaced by querying the current instance.

from UM.Application import Application
Application.getInstance().getController().getScene().removeWatchedFile(self._file_name)

The problem with calling removeWatchedFile from MeshData __del__, is
Cura 5.8.1 is creating three MeshData objects with the file name
populated, when the file is loaded, two are deleted, the last stays
around. If it were to call from the first two objects being deleted,
it would remove the watch even though it is loaded as part of the
scene. Further I'm seeing that the last object isn't getting deleted,
even when it is removed from the scene graph. I don't know if this is
a memory leak or if there would still be an issue with undo/redo.

Instead listen for the scene graph meshDataChanged signal, collect the
files in the scene graph and add or remove based on that list. This
does not listen to sceneChanged signal as that includes transform
changes, which won't change the set of files listened for.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

  • Tested with multiple models loaded, being deleted, undo/redo, and added debugging to print the list of files that are watched for in _updateWatchedFiles, to verify they match the file list and what is loaded in the scene graph.

Test Configuration:

  • Operating System: Debian Linux

Checklist:

When all files are being reloaded, the file modification reload
dialog is redundant.  This allows pressing F5 to reload and dismiss
the dialog.
They all take the same parameter and it his the SceneNode object to be
more specific.
If the file is no longer part of the scene graph no longer watch it
for file modifications.  This had been triggered from MeshData when it
was deleted, but _application was no longer populated so it was not
being called.

_application could be replaced by querying the current instance.
from UM.Application import Application
Application.getInstance().getController().getScene().removeWatchedFile(self._file_name)

The problem with calling removeWatchedFile from MeshData __del__, is
Cura 5.8.1 is creating three MeshData objects with the file name
populated, when the file is loaded, two are deleted, the last stays
around.  If it were to call from the first two objects being deleted,
it would remove the watch even though it is loaded as part of the
scene.  Further I'm seeing that the last object isn't getting deleted,
even when it is removed from the scene graph.  I don't know if this is
a memory leak or if there would still be an issue with undo/redo.

Instead listen for the scene graph meshDataChanged signal, collect the
files in the scene graph and add or remove based on that list.  This
does not listen to sceneChanged signal as that includes transform
changes, which won't change the set of files listened for.
@github-actions github-actions bot added the PR: Community Contribution 👑 Community Contribution PR's label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: Community Contribution 👑 Community Contribution PR's
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant