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

Create tree #110

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Create tree #110

wants to merge 5 commits into from

Conversation

hbcarlos
Copy link
Contributor

@hbcarlos hbcarlos commented Feb 1, 2023

Fixes #31

Grabacion.de.pantalla.2023-02-03.a.las.17.31.37.mov

@hbcarlos hbcarlos added the bug label Feb 1, 2023
@hbcarlos hbcarlos self-assigned this Feb 1, 2023
@hbcarlos hbcarlos marked this pull request as draft February 1, 2023 22:21
@github-actions
Copy link
Contributor

github-actions bot commented Feb 1, 2023

Binder 👈 Launch a Binder on branch hbcarlos/jupytercad/fix_31

@hbcarlos
Copy link
Contributor Author

hbcarlos commented Feb 6, 2023

There is not an easy solution to this issue. I looked into the format but couldn't find a pattern to detect groups easily.

From what I saw, depending on the object's type, a different attribute indicates whether it has a child.

@martinRenou
Copy link
Member

martinRenou commented Feb 8, 2023

I've been looking into the case of the ArchDetail.FCSTD example. I understand there that the tree could be created with the ObjectDeps xml tags.

For example, when opening that file with freecad, the wall looks like the following:

Screenshot from 2023-02-08 09-57-35

In the Document.xml file, the wall (labeled "Ground floor wall") could be linked to its children with:

        <ObjectDeps Name="Wall" Count="3">
            <Dep Name="Line"/>
            <Dep Name="Extrusion"/>
            <Dep Name="Extrusion001"/>
        </ObjectDeps>

and e.g. Extrusion001 is linked to Rectangle002 with:

        <ObjectDeps Name="Extrusion001" Count="1">
            <Dep Name="Rectangle002"/>
        </ObjectDeps>

We may miss the objectdeps object information in the front-end, it's something that we may want to populate from the back-end before doing the front-end work.

Looking into this made me think that we could probably use the label instead of the object name for displaying the tree.

@hbcarlos
Copy link
Contributor Author

hbcarlos commented Feb 8, 2023

We may miss the objectdeps object information in the front-end, it's something that we may want to populate from the back-end before doing the front-end work.

I saw that while investigating this issue, but I couldn't figure out how to extract that info using Freecad Python's API.
Once we load the document, we obtain the objects and metadata using the FreeCad python library. I looked into the documentation to find a property|method that returns the object's dependency tree but did not find it.

@martinRenou
Copy link
Member

martinRenou commented Feb 8, 2023

As per https://forum.freecad.org/viewtopic.php?style=5&p=537587

Children are returned by '.ViewObject.claimChildren()' called on the object.
Notice that it only works on GUI mode as tree is just not existing in CLI mode

Meeeeeeh. Stupid GUI mode again.

I guess we are back to the issue I had when trying to load the object colors, where freecad's Python API would just not load the colors information without a GUI mode activated (a QT context basically).
We could fix this by using the hidden sub module https://github.com/FreeCAD/FreeCAD/blob/20dc9d0a61ec1e9b94ac4088e58581229c2adac3/src/Mod/Arch/OfflineRenderingUtils.py#L33 but this one may not load the tree information (the objectdeps).

I suppose our only workaround would be to read the Document.xml ourselves.

@hbcarlos
Copy link
Contributor Author

hbcarlos commented Feb 8, 2023

I suppose our only workaround would be to read the Document.xml ourselves.

If every time we need a GUI feature we need to use the OfflineRenderingUtils (If I recall correctly from past conversations, ¿it means launching the qt-based app?) we should start thinking about reading the document ourself.

@trungleduc
Copy link
Member

trungleduc commented Feb 8, 2023

It looks like the OutList property of an object gives us its list of objects in the ObjectDeps key. They have also OutListRecursive which i think should give us all nested objects

@martinRenou
Copy link
Member

martinRenou commented Feb 9, 2023

If every time we need a GUI feature we need to use the OfflineRenderingUtils (If I recall correctly from past conversations, ¿it means launching the qt-based app?) we should start thinking about reading the document ourself.

Yeah that might make sense at some point... It was kind of convenient for colors because it was written exactly for fetching colors/opacities information.

It looks like the OutList property of an object gives us its list of objects in the ObjectDeps key. They have also OutListRecursive which i think should give us all nested objects

Oh cool! From the forum I posted I thought this was only set when a QT-based app is running.

@martinRenou
Copy link
Member

It looks like the OutList property of an object gives us its list of objects in the ObjectDeps key

Indeed, but it seems that it's not the information freecad uses for creating the tree view.

I think the only way for us to create the same tree view is to use .ViewObject.claimChildren() like suggested in the forum I posted above, which is only available in GUI mode (and the setupWithoutGUI method seems to not populate this).

There is a mention of a FreeCAD branch which would populates the ViewObject properly in non-GUI mode in https://forum.freecad.org/viewtopic.php?p=146746#p146746 but I did not find the branch in question. I posted an answer on the forum, hopefully we can get some guidance from them.

@martinRenou martinRenou removed the bug label Oct 17, 2024
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

Successfully merging this pull request may close these issues.

The tree view of complex objects is not grouped correctly.
3 participants