What You See Is What You Get API code displayer? Kind-of-anyway?

[Anonymous]

It is rather painstaking to use any API. What if trips to the manuals could be avoided when you need a API example quickly, pertinent to your current needs?

Could there be a way to push "API code blocks" into a text window as one builds manually in Fusion, like a "what you see is what you get" interface common in html editors? Even if it only showed static example code (in an early release version), that could provide timely examples the user could use right away.

The next level perhaps would be to show live API code directly which more perfectly equates to the last user action, complete with arguments filled in.

Is there enough information flowing by within the API events (and related event arguments) to reconstruct a 3d model from a "recording" of a user manually building it? This could be a way to drive such a thing, if the available data within the events that fire is complete enough to re-purpose for recording actions and values related to those actions, passed as arguments.

Such a window could have one tab for each language like the user manual for the API. As the user draws stuff and applies constraints, etc, the equivalent code is displayed or accumulated in the window, complete with arguments filled in, etc.

A fancier version would show the code needed to drill down into the api and set all the objects along the way. This code could be a different color, or on a unique visibility layer, than the code directly related to the user action, to reduce confusion.

API code could be grouped into blocks which correlate with the undo list, with means of suppressing various code, etc. Like show the meat of a call, not all the supporting code. Or the opposite, etc.

Event-driven code, like user pressed button or entered data, could also be shown below the original code but grouped separately.

This feels almost like an MS Excel "macro" kind of widget, but also shows the equivalent API code, as described above in one form or another.

I suspect even expert API users would appreciate being able to make API code examples on the fly by manually drawing what they want to draw, and copying the code snippets into their script, rather than trudging through a large API hierarchy manual. Instead, most API functionality could be explained and/or demonstrated to the user on an optional side window, as they manually perform actions in Fusion 360 the normal way.

To get started, a first version could merely echo the syntax hints and maybe code examples the user would find in the API user manual. This would also be a good way to organize code examples in context to the normal Fusion 360 user interface, as opposed to buried somewhere in a separate manual.

This kind of functionality would dramatically speed up use and learning of the API for everyone.

[Anonymous]

I asked this here to see if this could be done (at least to some extent) using a script itself. If an add-in can run in the background and watch events and see the arguments that were passed into Fusion 360 by the user, then one could derive the API call related to the event and display it somewhere else, as Fusion 360 is used in the usual (manual) way. That's why I said it's almost like macros, but also by checking a checkbox or running an add-in in the background, it can display the API code (or at least a basic static example from the manual, etc) in a side window, with the displayed code equivalent to what was just done manually by the user, and context driven help or samples could be another click away so the extra background activity of driving this dosen't bog down the system.

I don't know the limitations of an add-in watching Fusion 360 for user commands and related events. Could it see them? Would it be able to get the values passed in too? If not, is there (or could it be added) a "balcony" which can view the events overall and parse them into something meaningful enough to record a macro or drive a lookup table to display code and/or context-related info? Maybe the do/undo stack has this data already, and/or the timeline for the higher view?

My intention was to perfect this idea here, then I can post a more polished version of it in the Fusion 360 Idea Station, targeting the most likely approaches. I would like to do it in a script, but maybe it won't work until some future feature or API extention is available.

[ekinsb · Accepted solution]

I completely agree that something like this would be extremely useful for everyone.  However, it's not a trivial thing to do and certainly is not possible today using the API because there isn't enough information available to the add-in about what's happening in the Fusion session.

An alternative that I think might possible with the existing functionality, (at least in a prototype form), is instead of watching the construction as the user uses Fusion is to examine a finished model and then create the code that will reconstruct the model. The API provides the ability to query the model and then you can create a program that uses the create portion of the API.

[Anonymous]

Reverse engineering an existing model to generate code sounds promising, but depending on the granularity of the information that can be gleaned from the API reading the model's objects, etc.

I guess you mean that the step-by-step method of how a model was made, the "recipe", is contained within the model's objects, AND these details can mostly be gleaned from it via the API? As opposed to say, a sketchup or direct modeling kind of thing, which is merely the end result of a bunch of steps that cannot be pieced back together because the model only contains an accumulation of all things done to it in a mesh, etc?

Is the recipe contained in a list, like a functions with arguments, listed one after another, or do I have to traverse a huge object hierarchy tree to gather up the details, or a little of both?

Am I likely to run into cases where it may be ambiguous as to what order drawing actions, etc were originally done in, aside from direct modeling? Or is it normal for this to be clearly spelled out in the "timeline(s)" of the model?

I am new to this kind of parametric cad beast, but it I kind of remember that of the central tenants of it is that it is inherently structured step-by-step by definition?

I  am assuming the direct models could not be reverse-engineered in the manner you suggest via the API because they don't have such a recipe-based history contained within them, only the resulting mesh, etc?

I will have a look at that part of the API. If you could clarify what section(s) or pointers to specific examples traversing a model for a model's "recipe" or elements extraction, that would be useful.

Thanks, I will research and toy with some of the calls to read a Fusion model's "recipe". If I can get traction, I will post some examples myself. I am brand new to this API and Python, so it may be a while. But I have gotten a bunch of tutorial samples and other code to run. I guess the hard part, ironically, is doing what my suggestion would help with, finding the right code snippets so I can play with them.

I guess I need help finding the step-by-step list Fusion uses when it opens a new project and re-draws the model, if one exists. What am I looking for, and what part of the API contains it? Or phrased another way, can you offer some pointers on how to read an open model using the API and extract the essential step-by-step info on how to re-build it? Even a simple example would go a long way I think. I don't know the first door to knock on, let alone the second, lol.

[Anonymous]

I am looking around the API thinking about a viable strategy for extracting the steps used to make a model, from the model.

In general, would I begin by traversing the timeline from beginning to end, and traverse the object tree of each object found?

Are most of the original geometry "arguments" applied to the model by the user still accessible from the model via the API, like the length of a line, the diameter of a circle, type and distance of an extrusion, etc?

I am trying to come up with a really basic strategy, like what my outer loop would do, and maybe the first inner loop or two. Once I can collect the needed information, then the rest is mostly grudge work making it translate what was collected into useful things that show up on another window or browser.

[Anonymous]

I ran the following python script (very minimal example) and it showed the main object types contained within the timeline, one after the other in a message box:

#Description-Extracts some useful info from the timeline

# some Fusion code to drill down into the parts of the API we need to access:
import adsk.core, adsk.fusion

ui = None

app = adsk.core.Application.get()
ui = app.userInterface

design = app.activeProduct

# Get the root component of the active design.
rootComp = design.rootComponent

timeline = design.timeline

for obj in timeline:
    ui.messageBox(obj.entity.objectType)

I also looked at the Assembly traversal using recursion API Sample, and maybe I could use a similiar loop structure for traversing the objects inside the timeline. But I want to start with a simple framework, leaving assemblies for later. And maybe that example is not enough, because I need to flatten a tree that contains many different levels and a different object type at each level. Hmmm.