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

[hydro] disabling a group doesn't disable its children #709

Closed
RainCT opened this issue Jan 17, 2014 · 6 comments
Closed

[hydro] disabling a group doesn't disable its children #709

RainCT opened this issue Jan 17, 2014 · 6 comments
Assignees

Comments

@RainCT
Copy link
Contributor

RainCT commented Jan 17, 2014

After disabling a group, its children are still visible.

@ghost ghost assigned wjwwood Jan 17, 2014
@wjwwood
Copy link
Member

wjwwood commented Jan 17, 2014

I'll look into this.

@RainCT
Copy link
Contributor Author

RainCT commented Feb 4, 2014

Hi wjwwood,

Cool, thanks. Any news on this?

@wjwwood
Copy link
Member

wjwwood commented Feb 4, 2014

I have not, no time yet. I'll try to address it as soon as possible.

@wjwwood wjwwood added this to the untargeted milestone Feb 25, 2014
@forouher
Copy link

forouher commented Mar 5, 2014

This results in a huge memory leak, btw. The children are (partially) disabled, but rviz still seems to collect data on them.

@efernandez
Copy link

Note this is related with #679

RainCT added a commit to RainCT/rviz that referenced this issue Mar 13, 2014
This was broken with commit 5897285, which reverted the changes in
commit c6dacb1, but rather than only removing the change concerning
the read-only attribute, commented out the entire check, including
the parent_->getDisableChildren() call (which existed prior to
commit 5897285).
@RainCT
Copy link
Contributor Author

RainCT commented Mar 13, 2014

Indeed, turns out it's a regression introduced by the fix for #679.

#740 fixes this.

RainCT added a commit to RainCT/rviz that referenced this issue Apr 15, 2014
This was broken with commit 5897285, which reverted the changes in
commit c6dacb1, but rather than only removing the change concerning
the read-only attribute, commented out the entire check, including
the parent_->getDisableChildren() call (which existed prior to
commit 5897285).
wjwwood added a commit that referenced this issue Apr 29, 2014
@wjwwood wjwwood closed this as completed May 1, 2014
wjwwood pushed a commit that referenced this issue May 14, 2014
This was broken with commit 5897285, which reverted the changes in
commit c6dacb1, but rather than only removing the change concerning
the read-only attribute, commented out the entire check, including
the parent_->getDisableChildren() call (which existed prior to
commit 5897285).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants