Morph UI not working properly.

[Eder Rogerio Deana Juliette]

With the last commit (1.6.1.0644), the scroll-down function is not working correctly. No matter if with the mouse wheel or dragging the sidebar, especially if you set a small panel for the morphs. It stuck.

And as a minor question. At least for me, I believe that the button that stretches the morph panels should work independently with each morph panel. Currently, when I resize the morphs panel in Expressions, it stretches all the other panels too. That doesn't look

‌

[Xin]

This problem only appears if you have more than one panel open (of the same morph type) at the same time.

If you close all other panels, you can scroll again. So it seems that the problem is a result of having a single UIList for all panels of the same type (in this case, “DAZ_UL_Morphs”). Using multiple UILists would likely solve the problem, and also make the expand options independent.

[Eder Rogerio Deana Juliette]

Xin. Thank you for the information. I didn't notice that it worked if just one panel was open at each time. That helps a lot.

[Thomas Larsson]

OK, I just introduced separate UILists for the standard morph types. Alas, the problem persists for the custom morphs, because all categories share the same UIList. The problem is that the categories are created dynamically and are different for different characters in the scene, so it is not straightforward to create separate UIList classes for each category.

[Xin]

I know of a way to create them dynamically, I will make an example and put it here later.

[Xin]

Here is the example. Run the script in a new blend file with an object that has at least a few materials selected (the UILists in the example list the materials).

This example uses external properties for the UILists, see last example in #728 .

I think you can ignore that, just focus on the CreateListOperator that shows the most important part.

The PrintFilteredOperator serves as an example that prints to the console the currently visible elements in the specified UIList (the second column of the UILists shows the list "identifier").

[Xin]

Also, see: https://developer.blender.org/T86719

[Eder Rogerio Deana Juliette]

Thanks, Thomas, now it is really better. I could close the issue now. But as I don't know if you intend to implement Xin's suggestion, I'll leave it open for a while.

[Thomas Larsson]

I’m trying to implement Xin’s suggestion, but the code is quite non-trivial so it will take a while.

[Thomas Larsson]

Now the scroll bars sort of works for custom morphs as well, but you have to manually initialize the UILists with Update Dynamic Classes. Otherwise all categories share the same UIList as before. It’s not perfect, but it is better than before.

‌

[Thomas Larsson]

Now the UILists are initialized automatically when new custom morphs are loaded, and also when a new blend file is loaded. They must still be initialized manually after you hit F8 to reload the addons, because I didn’t find any suitable handler to do the job automatically.

[Xin]

Thanks for the changes Thomas, that was fast.

I haven’t yet looked it closely, but another possibility could be to use a global boolean to keep track of the “initialization” state of dynamic classes, then in the draw() methods of the main panels, check the flag, and if it’s false, call the initialization code. Later on, when custom morphs are loaded, the necessary dynamic classes are created, so the flag always remains false from then on. This wouldn’t affect the draw() later on either since checking a flag that is false is not expensive at all.

But I don’t think this is worth if if it already works fine for all cases except for F8. Pressing the button is fine in that particular case.

Another possibility: https://blenderartists.org/t/when-to-initialize-custom-scene-variables-in-an-addon/588708/2 . Again, I don’t think it’s worth the hassle if the problem is just F8.

[Xin]

Oh, and another thing. Have you tried saving a .blend with custom morphs, then opening that .blend in a new Blender window with the addon disabled, and then re-enabled the addon (to emulate giving a .blend to someone else on another computer who also uses the addon)?

I think there could be an issue since “DazDynMorphs” and “DazDynShapes” are saved with the .blend, but the updateDynamicClasses() method is looking at those scene properties to see if it needs to register classes. So in that case, there would be a desync between the registered classes and the scene properties (DazDynMorphs and DazDynShapes).

Considering that, and considering you aren’t using external properties for the UILists, I don’t think you need “DazDynMorphs” and “DazDynShapes”, you could use “theDynamicShapeClasses” and “theDynamicMorphClasses” instead. Since those aren’t saved with the .blend, they would be in sync with the registered classes.

Another way would be to check if a class is already registered directly, with a try/except maybe. Probably the cleaner solution.

[Thomas Larsson]

The DazDyn… properties have now been removed, and the dynamic classes are only stored in the global variables. There are still some cases where you manually need to update the UILists, e.g. if you press F8. I tried to put the update code in the register function, updating all objects in bpy.context._real_data, but that caused a hard crash with library overrides.

Doing the update in the draw function does not work, since it is not allowed to register new classes in a read-only state.

At some point I managed to lose the class definitions by disable and reenable the plugin, but I’m not sure exactly which step that led to that and now I cannot reproduce the error. Anyway, I don’t see why anyone would want to do that. You may disable the plugin for rendering, e.g. in a render farm, but then you don’t need the UI and don’t reenable it again.

[Xin]

Thanks again Thomas.

If you still want to put the update code in the register function, there is a workaround as explained here: https://blenderartists.org/t/when-to-initialize-custom-scene-variables-in-an-addon/588708/2 (check the answer). Again, I don’t know if it’s worth doing if the only thing this would handle is the F8 case.

[Thomas Larsson]

The problem appears when you add a character with morphs already loaded. Opening a blend file is one way to do that, and that case is covered by the load_post handler. However, there are other ways for which no suitable handlers exist: append file, link file + make proxy, link file + library override. It would have been nice if there were handlers for those cases as well, but doesn’t seem to be.

The suggestion in the link, to add a handler on scene update, seems too expensive. In contrast, loading a blend file happens very seldom and you expect that it takes a little time.

So I’m inclined to leave things as they are. The UI still works even if separate UIList classes haven’t been defined, the only problem is that you cannot scroll custom morphs if several categories are open. And in that case you can update the classes manually.

[Xin]

The example in the link is not supposed to be a permanent handler, it removes itself after being called once. The purpose is to run some code immediately after register(), so it’s basically an addon initialization code. Search “collhack” in that link above.

This would handle the F8 case, that’s why I’m not sure if it’s worth doing just for that case. It does not handle the append/link cases.

[Thomas Larsson]

I hit F8 all the time during program development, but when I try to do something artistic (which was a while ago), I never do F8 but often append or link files. So I will close this, for now at least.

[Eder Rogerio Deana Juliette]

Thank you for your efforts, Thomas.