[Bf-committers] Exposing Tool Settings - issue with 2.5x

Campbell Barton ideasman42 at gmail.com
Fri Aug 5 07:20:48 CEST 2011


On Fri, Aug 5, 2011 at 2:58 PM, Matt Ebb <matt at mke3.net> wrote:
> On Fri, Aug 5, 2011 at 2:53 PM, Campbell Barton <ideasman42 at gmail.com>wrote:
>
>>
>> Unwrap can have a settings menu which can be in both.
>> * Image Space -> UVs -> Live Unwrap Settings (toggle under live unwrap
>> option)
>>
>
> Sure, because it's a thing that's 'built in' to the UV editor, not an
> operator
>
>
>> * 3D View Space -> UV Mapping Menu -> UV Unwrap Settings (toggle under
>
> Unwrap) --- *this one is a bit awkward IMHO*
>>
>
> I don't understand this - the UV unwrap *operator* has its properties in the
> operator properties area, like any other operator. It shouldn't be in a menu

Yep, but there is still a conflict here in how settings are exposed,
should the operator be synchronizing between scene->toolsettings and
operator options at all?

Its error prone - if a python script for example runs a bunch of
operators it can adjust the scene->toolsettings used when they next
run live unwrap.

once we add last-used settings. should this be used rather then
initializing the options from the tool settings?

Should the settings set in the operator write back to the
scene->toolsettings? (we could just use it for initialization only and
not write back, relying instead on the last-used settings to give
predictable behavior).


IMHO having settings both as operator properties and toolsettings is
problematic and unnecessary. You could just say "dont synchronize
settings" - in that case users can get different results between
unwrap and live unwrap and just have to accept it.

Or  try to find a way to sync in a way which isn't annoying to the
user - this is what we attempt now, blender could for eg detect that
an operator is run by a script or a macro (rather then by the user)
and not store as tool settings in that case, but I'm not convinced we
can do this really well.

>> Edge Slide UV options
>> * 3D View Space -> Mesh -> Edges -> Edge Slide UV Correct (toggle
>> under Edge Slide)
>> ... will go in Ctrl+E menu too - same menu in this case.
>>
>
> Uh? why not in the edge slide operator properties area?

This option is internally (scene->toolsettings->uvcalc_flag &
UVCALC_TRANSFORM_CORRECT), the idea is to be able to do other
transformations and have the UV's be corrected - just transforming a
vertex loop could work too for example.
This option is meant to work more like mesh mirror, where multiple
tools use it.

Another reason only accessing this in the operator is a problem is
that bpy.ops.mesh.loopcut_slide() macro doesn't expose the option,
though this is an implementation issue since it could be made to be
exposed.


-- 
- Campbell


More information about the Bf-committers mailing list