Skip to content

Conversation

@ivaylo-matov
Copy link
Contributor

@ivaylo-matov ivaylo-matov commented Mar 4, 2025

Purpose

This PR addresses DYN-7874. It adds a new preference setting to enable | disable the default description text for groups. Previously, users had to manually delete the default text each time they created a group. Now, they can toggle this behavior in Preferences.

Key Changes:

  • Added ShowDefaultGroupDescription setting in PreferenceSettings.cs.
  • Added a ToggleButton in PreferencesView.xaml to control the setting.
  • Updated AnnotationTextConverter to check the state of ShowDefaultGroupDescription. If ShowDefaultGroupDescription==true && AnnotationDescriptionText == GroupDefaultsText, it passes string.Empty intead of the actual value of AnnotationDescriptionText .

DYN-7874-Proposal_3_English

DYN-7874-Proposal_3_Spanish

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated
  • This PR contains no files larger than 50 MB

Release Notes

This PR adds a new preference setting to enable | disable the default description text for groups. Previously, users had to manually delete the default text each time they created a group. Now, they can toggle this behavior in Preferences.

Reviewers

@QilongTang
@reddyashish

FYIs

@dnenov
@achintyabhat

@github-actions github-actions bot changed the title [DUN-7874] As a Dynamo user I do not want the default group description text DYN-: [DUN-7874] As a Dynamo user I do not want the default group description text Mar 4, 2025
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-7874

@ivaylo-matov ivaylo-matov changed the title DYN-: [DUN-7874] As a Dynamo user I do not want the default group description text [DYN-7874] As a Dynamo user I do not want the default group description text Mar 4, 2025
@ivaylo-matov
Copy link
Contributor Author

ivaylo-matov commented Mar 4, 2025

aware of the failed build. resolving now

Copy link
Contributor

@reddyashish reddyashish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, need to resolve conflicts.

@johnpierson
Copy link
Member

johnpierson commented Mar 4, 2025

First, I like this idea quite a bit as descriptions are often not required.

however, this is causing what I feel is a regression in user experience. If a user went through the effort of removing these descriptions in a previous version, they are now surfacing when a file from a previous version of Dynamo is opened in this dev version with "Use Default Description" enabled. And often times users will remove descriptions from some groups, but not all groups.

This will surely tick off some users.

is there a requirement for this to modify existing groups in a file that has been opened? If so, I would lean toward prompting the user before changing the groups for them.

cc @jnealb

image

@reddyashish
Copy link
Contributor

One test failing: [Dynamo.Tests.Configuration.PreferenceSettingsTests.TestImportCopySettings]

@reddyashish
Copy link
Contributor

reddyashish commented Mar 4, 2025

First, I like this idea quite a bit as descriptions are often not required.

however, this is causing what I feel is a regression in user experience. If a user went through the effort of removing these descriptions in a previous version, they are now surfacing when a file from a previous version of Dynamo is opened in this dev version with "Use Default Description" enabled. And often times users will remove descriptions from some groups, but not all groups.

This will surely tick off some users.

is there a requirement for this to modify existing groups in a file that has been opened? If so, I would lean toward prompting the user before changing the groups for them.

cc @jnealb

image

In that case, we can make this change only for newly created groups and i think that would be ideal for all. @achintyabhat @hwahlstrom What do you think?

@johnpierson
Copy link
Member

Also, this feature does not work accross different languages currently.

Created graph in spanish dynamo, opened in english dynamo, toggled the setting.

image
image

