On Mon, May 27, 2013 at 11:34 PM, Matt Ebb <m...@mke3.net> wrote: > I suspect I'm one of the people Ton is mentioning so I'll say a quick word > here. These days at least for me, trying to work on an addon is frustrating > and demotivating, and the number one cause of it is API instability. > > Maybe this is just something personal to my situation because I don't have > a lot of time for this sort of thing these days but for the last several > months the pattern has been something like: "ah I have some time on a > Sunday afternoon, why not do a few improvements and make some more progress > on the addon". So I update blender, and spend all the time I have available > testing and hunting through commit logs and googling just trying to make > the damn thing work again, without doing any creative/productive work of my > own. Next time around, it's the same pattern over and over again. So these > days there's little motivation to spend my free time finishing off the > remaining last round of fixes, let alone updating to fix the next. It seems > somehow acceptable now that scripts have to be updated every few months, > because as long as people change addons that are included in SVN then > there's no problem, right? Too bad if you don't want to work that way, or > have custom/proprietary tools. > > To answer what kind of changes cause problems, *every* change is a > potential breakage and can make the difference in the eyes of a > user between an addon that works and an addon that doesn't. As I've > mentioned in the past, imo theres much too low a priority given to api > stability. > > Looking at those pages previously linked (better publicity for this would > probably help), there's all kinds of minor renaming that all will break a > script that is using it. Having consistent names for properties can be a > nice hint as an aid to API users but constantly renaming things erases all > minor benefits and just makes life difficult. I was also pretty astounded > previously to have to update all of the template list calls, an absolutely > fundamental ui function, which apparently could not have been implemented > as a separate function or optional arguments? These sorts of changes would > never happen in any other app I use with a scripting API. > > In specific one thing that I now have to fix is a bizarre error that's > never happened before, has cropped up in the last couple of months and > doesn't seem to show up in other examples included in blender, > like ArmatureButtonsPanel. [1] > > Anyway, I know this could sound quite self centred. It's really not meant > to be, just a description of what a constantly changing API means to > someone in my position. If more time and effort is necessary to effectively > use blender's python API then I'm probably just not able to devote in the > requisite amount of time and energy, and I can accept that, and probably > won't much more. It's disappointing though. > > Hope that provided some of the background you were looking for. > > cheers > > Matt > > > [1] https://github.com/mattebb/3delightblender/blob/master/ui.py > bpy.utils.register_module(): failed to registering class <class > '3delightblender.ui.InlineRibPanel'> > Traceback (most recent call last): > File "bin/blender.app/Contents/MacOS/2.67/scripts/modules/bpy/utils.py", > line 578, in register_module > register_class(cls) > AttributeError: expected Panel, InlineRibPanel class to have an "draw" > attribute
Quick reply about this python exception, the problem here is that you have a mix-in class that gets registered. InlineRibPanel, checked with 2.62 and it has the same behavior (quite sure its been this way for over a year). So fix is to change: class InlineRibPanel(CollectionPanel, bpy.types.Panel): to... class InlineRibPanel(CollectionPanel): _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers