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
(Geo)Group behavior changes #2759
base: main
Are you sure you want to change the base?
Conversation
3f25965
to
d7e4996
Compare
3d73812
to
d7701d0
Compare
d7701d0
to
8dae676
Compare
5b0aad5
to
658ed53
Compare
Hi, I'd like to test this, as is supposedly fixes a rather important issue in Arch. (Easy to work around but very confusing to new people.) Can you rebase and resolve the merge conflicts? |
Done. Please try. |
Hi @realthunder, I'm seeing an issue that I believe is related to this PR: This PR is the only change I have on top of master, so I guess it is responsible. |
Is it possible to attach a file showing the problem? |
Github tells me "We don't support that file type" for an .FCStd, so I have renamed it to .zip, but it is utterly trivial anyway: Just an empty file with a single wall. |
The problem is caused by not fixing direction of the line segment in WallTrace. It behaves the same in upstream. |
BTW, ArchWall is not a group. So this patch shouldn't have any effect on it. It is more relevant to ArchBuildingPart, I guess. |
That's strange, I never saw this before. I need to compile current master again ... |
I have used this branch now for a all my work for a full month. I can confirm that it fixes a nasty problem for the Arch WB. I didn't run into any regressions. I'm switching back to master now, as the branches have conflicts again and it is unlikely that my testing will uncover any regressions in the future. I'm sorry that I don't have the insight into the code base to do a code review, but I'm looking forward to when this gets merged. |
link to the forum post with the nasty bug described ... link to this PR as a fix: |
Is there a blocking issue with this PR ? Not sure why we don't merge (after rebase/resolve) |
src/App/GroupExtension.cpp
Outdated
} | ||
} | ||
} | ||
|
||
App::Extension::extensionOnChanged(p); | ||
} | ||
|
||
void GroupExtension::slotChildChanged(const DocumentObject &obj, const Property &prop) { | ||
if(&prop == &obj.Visibility && !_togglingVisibility) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading this code, I wonder: Shouldn't this &prop == &obj.Visibility
be kept? I'm not entirely sure, but it looks like the below handler only has code for when a child's visibility changes? Or is this changed handler somehow limited to only Visibility changes now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is limited to Visibility. A new signalChanged has been added to every property. This slotChildChanged
is now hooked to child objects' Visibility.signalChanged
, so no need to check for property anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see it was in an earlier commit (57e2164), I was looking just in the same commit. Ok, looks good, thanks for clarifying!
} | ||
} | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like these helpers, great for readability of the other code. However, I would personally put these helpers, along with modifications to use them in existing code, in a separate commit, which would then make no functional changes, just optimize the existing code, making both resulting commits easier to review. It's of course not up to me and I believe that the form/separation of these PRs has already been discussed a lot, but just wanted to add my 2c here :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Following a link to the branch on the CI-repository: https://gitlab.com/freecad/FreeCAD-CI/-/commits/PR_2759 The CI-status is available on the latest commit of the branch. https://gitlab.com/freecad/FreeCAD-CI/-/pipelines?scope=branches |
Would it be possible to rebase on latest Master? Cheers bernd |
Yes, sure. I'll rebase all of my PRs. But since there are quite a few of them. It'll take some time. |
can you please rebase to merge the PR? approved once by @yorikvanhavre . |
Will this PR become part of the planned Toponaming inclusion branch? |
@realthunder pinging for rebase as I think it's a very interesting PR. Thanks ! :) |
PR suspended for now, and will resume after topo naming merge. |
Is this PR also ready to be resumed after the recent toponaming merges? |
Thess patches are split out from #2723
Please refer to this post for description of group changes.