/// <param name="showDefault">Whether to apply the default description or clear it.</param>
public void ApplyAnnotationDescriptionSetting(bool showDefault)
{
foreach (var workspace in Model.Workspaces)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a user has a custom node (dyf) open in the background, this will modify groups within the custom node resulting in a node that has been edited.
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ivaylo-matov In this case, we want to check for groups only in the homeworkspace?

Copy link
Contributor Author

@ivaylo-matov ivaylo-matov Mar 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reddyashish , my understanding was that the problem was in marking the cunstom node as modified and not removing the group description from it in principle. This should be addressed now. I think the idea is to remove (tunr off) the descriptions consistently in every workspace. Hope that makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So your changes won't remove the group description in the custom node workspace? Confused when you say every workspace as only one homeworkspace will be opened at one time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

apologies if my explanation was unclear

If we have one graph open along with a couple of custom nodes, Model.Workspaces will return three items:

  • 1x HomeWorkspaceModel
  • 2x CustomNodeWorkspaceModels

When a user turns off the default group description in Preferences, Dynamo will:

  • Apply this change to both the open graph and the two custom nodes.
  • Ensure that default group descriptions are disabled everywhere, so that everuthing is consistent.
  • Prevent a situation where the main graph (HomeWorkspaceModel) hides the default group description, while custom nodes (CustomNodeWorkspaceModels) still display it.

The purpose of RefreshAnnotationDescriptions() is not to remove the description value. Instead, it reassigns the same description to each group, triggering RaisePropertyChanged().

This allows AnnotationTextConverter to detect the change and update the group view by setting the description to string.Empty.

@hwahlstrom
Copy link
Collaborator

First, I like this idea quite a bit as descriptions are often not required.
however, this is causing what I feel is a regression in user experience. If a user went through the effort of removing these descriptions in a previous version, they are now surfacing when a file from a previous version of Dynamo is opened in this dev version with "Use Default Description" enabled. And often times users will remove descriptions from some groups, but not all groups.
This will surely tick off some users.
is there a requirement for this to modify existing groups in a file that has been opened? If so, I would lean toward prompting the user before changing the groups for them.
cc @jnealb
image

In that case, we can make this change only for newly created groups and i think that would be ideal for all. @achintyabhat @hwahlstrom What do you think?

I agree, make it apply to newly created groups only. Would that resolve the issue, @johnpierson ?

@ivaylo-matov
Copy link
Contributor Author

ivaylo-matov commented Mar 5, 2025

Thanks for the feedback @johnpierson .
I might have a solution for two of the points:

DYN-7874-JP_Comments

How do you test wilt different languages? Does not seem to work completely on the builds. If I chage the language only a few of the button will be translated and the new groups will have default text in EN.
For example, CultureInfo.CurrentUICulture.Name will return es-ES ,but Resources.ResourceManager.GetString("GroupDefaultText", CultureInfo.CurrentUICulture) will return the text in EN 🤨

Screenshot 2025-03-05 103942
Screenshot 2025-03-05 104048

@johnpierson
Copy link
Member

johnpierson commented Mar 5, 2025

@hwahlstrom that would work for me! New groups only.

@ivaylo-matov - I couldn't get the sandbox language flag to work either (https://dynamobim.org/multilingual-dynamo/), so I created a DYN in Revit with these instructions https://help.autodesk.com/view/RVT/2024/ENU/?guid=GUID-BD09C1B4-5520-475D-BE7E-773642EEBD6C

Let me know when your new revisions are in and I can test!

Also, not 100% sure the cross-langage thing applies if we only do it on newly created groups. :)

@ivaylo-matov
Copy link
Contributor Author

ivaylo-matov commented Mar 5, 2025

@johnpierson, all ready for testing. As mentioned above, I changed the strategy, and it now works with existing groups as well. In my opinion, this solution is better and addresses the points you raised, but let me know if you still prefer applying the changes only to new groups.

It also seems to work across different languages. See updated jifs in description.

@johnpierson
Copy link
Member

Looks great @ivaylo-matov !

Everything works how I would hope. The only odd (kinda) experience is if you copy a group that has had the default text modified with preferences, it will now be modified. But I do not think that is a problem.

@reddyashish
Copy link
Contributor

Triggered the job again: https://master-5.jenkins.autodesk.com/job/Dynamo/job/DynamoSelfServe/job/pullRequestValidation/17393/ as the previous one did not finish.

@reddyashish
Copy link
Contributor

@ivaylo-matov one comment left here: #15885 (comment)

@reddyashish
Copy link
Contributor

Looks like this test Dynamo.Tests.Configuration.PreferenceSettingsTests.TestImportCopySettings is failing here. Can you verify that?

@ivaylo-matov
Copy link
Contributor Author

ivaylo-matov commented Mar 18, 2025

TestImportCopySettings

Fails here as well. Will take a look today
@reddyashish , the latest commit should solve the problem with TestImportCopySettings

@reddyashish reddyashish merged commit 44bcce2 into DynamoDS:master Mar 18, 2025
24 checks passed
@zeusongit zeusongit added this to the 3.5 milestone Mar 19, 2025
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.

5 participants