[Bf-committers] Windows XP support has been dropped.

[Martijn Berger]

We implicitly dropped Windows XP when switching to python 3.5.
Python has the so called PEP system and PEP 11 "Removing support for little
used platforms" defines the support for windows XP to be over at the same
time Microsoft stopped supporting it. Since python 3.5 released after XP
died it does not support XP.

While it might be possible to backport python 3.5 to windows XP i think
that we should not do this.

So blender 2.77 will not run on XP. The 32 bit release requires Vista or
newer and the 64 bit release Windows 7 SP1 or newer.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] About groups and object deletion in 2.77

[Thomas Beck]

Hi Bastien,

as stated earlier while talking to you in IRC, I'm definitely for your last
proposal - delete the object from the group if it is not used anymore in
the scene. I think the current behaviour (deleting an object but still
having it in a group) is hardly understandable from a user perspective
(even tough it is consistent when you imagine that the assignment to a
group is raising the user count). Indeed I would never have contacted you
if one of my collegues would not have told me that he found a bug with
groups (exactly the new behaviour!).

So let's not change the deletion behaviour for this version and stick to
the expected one...and I'm all in for a good group dev sprint when the time
is right ;)

All the best,
Thomas


Plasmasolutions
Design | Development | Training

Website: Http://www.plasmasolutions.de 
Blog: Http://blog.plasmasolutions.de 

Telefon: +49 176 2017 9565

Blender Foundation Certified Trainer
Autor von "Blender 2.7 - das umfassende
Handbuch" 

2016-02-21 17:22 GMT+01:00 Bastien Montagne :

> Hi people,
>
> So, a recent report [1] raised the topic of how deleting objects should
> (or not) remove them from their groups.
>
> The 2.76 and previous behavior was (usually) to remove objects from
> their groups once they were deleted from all user scenes.
> However, this behavior was broken in some cases (the 'user_one' ID
> issue, same as with images used in both textures and ImageEditor
> e.g., depending on order of assignments images becomes unremovable…).
>
> In 2.77 a fix was made to our handling of those 'user_one' ID usages,
> previous 'special behaviors' of those corner cases shall no more
> exist, and usercount should always remain consistent.
>
> Now, this unfold an issue with object deletion and groups: since
> 'user_one' usage is no more 'lost' when deleting the object, it does not
> desappear
> anymore from its groups - so you get an unreachable object still
> presents in all groups instantiations, which is obviously bad.
>
> This kind of enlight our poor managing of objects & groups imho, but for
> 2.77 I would propose to simply add explicit removal
> of object from all groups uppon deletion (provided said object is used
> by no scene anymore). That way we avoid changing
> behavior for users, and at least code also clearly reflects expected
> behavior.
>
> Later we can decide what tools we want to manage objects in groups, and
> add them. ;)
>
> [1] https://developer.blender.org/T47482
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bring multiple objects to edit mode

[David Fenner]

For the moment I don't think we need advanced features for multi edit mode.
Maybe support could start only for transform operations (with soft
selection too). That would be quite a nice upgrade for the moment.

El domingo, 21 de febrero de 2016, Joshua Leung 
escribió:

