Make importing a non destructive operation

[itouh2-i0plus]

https://github.com/KlingOne/XdUnityUI/issues/2

Currently importing the same Artboard again is a destructive operation that removes all changes made to the prefab in Unity. To improve the workflow the changes made to the prefab in unity should be persisted after a reimport if possible. One way to may be achieve this is by Creating the Prefabs in the CreatedPrefabs Folder but then create a Prefab variant from that prefab that should be used by the game. This way it should be possible that we can just override the Prefab when importing but still retain the changes that we made in the Prefab variant.

[itouh2-i0plus]

Challenge https://github.com/itouh2-i0plus/XdUnityUI/pull/129

• Automated Prefab Variant generation
• IDing the root name to retain the changes.
• IDing the child object names may allow for more work to be retained.

[itouh2-i0plus]

Challenge #129

did not marge.

• I want to keep the conversion simple.
• ID-named files are difficult to manage.

[KlingOne]

Hi,

I just looked at the project again after a long time and saw that you implemented prefabs that can only change their size but nothing else (like text etc...). Why is that? As far as I remember also applying changes to prefab instances wasn't too complicated. Otherwise the usefulness of prefabs will be quite limited since you couldn't reuse a button with a different text for example.

[itouh2-i0plus]

Hi KlingOne,

I'm glad you're paying attention again.

implemented prefabs that can only change their size but nothing else

I'm also passionate about repurposing prefabs. I'd like to be able to use a converter to determine that the difference between Master and Instance on AdobeXD is limited and adaptable to Unity's Prefab. It should probably be close to what you want.

When the AdobeXD API can differentiate between MainComponent and Instance, I'll be dancing.

https://forums.adobexdplatform.com/t/way-to-get-a-component-or-symbol-instance-element-that-has-changed/1894 We're monitoring this thread.

Currently I tell our designers that if they make changes to the Main component that will become the Prefab, they should put .no-instance in the layer name. This is better for the designer than the convenience of reusing prefab for the programmer. This is currently working well. Designers don't come to me and ask why this change doesn't go to Unity anymore. We've been able to put the responsibility for user screens in the designer's hands.

[itouh2-i0plus]

I came up with the idea of adding recursion to CreatePrefab. I tried it, and I'm glad it seems to be working.

The brunch is here. https://github.com/itouh2-i0plus/XuidUnity/tree/feature/create-nested-prefab

There are the following problems.

• The conversion of the nested prefab has to be finished before the artboard's prefab can be converted.
• Images that are unchanged from the main component are also converted.

There are some issues, but I like it because it was smartly done. It might be able to handle more than just text/image changes from the main component.

[KlingOne]

Hi itouh2-i0plus,

thx for the detailed answer.

There are the following problems.

• The conversion of the nested prefab has to be finished before the artboard's prefab can be converted.
• Images that are unchanged from the main component are also converted.

These were exactly the problems I faced with my prefab variant implementation of nested prefabs. But your approach seems more promising since it seems to work without the use of prefab variants

The brunch is here. https://github.com/itouh2-i0plus/XuidUnity/tree/feature/create-nested-prefab

I tried the branch and it does not seem to work for me (the changed components still have the master values) Do I need to do something special during export for it to work?

[itouh2-i0plus]

The AdobeXD plugin also needs to be updated. The branch has been updated with code fixes and plug-ins packaged. https://github.com/itouh2-i0plus/XuidUnity/tree/feature/create-nested-prefab/Release

The conversion of the nested prefab has to be finished before the artboard's prefab can be converted.

I'm going to output the dependencies with an exporter and sort the conversion order based on that.

Images that are unchanged from the main component are also converted.

This one is hard to do; it requires an extension to the AdobeXD-API. If the Artbord prefab and Nested prefab are in the same folder, it's not a problem.

[KlingOne]

With the updated plugin it works, thx!

Just sharing some of my observations:

• The ComponentToPrefabSample only seems to work if the prefab is allready in Unity

  • If the prefab is not present it properly imports the prefab, but all prefab instances have the default values
  • If you then import it a second time without deleting the existing prefab in unity all changes get properly applied to the prefab instances

• ToggleGroups do not work when they are part of a prefab

  • Convert the toggle {toggle-group: GroupA} Element into a prefab and then export it and import it to unity and you get a structure like this where every toggle has its own toggle group

Apart from those 2 small issues it works great!

[itouh2-i0plus]

Thanks for trying it out. I'm glad to hear it's becoming a good product!

The ComponentToPrefabSample only seems to work if the prefab is allready in Unity

Expoter is now giving out dependency information. I believe I have been able to handle it, but I will verify it.

ToggleGroups do not work when they are part of a prefab

This has to be fixed. We will find a better way for the converter.

[itouh2-i0plus]

ToggleGroups do not work when they are part of a prefab I fixed this. I took the approach of creating a group at runtime.

I created the same Artboard. The RadioButton is set up to be prefab, and it is mass-produced with a repeat grid.

After conversion. It does not work as a RadioButton in the Editor Mode.

AddComponent<ToggleToRadio> https://github.com/itouh2-i0plus/XuidUnity/blob/feature/create-nested-prefab/Develop/UnityProject/Assets/I0plus/XuidUnity/Scripts/Runtime/ToggleToRadio.cs

ToggleGroup is created that will be shared at runtime.

[KlingOne]

Thx for the quick fixes!

[KlingOne]

@itouh2-i0plus it would also be nice if Prefab names in XD could contain more than one Subfolder depth. Currently prefab names like this "Prefabs/UIComponents/patientMenuEntry" lead to a weird import behaviour where prefabs get created multiple times in different Folders. I tried to look at it myselfe but the problem seems to be caused by the exporters main.js replaceToFileName function which replaces the second '/' with a '_' Sadly my javascript and japanese reading skills are not the best so I quickly gave up trying to fix it myselfe.

[itouh2-i0plus]

Sorry about the difficulty reading JavaScript code... To make the folder depth free, both JavaScript and C# modifications are required. I think it's a necessary feature as well, I'll consider fixing it.

[itouh2-i0plus]

Subfolders can be deeper.

Here's the brunch. https://github.com/itouh2-i0plus/XuidUnity/tree/fix/subfolder To know the location of the relative path Nested prefab, I output a marker file in the Export root folder.

I think this has been a good feature. User can make favorite folder structure.

Remaining task: Don't output image if it is the same prefab's image. This is the hard part.

[KlingOne]

Remaining task: Don't output image if it is the same prefab's image. This is the hard part.

Shouldn't this be quite easy on the unity side? I saw that you are allready doing some sort of caching of the imported sprites so it should be easy do check if a sprite already exists. And if a user deletes a sprite or prefab you could use something like this to detect the change and update sprite cache.

    {
        if (AssetDatabase.GetMainAssetTypeAtPath(path) == typeof(MyType))
        {
            if (AssetDatabase.TryGetGUIDAndLocalFileIdentifier(AssetDatabase.LoadAssetAtPath<MyType>(path), out var guid, out long id))
                //Delete Sprite from cache here
        }
        return AssetDeleteResult.DidNotDelete;
    }`