-
Notifications
You must be signed in to change notification settings - Fork 635
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
Python template support #8034
Python template support #8034
Conversation
- introduced code regions - moved class properties to appropriate regions - fixed a few summary annotations to make it clearer what they do/return and adhere to Microsoft standards a bit better
- added public property to class for PythonTemplateFilePath - added default value in the Settings constructor
- builds fine - creates the correct python template file path - serialises it to XML file fine
Implemented support for the file path, following the model of the PreferencesFilePath.
- when adding a Python node, the template is read - added conditional load & fallback on hardcoded text if template is not found - replaced "\n" with `Environment.NewLine` in hardcoded template - added new comment lines to default template, using Resources to make it easier for beginners - fixed typo in existing Resources & XAML
Sterling work and this is a great addition. I have a small comment; Instead of the location being hard coded as being in a user location, could this location not be set from within the Dynamosettings.xml file. If not filled in or used it will go back to default location? This will allow companies to have a central location for company standards that includes this python template and dynamo template. |
Thanks @brencass ! Really good suggestion - that's what i had in mind too and this PR does indeed store and read the location in the If someone a bit more familiar with the codebase ( @ke-yu, @QilongTang , @mjkkirschner ) can weight in and point me in the right direction, i can connect the 2 dots as originally intended. |
it also propagates changes made to settings in Dynamo
- renamed static prop to PublicPreferenceSettings, essentially adding `Public` in front of existing field - added lines to update the static prop where the `PreferenceSettings` gets updated in the model - set static prop to be public GET, private SET - tested with build, changes are picked up by Python nodes just fine
added public Static preferences
- added an extra spacing line - changed back the default output so newly added Python node does not throw an exception due to missing variable `yourOutputVariableHere`
added spaces after `#` Python comment marker
Ok, so I implemented requested change by @brencass above and aligned it to what I originally envisioned. New behaviour
Python template file in external editor :
ImplementationAdded a The property should be thread-safe as it's read-only :
Also added behaviour to update the static property whenever the instance-based Tested by
Notes :
|
@radumg - We have a meeting to review this today. Will discuss with the team and get back to you. |
@radumg - After review with the team, we want to consider other approaches than changing DynamoModel. @mjkkirschner will follow-up with some suggestions to think about. Additionally, we noticed that your PRs were made against the 1.3.1 Release Candidate. In order for your changes to appear in the next stable release of Dynamo, please make a PR against master. |
Thank you @Racel for the feedback and quick reply 🎉 ! As for the PR branches, my bad : I assumed |
@mjkkirschner , in anticipation of your suggestions : my initial instinct was to turn the PreferenceSettings class to This is obviously a significant departure from current approach & also a UX question, so i await instructions on what you think will be best. |
@radumg so here are some alternatives I have not given much thought 😉 .
In general, I think adding more properties to DynamoModel is not great as it's already a giant class, so I'd rather if we have to that we add it somewhere specific. let us know what you think of those. |
hi @mjkkirschner , thanks for all the options above! And sorry for the delay in replying, we've been busy organising the latest UK Dynamo User Group meeting last week. Options feedbackIn terms of the options, my notes on them would be : from python node raise an event
a static property on the PreferencesSettings class instead of DynamoModel
a static property added to Dynamo services Python Node customization Suggested optionsThat would leave us I think with 3 main options :
I'd gravitate towards Still requires the answer to my question above
Let me know which option you want me to go for, Cheers, Radu |
@radumg sorry for the delay here. |
@radumg to clarify: |
/// Full path to the python template py file. This setting file is specific | ||
/// to the current user. | ||
/// </summary> | ||
string PythonTemplateFilePath { get; } |
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.
because you are changing the interface here you may need to update: https://github.com/DynamoDS/DynamoRevit/blob/Revit2017/src/DynamoRevit/RevitPathResolver.cs
in a related PR to avoid breaking the Revit build.
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.
Thanks @mjkkirschner , was definitely not aware of Dynamo Revit was implementing its own class from this interface. Will try and keep an eye out for that in the future.
@@ -304,6 +322,8 @@ public PreferenceSettings() | |||
ShowDetailedLayout = true; | |||
NamespacesToExcludeFromLibrary = new List<string>(); | |||
|
|||
PythonTemplateFilePath = new PathManager(new PathManagerParams()).PythonTemplateFilePath; |
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've not investigated far enough to know, but do you actually need to create a new path manager just to pull this property out, don't we create a pathmanager somewhere else during dynamoModel initialization?
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.
Will investigate further but from what I remember, there wasn't a mechanism to get to the DynamoModel.
@@ -45,7 +45,7 @@ | |||
// to distinguish one build from another. AssemblyFileVersion is specified | |||
// in AssemblyVersionInfo.cs so that it can be easily incremented by the | |||
// automated build process. | |||
[assembly: AssemblyVersion("1.3.1.1514")] | |||
[assembly: AssemblyVersion("1.3.1.1977")] |
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 think you should send future PRs to master - and no need to commit this file, its auto generated.
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.
Will do 👍 I originally based this one off the 1.3.1
branch thinking that would be the next release (it wasn't out yet). Maybe it would be a good idea to add to the wiki a bit about git branch management and how the team uses them, which one is current/release/etc ? I remember first PR I did was highly confusing how it was cherry-picked when merged etc.
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.
Dug around...can't figure out why this file was included, it's in the .gitignore
for the repo, which is what my cloned version uses too.
Thanks for catching it, I'll exclude from future PRs.
Thanks @mjkkirschner for the detailed feedback & review, will get working on that option asap 👍 FYI, I had a working version of the static Quick question : when is the team aiming to finish round of PR merges for next release ? I would like to get this one (should be ready this weekend) in there but also the next one which will look at support for |
gets rid of un-necessary initialisation of new `PreferenceSettings` or `PathManager` classes, see DynamoDS#8034 (review)
created a new PR #8122 based on |
actually gets rid of un-necessary initialisation of new `PreferenceSettings` or `PathManager` classes, see DynamoDS#8034 (review) forgot the PathManager in last commit.
gets rid of un-necessary initialisation of new `PreferenceSettings` or `PathManager` classes, see DynamoDS/Dynamo#8034 (review)
actually gets rid of un-necessary initialisation of new `PreferenceSettings` or `PathManager` classes, see DynamoDS/Dynamo#8034 (review) forgot the PathManager in last commit.
Purpose
This PR fixes #7604 , wish for adding a Python template that can be used to populate any
Python Script
nodes when adding to workspace.Current behaviour
Python Script
node to canvasNew behaviour
Python Script
node to canvasPythonTemplate.py
file exists at the user location root (%appdata%/Dynamo/Core/{version}/
) and if it does, it reads the file and populates the Python script node with its contentsThis allows users and organisations to rollout the template as part of users profiles or as logon scripts.
Implementation
PreferenceSettings
class to include code regions, moving properties into their logical group, also fixing some comments/documentation at same time, making it clearer.PythonTemplateFilePath
property in the settings class so it serialises and deserialises with user settingsIPreferences
,IPathResolver
andPathManager
class\n
with .NET standardEnvironment.NewLine
line breaks, should behave more predictably when compiled on different platformsLimitations
DynamoSettings.XML
file itself. Since the interfaces implement the property, it can be exposed via UI in later PRDynamoModel
instance from thePythonNodeModel
class to retrieve current settings, so the template is read every time aPython Script
node is added to canvas. Would welcome some pointers here as both the Dynamo API documentation and the class annotations are lackluster. Would've expected either a static class or some public methods that expose this.Declarations
*.resx
filesReviewers
@kronz
@mjkkirschner
@QilongTang
FYIs
@ksobon , @ThomasMahon, @wynged , @eibre , @andydandy74