> IIRC, there are quite a few technical hurdles in many cases.
>
> * Pose Mode - ALL the tools assume that they can fetch the pose and/or
> selected + editable bones off the active object
> * All Edit Modes - Again, these assume a direct correspondence between
> "active object" (specifically, ob->data) and the geometry they are editing.
>
>
> In a way, that's also why for a long time we didn't even have any sort of
> multi-edit for properties...
>
> On Sun, Feb 21, 2016 at 4:25 PM, Bassam Kurdali  > wrote:
>
> > Multi Edit (and multi pose) would be amazing. Is there a real technical
> > reason it can't be done currently? Or is it a matter of design,or
> > risking new bugs, etc.?
> > There's so many reasons a user would want this.
> >
> > On Sat, 2016-02-20 at 13:11 +0100, Doeke Wartena wrote:
> > > yeah I mentioned MultiEdit in the OP. But if you have animations on
> > > multiple objects and you multi edit them then the animations break.
> > > Also it
> > > duplicates the objects, which can be very heavy in large complex
> > > scenes.
> > > MultiEdit is created with a nice goal in mind but it's clearly not
> > > the
> > > proper way for a multi edit implementation.
> > >
> > > 2016-02-18 21:01 GMT+01:00 Yury Baranov  >:
> > >
> > > > Actually, there is MultiEdit addon for that. Check it out. You can
> > > > participate in development if you want.
> > > >
> > > > http://www.blenderartists.org/forum/showthread.php?339369-MultiEdit
> > > > -version-5-Multiple-Objects-Editing
> > > >
> > > > 2016-02-18 22:15 GMT+03:00 Doeke Wartena  >:
> > > >
> > > > > >
> > > > > > I think blender could definitely benefit from allowing multiple
> > > > > > objects
> > > > > > in edit mode, but it should only
> > > > > > work on selected objects, not on the whole scene.
> > > > >
> > > > >
> > > > > true
> > > > >
> > > > > 2016-02-18 20:04 GMT+01:00 Jeffrey  >:
> > > > >
> > > > > > I have experience modeling in Maya as well as blender, and I
> > > > > > prefer the
> > > > > > blender way because of Maya's obnoxious automatic mode
> > > > > > switching when
> > > > > > you accidentally select another object. I think blender could
> > > > definitely
> > > > > > benefit from allowing multiple objects in edit mode, but it
> > > > > > should only
> > > > > > work on selected objects, not on the whole scene. If it acts on
> > > > > > the
> > > > > > whole scene, it opens up armature edit mode, curves, metaballs,
> > > > > > etc. It
> > > > > > should only act on selected objects of the same type as the
> > > > > > active
> > > > > > object. If a couple meshes and a metaball are selected, the
> > > > > > metaball
> > > > > > will not go into edit mode if a mesh is active.
> > > > > >
> > > > > > I do not think you should be allowed to add an object to edit
> > > > > > mode if
> > > > > > you are already in edit mode; you would switch back to object,
> > > > > > select
> > > > > > the other, then switch back to edit. This avoids automatic mode
> > > > > switching.
> > > > > >
> > > > > > Because edit mode ultimately modifies only the base mesh,
> > > > > > modifiers are
> > > > > > not an issue here. Likewise, shapekeys store vertex position on
> > > > existing
> > > > > > vertex indices, so adding geometry is already bad form when
> > > > > > working
> > > > with
> > > > > > shapekeys. I'm less familiar with vcols, but I would imagine
> > > > > > the data
> > > > is
> > > > > > stored similarly.
> > > > > >
> > > > > > Multiple object editing is no doubt beneficial, but it needs to
> > > > > > be
> > > > > > improved. This is my two cents after using both. I have not
> > > > > > used XSI or
> > > > > > Max for modeling, so I cannot vouch for their functionality.
> > > > > >
> > > > > > On 02/18/2016 09:55 AM, Doeke Wartena wrote:
> > > > > > > >
> > > > > > > > It is actually something that is better in Blender, to only
> > > > > > > > be
> > > > editing
> > > > > > one
> > > > > > > > object at a time, as it can cause errors in other programs
> > > > > > > > where
> > > > > > multiple
> > > > > > > > objects are selected.
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > ...you can just join them together but pressing
> > > > > > > > Ctrl J.
> > > > > > >
> > > > > > >
> > > > > > > I never had a error with Softimage when editing multiple
> > > > > > > objects at
> > > > the
> > > > > > > same time. For maya and max I can't remember cause it's way
> > > > > > > to long
> > > > > ago I
> > > > > > > used those programs. And I think if something is prone for
> > > > > > > error then

[Bf-committers] About groups and object deletion in 2.77

[Bastien Montagne]

Hi people,

So, a recent report [1] raised the topic of how deleting objects should 
(or not) remove them from their groups.

The 2.76 and previous behavior was (usually) to remove objects from 
their groups once they were deleted from all user scenes.
However, this behavior was broken in some cases (the 'user_one' ID 
issue, same as with images used in both textures and ImageEditor
e.g., depending on order of assignments images becomes unremovable…).

In 2.77 a fix was made to our handling of those 'user_one' ID usages, 
previous 'special behaviors' of those corner cases shall no more
exist, and usercount should always remain consistent.

Now, this unfold an issue with object deletion and groups: since 
'user_one' usage is no more 'lost' when deleting the object, it does not 
desappear
anymore from its groups - so you get an unreachable object still 
presents in all groups instantiations, which is obviously bad.

This kind of enlight our poor managing of objects & groups imho, but for 
2.77 I would propose to simply add explicit removal
of object from all groups uppon deletion (provided said object is used 
by no scene anymore). That way we avoid changing
behavior for users, and at least code also clearly reflects expected 
behavior.

Later we can decide what tools we want to manage objects in groups, and 
add them. ;)

[1] https://developer.blender.org/T47482
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers