So today I was informed once more the API changed and broke my addon once more. It seems to be the usual case with each new release of blender and I can say I am very annoyed by this. But I was wondering if I am the only one, or even more, whether I am a minority or not.
So the question is do you think that the blender API should be , less eager to brake things in sake of progress.
Bare in mind here for those who may make you believe eitherwise its perfectly possible to have a fast evolving API without braking backward compatibility . But I want your opinion on this , mine is pretty much clear.
Oh, you are not alone. I have been annoyed for quite some time. It has actually discouraged me from writing new AddOns for the community. I mean whats the point? It will be broken in one or two revisions anyway. This last round of changes killed Re:Phrase+ and RE:Frame.
I coined this term in another thread but it deserves to be mentioned here API Shock!
So, umm… People are volunteering to maintain this backwards compatible API?
Makesrna isn’t really that difficult, you just have to figure out how whatever part of blender it wraps works and either adapt existing functions or write new ones for python to access the data. Sometimes you also have to figure out how makesrna itself works too to get it to do some random new thing where there’s no examples to work from but that isn’t really that hard. Doesn’t really hurt to understand how python works internally either since a lot of things aren’t as the seem on the surface but, yet again, python isn’t that difficult to understand. Easy peasy, really.
I, for one, look forward to having some new blender py-devs because just once I want to be able to write a script without having to go in and either fix bugs or write new wrappers for some part of blender that nobody has gotten around to yet.
good thing I am not the only one. Yes at least we need some good docs for the api changes I definetly agree on that.
probably . But then I was not looking for alternatives just the opinion of people on this.
I abandoned python completely apart from doing some minor things for blender in favor of smalltalk. And the reason was not just the blender api.
So if I understand you corectly you saying that developers , us and anyone else would be better adding more things to the api.
If you asking for my opinion , I would reply with a “No Way”. You see I am a person that all his life has been using the moto , “less is more” this is the first thing that draw me to python. I happened to become a blender developer because I love python and I love graphics in general. Blender using python made me hope that it followed that same philosophy but I was wrong.
Blender follow a diffirent moto " more is more" , blender is all about cramming new features. Its no secret it was messy as GUI , and I think its blender python api is far from “pythonic”. To be frank I and blender just have opossite philosophies and certainly go opossite directions. So the chance of me contributing to the API or to C source code , is close to none.
As a matter of fact I am looking for way moving away from the API. I am developing my project Ephestos in smalltalk which will be all about simplifying coding, blender and other apps and libraries I use. I was thinking making a layer on top of blender api that will never brake its compatibility this way allow me to create blender addons (but not in python but in smalltalk) and never have them brake. Obviously I will have to maintain that layer and compansate for each time the blender API brakes. But I prefer maintaing a simple API than a collection of addons.When that will be ready I make no promises.
Blender is just not the kind of enviroment I would like to code for, but yet I love using blender and supporting it. Obviously Blender is a great piece of sofware , even though deeply flawed in design, and the API does its job. So Ephestos will be I hope my solution to this mess.
Let me ephasize here that in no way I am downgrading the amazing job blender developers have done so far with Blender. They managed to add features to blender that I would not dream in my wildest dreams. And I cannot claim that I have not benefited from “more is more” philosophy. But in the end of day I prefer limitations and easy of being productive than, super powers and nasty workflow. I totally respect people that prefer something else. And I am not in any way claiming that Ephestos will not suck in many diffirent ways. Just that it will suck diffirently
Once the current push for adding new features/reorganizing things in Blender dies down, it’s highly likely the API will settle down, too. Until then, the only Python coding I’m doing is such things as adding buttons to panels and using those to access features already available. In other words, I’m not going in too deep.
Others will, of course, do as they please, but I don’t like headaches; they make my head hurt.
People are volunteering to maintain this backwards compatible API?
@Uncle Entity: How can we maintain backwards compatibility against something like Addon’s can no longer access context on activation? Developers are changing the way events flow behind the scene. It is easy, in hindsight, to say well this won’t effect too many people I think we can this or that. But to repeatedly do this to us on every release is quite discouraging.
I assumed the Foundation, and it’s paid developers, were maintaining the fixes that they routinely break in all the scripts that get ‘officially’ released. Isn’t that the reason why you want your script officially accepted, so you do not have to maintain it when the developers decide to change things? But from what Kilon is posting it seems that even if your script gets accepted into the ‘official’ release you will still have to maintain patching it. And what about scripters that have moved on but have scripts in official release? Does the Foundation just wait to see who jumps through the hoops and fixes things for free then patches what they broke on the remaining fallout?
No I did not say that, you dont have to keep maintaining and if it is really useful to people most likely ideasman , or other developer steps in to further maintain it. But I do not like other people maintaining my script , not because I think its a bad thing but because I know they have better things to do than trying to understand my code which is not the best of the best if you know what I mean. Because lets face it I am still a noobish coder.
Most addon developers that get their addons in trunk abandon them sooner or later. Because life get busy or acquire new priorities.
And this is another reason why I praise all developers and especially ideasman for their hard work. I am just a bit annoyed with this situation.
I was able to patch two of my scripts by deferring the action to a thread. For instance, you can no longer issue a collection.add() within a draw event. Without this, my entire RE: series of scripts do not work. Properties are stored in the object that has the context, not the scene. So instead of adding the collection in a draw event I simply launch a thread and issue the collection.add() in the thread which is activated on a small time delay to give the draw event time to exit and release the lock. This is kind of like going behind the developers intent, just to get the functionality I need. How long till this is invalid? So do I spend my time trying to re-invent what I already have or just live with a sneaky workaround till it is discovered and blocked?
Hopefully some of these restrictions will ease up when the DAG receives it’s scheduled attention in 2013.
AFAICT the only reason this effects anyone is because there isn’t a better place to store global settings than Scene so what is really needed is a proper fix so people don’t have rely on a hack that can crash blender and somebody needs to code this proper fix so…
And to beat my favorite dead horse… my old py-listeners patch would have solved your draw() problem nicely though you could probably recode them to use the (much less nice) event system hooks Campbell added a while back – assuming you mean calling stuff from Panel.draw() that is.
Actually… that’s the perfect counter argument here. If Campbell were ever to actually look at the code for my py-listeners, realize that every argument against them is either trivial to fix or just plain wrong and see how super they are then we’d have people complaining because the hacky event-system hooks scattered willy-nilly throughout the py-api were replaced by a much better system. Or even worse someone would have to maintain all those dodgy functions (to maintain backwards compatibility) instead of working on something as equally awesome as py-listeners.
If it were up to me I’d much rather maintain a unified event listener system than a bunch of random low-level python functions.
…and, yes, I’m mostly joking on how super-awesome py-listeners are.
Some backword compatibility is always very nice. I’ve seen other unrelated projects where a lack of compatibility frustrated quite a lot of people because any progress they had made in the current version had to go back and redo the same crap all over again. Some people got lost, the developers created new bugs to solve, and overall progress degressed to one version replacing another continually until some folks just sort of lost interest because the developers didn’t want to take the time to slow down enough for most people to catch up on what was changed before making more and changes. Progress, is always good, but with an open project like Blender you can’t really move forward if too many people get lost in the process? Hope this makes some sense to the developers in not moving too fast.