Ah, so this is the why of this situation… I see the situation is even more complex than what I thought. Ugly dummy DNA! :P
Le jeudi 15 décembre 2011 14:20:58, Christian Monfort a écrit : > Hi, > > I don't know if Joshua is talking about the patch I made some years ago for > Blender 2.45... > Anyway, it is now in the "Todo": > http://projects.blender.org/tracker/?group_id=9&atid=264&func=detail&aid=7889 > > Christian > > Le 15 décembre 2011 12:55, Brecht Van Lommel<[email protected]> a > écrit : > >> I think such defines should be used ideally, but the reason they are >> not used in DNA_* structs is that makesdna can't parse them. >> >> Brecht. >> >> On Thu, Dec 15, 2011 at 12:27 PM, Bastien Montagne >> <[email protected]> wrote: >>> Hi devs! >>> >>> While working on some improvements to WeightVG modifiers, I stumbled >>> upon that: in DNA def of modifier structs, all vgroup and uvmap name >>> lengths are literal (32)… Imho, a define would be much better (and much >>> easier in case we decide to change it one day). We do have a >>> MAX_VGROUP_NAME defined in DNA_object_types.h – but I guess including >>> that file into DNA_modifier_types.h just for that wouldn’t be wise. >>> Also, the FILE_MAX& co are defined twice, once in BKE, once in DNA… >>> >>> So here is my proposition: why not gather all those string-length >>> defines in one place (e.g. the recent DNA_defs.h, which seems to be >>> safely includeable every where) ? After a quick search, this would >>> concern at least: >>> * FILE_MAX and co >>> * MAX_VGROUP_NAME, MAX_STYLE_NAME, MAX_FONT_NAME (and others, like [new] >>> MAX_OBJ_NAME, MAX_UVMAP_NAME, etc.) >>> * MAX_ID_NAME and MAX_IDPROP_NAME >>> >>> Also, would we need a MAX_VGROUP_NAME, MAX_OBJ_NAME, MAX_UVMAP_NAME, >>> etc., or just define a common MAX_BLDEF_NAME (e.g.), as they all seem >>> set to 32 currently? >>> >>> I’m well aware that this involves many parts of Blender code, and as >>> such might need a much deeper knowledge of that code than I currently >>> have (even though changes could be made progressively, as values would >>> remain the same) – but I really think this should be addressed, for >>> sanity of code. >>> >>> Best regards, >>> Bastien. >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
