Did I read this right, Blender trunk development to be frozen for 2.5?

Quote from Campbell

Development continues, though blenders internals will be frozen for blender 2.5 reactor. I wouldn’t expect it to slow down that much since devs can still work in their branches

Does this mean trunk will be unavailable for development until 2.5 refactor is complete? If so then will this mean more branches for more developers like a BGE branch for Ben2610 and the handful of other BGE developers?

Well who knows? (Campbell ? Ton?) But it does make sense.

If you have to refactor a central part of a system it is a lot more easy to refactor a central part in a static environment than in a dynamic. Afterwards one can try and implement branch changes. The problem here is that developing for the dynamic environment forces a lot of patches to make other WIP’s compatable with the evolving project.

Before you freeze it please consider including the normals paint developments! They so goood!

you asked for it (new gui), you (will) got it.

with graphicall people(non-builders) can still get custom builds with their favorite patches. i would hope Ton and the others would freeze the main branch to port everything over and then tweak/debug for 2.5. the other way would be a nightmare with people still developing constantly… but im not a dev i have been known to be wrong before.

Makes sense to me, whatever helps the devs get the job done.

I just wonder what it will look like and/or if it will be worth the hype. (what really is)

If it looks remotely like that video last year, I’ll be grealy disappointed.


No but seriously… Dis-A-Pointed


I honestly don’t know why anybody could be disappointed by that. It is a necessary move for the developers to be able to port the internals for 2.50. This would be, as some already said above, a nightmare if these parts gets changed here and there by someone else. Nonetheless every developer CAN still add features inside a BRANCH. So instead of complaining here…feel free to checkout these branches and compile them on your own (or download a build at graphicall).

Just place confidence in the developers. They know what they are doing!

At least we like 1) to believe we know and 2) make others believe we do.


I just noticed the mailing list has not had any new commits in anything over the past 2 days, is this because everyone is waiting to here the plans for Blender at the conference?

what ever it takes to make the interface easier to learn is welcome to me.

when they freeze the main part to bring blender onto a new level - well it might
be required and in the end turn out well.

William Reynish’s GUI Mockup looks promising.

The ‘silence’ in trunk is mainly due to the Blender Conference.

But even if there weren’t such an event, there’s really no need to get all worked up over a period in where no commits are being made.


Are you talking about the old redesigned button architecture project? If not, I’m interested to see what you are referring to.

Egan, the second video on this page.



They finally make an attempt to improve Blender and bring it to up-to-date standards.

This looks very promising. I am curious about how far they can do it because it would
require also re-write from scratch for parts of Blender as they expressed inside the

And we should be starting to see the actual development going before long. 2.5 is finally going to happen and we’ll be seeing the fruits as we download the new release sometime in 2009.

Yep, I watched it, and I am very excited. :smiley:

Ya, that was good and yet barely scratching the surface.
There is a whole darn lot to discuss and it will be hot, very hot.
I agree with him that 98% of the users won’t customize the interface that much and that good defaults must be found. I can imagine that every darn user will have his/her own conception of what those defaults should be though.
There was a thing that is a no-go for me: forcing us to adopt vertical displays of the buttons exclusively.
What I liked the most was his insistence on having uniform behaviors and applying the same models, like the object>action>settings model. Strangely enough this stand just short of having true parametric objects and yet he didn’t go there… Then again, if construction history can be accessed like a pile of modifier he didn’t have to.


I could live with vertical displays since panels would be seen easier in a vertical fashion and they’ll be redesigned.

I think he makes the argument saying computer screens are generally wider then they are tall, this would take advantage and maybe have a more square workspace, though some areas could also be horizontal, we just have to see what the 2.5 interface ends up looking like.

I agree that monitors will be increasingly of the 16:9 persuasion. My preference is for two 4:3 monitors though and there will always be cases of screens that someone need for a job where buttons will have to be horizontal. Why wouldn’t the resizing that he proposes for vertical displays not be available for horizontal displays too? It is just a matter of stretching the panel in width rather than in height after all…