[Macro] Get an ASCII representation of the model tree

[galou_breizh]

I implemented saving the pattern and the style. There is no need to click on 'Generate' anymore. Please double-check.

FCTree2AsciiUI.FCMacro

(5.05 KiB) Downloaded 52 times

[openBrain]

I implemented saving the pattern and the style. There is no need to click on 'Generate' anymore. Please double-check.

Thanks for that. Actually I don't really like it for several reasons :

• I'm not sure whether macros should authorized themselves to store parameters... But I can trust you on this point
• Parameter will be saved each time the genLine is modified, that's probably stressing the filesystem.
• Tree is updated each time the genLine is modified. That will generate a bunch of errors during writing.

So I prefer to keep the Generate button. Parameters are saved and tree updated only at this time.

Some more remarks :

• Your code actually doesn't save the style. Probably you forgot a line.
• Your way to get default parameter value is a bit strange. The mechanism already exist. For example instead of g_tree_style = p.GetString('TreeStyle') or 'Modern', you can write g_tree_style = p.GetString('TreeStyle', 'Modern')

Attached updated code.

What are your thoughts about that ?

[galou_breizh]

I'm not sure whether macros should authorized themselves to store parameters... But I can trust you on this point

Why not? This is for user-friendliness.

Parameter will be saved each time the genLine is modified, that's probably stressing the filesystem.

I don't think so. The filesystem is able to save 4K videos in realtime.

Tree is updated each time the genLine is modified. That will generate a bunch of errors during writing.[/list]

I added the try: ... except: cause and it was catching most such errors.

So I prefer to keep the Generate button. Parameters are saved and tree updated only at this time.

I'll respect this choice, as the one from the original author.

Your code actually doesn't save the style. Probably you forgot a line.

I indeed did.

Your way to get default parameter value is a bit strange. The mechanism already exist. For example instead of g_tree_style = p.GetString('TreeStyle') or 'Modern', you can write g_tree_style = p.GetString('TreeStyle', 'Modern')

Thanks, your way is better. My way is sometimes used in Python, though it's not a typical construct. I actually use the parameter system seldomly.

I think it's a nice macro. I think you can publish it. I "may" change the style a bit, then...

[openBrain]

Parameter will be saved each time the genLine is modified, that's probably stressing the filesystem.

I don't think so. The filesystem is able to save 4K videos in realtime.

Not mine. Also saving video never write twice the same disk area. My concern is more about overwriting the same area again and again.

Tree is updated each time the genLine is modified. That will generate a bunch of errors during writing.[/list]

I added the try: ... except: cause and it was catching most such errors.

I think I saw that after I wrote.

So I prefer to keep the Generate button. Parameters are saved and tree updated only at this time.

I'll respect this choice, as the one from the original author.

I'd like to have community feedback on that so the majority will lead.

I think it's a nice macro. I think you can publish it. I "may" change the style a bit, then...

Feel free to feedback about coding style before I publish. I sometimes write macros, so better if I conform my coding style to expectations (whether it could be against a standard or specific rules).

[galou_breizh]

I prefer the classical PEP-8 style. The most important in my opinion are good variable names, i.e. style corresponding to the function (class, function, variable, global vs. local, hidden, ...) and an expressive name. I'll have a look when I find the time.

[openBrain]

I prefer the classical PEP-8 style. The most important in my opinion are good variable names, i.e. style corresponding to the function (class, function, variable, global vs. local, hidden, ...) and an expressive name. I'll have a look when I find the time.

Hi galou. Made a reforging about variable casing and all. Should be better (not perfect yet, I can't dare to have same casing for functions & variables, will come ).
Pull request is launched and Macro FCTree2Ascii has been set up.

[galou_breizh]

Integrated, thanks!

[galou_breizh]

I was just thinking about the macro name. What about "TreeToText" rather than "Tree2Ascii". I find "To" nicer than "2" within text and "Text" because this can be Unicode-Art rather than Ascii-Art.

Gaël

[openBrain]

I was just thinking about the macro name. What about "TreeToText" rather than "Tree2Ascii". I find "To" nicer than "2" within text and "Text" because this can be Unicode-Art rather than Ascii-Art.

Actually I like the current name (maybe because I chosen it ). But also I'm afraid that changing the name will be painful about changing the header, the wiki and the whole nine yards... So I'm a bit reticent ATM. But if you feel brave enough to do it, feel free to do so.

Ken tuch'

[Zolko]

Attached is a macro that outputs an ASCII representation of the model tree.
I use it mainly for documenting models, hence the specific line formatting.

I think this is really nice, I have been doing this for a while, but by hand. May I suggest some improvements ?

1) Make the spacing 4 spaces wide (not 3)
2) make the branch ├─ and not ├

Code: Select all

line 38:
    'Modern' : [' ├─ ', ' │  '],  # Unicode U+251C, Unicode U+2502
line 68:
            baselinechi = baseline + '    '

This is trivial and looks a little better. Then there is something more difficult:

3) make the last branch └─ and not ├─

End result would be:

Code: Select all

 └─ Model (Model)
     ├─ Origin (Origin)
     │   ├─ X_Axis (X_Axis)
     │   ├─ Y_Axis (Y_Axis)
     │   ├─ Z_Axis (Z_Axis)
     │   ├─ XY_Plane (XY_Plane)
     │   ├─ XZ_Plane (XZ_Plane)
     │   └─ YZ_Plane (YZ_Plane)
     ├─ LCS_0 (LCS_0)
     ├─ Constraints (Constraints)
     ├─ Variables (Variables)
     ├─ Sketch_master (Sketch_master)
     ├─ LCS_arm (LCS_arm)
     ├─ base (base001)
     │   ├─ Origin001 (Origin001)
     │   │   ├─ X_Axis001 (X_Axis001)
     │   │   ├─ Y_Axis001 (Y_Axis001)
     │   │   ├─ Z_Axis001 (Z_Axis001)
     │   │   ├─ XY_Plane001 (XY_Plane001)
     │   │   ├─ XZ_Plane001 (XZ_Plane001)
     │   │   └─ YZ_Plane001 (YZ_Plane001)
     │   ├─ LCS_1 (LCS_1)
     │   └─ Body (Body)
     │       ├─ Origin004 (Origin004)
     │       │   ├─ X_Axis004 (X_Axis004)
     │       │   ├─ Y_Axis004 (Y_Axis004)
     │       │   ├─ Z_Axis004 (Z_Axis004)
     │       │   ├─ XY_Plane004 (XY_Plane004)
     │       │   ├─ XZ_Plane004 (XZ_Plane004)
     │       │   └─ YZ_Plane004 (YZ_Plane004)
     │       ├─ Pad (Pad)
     │       │   └─ Sketch (Sketch)
     │       ├─ Pad001 (Pad001)
     │       │   └─ Sketch001 (Sketch001)

4) if Label and Name are identical, it's useless to print both (it's actual harmful, because it removes the information that the object has NOT been renamed). And according to the Selection View, they output Name (Label), the reverse of this macro.