shapekeys/targets added, version number made visible

[black-punkduck]

1: I added a new method for shapekeys. It now works with maketarget load a predefined human load a target from makehuman either apply target new button or produce clothes then it will be applied (e.g. for heels or breast-size) this is the method without MPFB

2: when a mesh is loaded (obj or predefined mesh) and MPFB is available MhScaleMode now is set to DECIMETER

3: I generate the title from bl_info. It is a hack. bl_label is set, when from x import y is called, I cannot directly set it in init because I cannot import from init so I put it as a global into extra_properties, which has to be imported first ... this is ... kinda crude :( ... But I did not want to threw all the makeclothes2.py code into the init.py

4: no dependencies changed

[Aranuvir]

@ Topic 3: I didn't take a look at the code, but is it possible to change the header after the class got registered? In that case it should be possible to write a classmethod that is called after the registration. Something like:

def register()
     [...]
     for cls in [...]
          [...]
     MHC_PT_MakeClothesPanel.setTitle(someString)

[black-punkduck]

stack_exchange: Manipulating an operator type once registered isn't supported.

leave the value completely out: bl_label => missing attribute, so it has a certain meaning

I also tried a setTitle after I got the class, which sets a global variable (because of unregister_class it had to be global), then I did an additional unregister_class and register_class ... it does not look better and it does not work.

I did not have succes tbh :(

[Aranuvir]

To bad. Did some tests, but couldn't find a quick workaround for that problem. Looking at HOps they do a simple from .. import bl_info Not sure if that works for us...

[black-punkduck]

no it doesn't because importing of "." (or init) would result in trouble (circular dependencies, blender complains that makeclothes is not found then). But why not moving bl_info into extraproperties ... now I can easily access it from everywhere and in a way that really makes sense and does not look as stupid as my first method :)

So it was not the solution but it put me on the correct way, thanx :+1:

[Aranuvir]

Sorry, but I'm not absolutely convinced :-1: . An addon must contain a blinfo in __init_\.py (https://wiki.blender.org/wiki/Process/Addons/Guidelines/metainfo#Script_Meta_Info). I'm not even sure if it currently will register correctly. I've crated a little test scenario using a from .. import bl_info, but the order in __init__.py matters and bl_info must be at the very top of the script to work correctly. A quick test by adding a from . import bl_info (with one dot in that particular case!) in makeclothes2.py and sorting __init__.py a bit showed me that it should probably work. (And BTW, Hard Ops, from where I got the inspiration, is a paid addon. They probably won't deliver crappy code. ;) )

[black-punkduck]

Even this big U.S. multi-million-vendor of routers with 5 letters delivers crap here and there. Daily business in my life. XD

Python itself can handle to get the bl_info from everywhere, but if they have a special tool to look for the bl_info you may be right. Of course I can put it there again.

To put the import lines after the bl_info solved the problem. I did a bunch of prints to see when python is sourcing the files. In Joels version all imports had been done and all extra-properties had been known before program reached declaration of bl_info.

Maybe it is because for most of the languanges we do import (python), use (perl), include (C) somewhere before the code (yes not always, I know). Last not least these are statements to let the interpreter/compiler open the next file, parse it and continue where it left. So now I hope it will fit.

[Aranuvir]

:+1: Looking awesome now :D

[joepal1976]

Looking good.

Concerning the "if XYZ is available then do ABC" logic, I think we should look more closely at merging all plugins into a monorepo once we've got 1.2.0 through the door.