Dynamo 2.0 new look

Dear Dynamo Team

I hope that you will reconsider the new look that split node names automatically by dots (.), it is fairly annoying. Why don’t keep the old way, where you can give the “category” at the end of the first line in the node definition? (example from a node -> Category=“DanEDU Dynamo.Core”)

dynamo 2.0

dynamo 1.3

1 Like

I have to come with this confession. As stated earlier I was not that pleased with the new look and feel in Dynamo 2.0, but after I have converted my package into a zero-touch package am I really pleased about the look and feel of Dynamo 2.0.
Although I still think that there is a huge missing in a node doesn’t show which package it comes from, but that is another discussion.

The original problem that dots are being used as a separator can actually be turned into something very useful but it has the backside that packages needs to be maintained as 1.3.x packages or 2.0.x packages, which I have found a solution for as well.
That means that my package Orchid in the Dynamo 2.0.x version has a look so those few custom nodes left there isn’t converted looks like the zero-touch nodes.

Thanks a lot for the new look and feel after all :slight_smile:

4 Likes

@erfajo thanks for the updated feedback. I agree 100% on the nodes not containing information on the package they are from. It becomes slightly tricky with dependent packages. But I think a first improvement would be to include the full name of the node along with the display name on the node UI. (including namespace or assembly etc)

I think some of this work could be solved with extensions because they can adapt much faster than dynamo core itself.

I built a very simple sketch of this functionality as an extension here:

(this adds the full function signature of the node to it’s ui)

I believe the largest missing component to the package manager today is top level package.json files for dynamo home graphs (.dyn files) so that a graph describes its dependent packages, just like a solution in .net or a node javascript project using the node PackageManager (npm). These both have top level package files, unfortunately dynamo does not currently support this OOTB. This could be a very useful extension.

2 Likes

Thanks, @Michael_Kirschner2 I will look into what you have been doing.

Just to clarify what the problem is. If you get a graph from the forum, a colleague, old graphs, or even your own old graphs, then you might not have the proper packages installed anymore. In those cases you will get no help at all. That’s why I suggested that the name of the package should be contained in the node graphically. That would help the uses a lot.

Unfortunately has this topic not being prioritized, so users are still having this problem.


1 Like

@Michael_Kirschner2
I did test your sample, and it works very well… as long as I have the package installed. If I removed it and reopened the dynamo graph, the I ended having an unresolved node. This is why I have asked for the node to include the package name in the graphics… Since the node name always is being kept, i think it would be easy to include the assembly name as well (see my previous posted links).

image
vs.
test

hmm, indeed this information needs to get serialized somewhere to actually be useful.
One limitation of the extensions framework in dynamo today, is that there is no API for saving data into the .dyn file from an extension. (something we have in the backlog)

I think currently lets say to implement something like this as an extension (not in core) one could save the information to an extra file on save which contains information on loaded (or used) packages at the time the graph was saved, and could group the nodes by their package. When the graph is loaded if that extra file is found that information can be repopulated.

something like this:

dynamoHomePackage.json
{

package1:{
version:xxx
url:dynamopackges.com/123 or GitHub.com/xyz
nodesInGraph:[
id1,id2,id3]
}

package2:{
version:xxx
url:dynamopackges.com/123 or GitHub.com/xyz
nodesInGraph:[
id4,id5,id6]
}

}

One problem with changing the main file format at this time is backwards compatibility issues, also speed of release. This is something I hope to look at in the near future.

I tried to address this as important in the 2.0 roadmap. I am convinced that it would have been doable to include this as a placeholder back then and coded later as an update option in the tight schedule for the 2.0 release… now it is far more problematic.

I think as you, that taking advantages of the JSON file and read information from that would indeed be a solution. That would also have worked in the old XML format. Store the information about the package as one of the information about a node, and let the graph read this information for the individual node. This can be done in the opening session. If the graph is being activated from the Player, then it don’t needs to read this.

Your idea that it could be the package there was written into the graph is also brilliant, and hold a url is really a good idea… then it could be a kind of “nuget” package or “pip” installer. Press restore/install, and the needed package was installed.

I like it, please go ahead :slight_smile:

Would this also solve the node name changes as well? If I had a dollar for every time I had to replace a few dozen nodes in a graph because someone changed a name…

More or less. Yes it would… if there was a package written in the graph, and the package was missing, then it could install it automatically… or the user could be warned about the missing :slight_smile:

There could be issues with versions, but come on… lets test it I am on :slight_smile:

Renaming depends… Custom nodes is recognized by guid, so this is no problem. Zero-touch is by name and namespace… that cant be fixed unless the author includes a migrate information.

example for Zero-touch “renaming”
image

1 Like

Which means it would depend on how it was renamed, right?

Zero touch was the usual offender (and the harder to find as you can’t right click to get package info even when you have them installed).

No, not at all, you can name it exactly as you please, and rename it endlessly that doesn’t matter. What matters is the guid. So if an author wants to rename and by accident makes a new node coping the content from the old node, then everything is broken. Nothing can be done in those cases.

If it is only renaming the custom node, then you might need to “refresh” the node, that can be done by right-click “Edit Custom Node Properties”, press ok and the node should be “updated”

I have renamed my custom nodes dozens of times, no one has complained about that.

Zero-touch is a completely other ball game. Here is everything serialized into the dynamic library that is being loaded, which means that renaming is becoming something very different.

I am currently working on an update where I split my nodes into those that are Revit dependent and those there are not. This is to support the normal Dynamo and the standalone Dynamo versions. This will come with a price since I have to make two different superior namespaces (Orchid -> OrchidRevit and OrchidCore).

Said in another way, I have to choose if I will let the users put in new nodes so they are correct, or I will help them by setting up the migration but then remaining them as incorrect. Hard choice :-S