[Bf-committers] Weekly irc meeting minutes, oct 11 2009

Campbell Barton ideasman42 at gmail.com
Tue Oct 13 10:23:14 CEST 2009


- Note: Python scripts for menus or buttons should strictly use the
Operator names themselves.
--- snip

Brecht and myself disagree that this is a good move, simple example of
how this fails.
- A menu item sometimes refers to an operator+option combination.
 Wkey -> Subdivide Smooth
 is... layout.item_floatO("mesh.subdivide", "smoothness", 1.0,
text="Subdivide Smooth")

If we use full names this also makes enumerator menu's look different.

# This is a menu that shows each operator enum as a submenu...
layout.item_menu_enumO("mesh.uvs_rotate", "direction")

static const EnumPropertyItem direction_items[]= {
	{DIRECTION_CW, "CW", 0, "Clockwise", ""},
	{DIRECTION_CCW, "CCW", 0, "Counter Clockwise", ""},
	{0, NULL, 0, NULL, NULL}};

We get this...
"Rotate Edge -> Clockwise"

But assuming sub-menus have full names it SHOULD be...
"Rotate Edge -> Rotate Edge Clockwise"

Assuming you want full operator names here are some options...
- add enumerator names to operator names automatically (gives long menu names)
- name enumerators including the operator name (which makes enum
definitions less reusable).
- not use menu enums and have an operator for "Rotate Edge Clockwise"
and "Rotate Edge Counter Clockwise", but this seems overkill since
menu enums are a nice way to avoid writing lots of operators.
- ignore this problem and allow enums to be names as they are and
accept inconsistent menu naming

having a way both can be consistent which is less easy then it looks,
especially when you could have multiple operator options assigned to
one menu item.

On Sun, Oct 11, 2009 at 6:40 PM, Ton Roosendaal <ton at blender.org> wrote:
> Hi all,
>
> As usual, the highlights of the irc meeting.
>
> *****  Bringing back 2.4x stuff in 2.5
>
> - Ton happily reports the Durian team fully uses 2.5 trunk now! It goes
> sometimes with pains... but reports have been greatly tackled by
> Campbell and Brecht
>
> - Missing features and todo items should still go to the 2.5 todo:
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Todo
>
> - Tom and Campbell will fill in the wiki todo for mesh, sculpt,
> sequencer
>
> - Mesh retopo: Angela (Durian team) missed it in 2.5, used 2.4 to make
> a first character remodeling. The retopo snap-to-Z feature is still
> much wanted. Nicholas, who coded it, rather not just moves the code
> over, too horrible. Martin checks on having it as a Transform Snap
> version.
>
> - Macro-ing operators still needs work. (like for extrude, loopcut). Is
> on todo list.
>
> - Meeting agrees on sticking to 2.49 compatible hotkeys in the
> hardcoded (C code) keymap, at least for the first 2.5 beta. Some
> exceptions exist, but will be kept minimal.
>
> - We also make a shortlist of 2.5 features to not enable in the first
> beta build. Some operators are only for test ("split region"), others
> are unfinished ("duplicate window" lacks proper local context).
>
> - Once we have the detailed picture, a date for the beta0 build will be
> picked. Currently unknown, and quite uncertain if that's around Blender
> Conference (2-3 weeks).
> Topic comes back next meeting and on mailing list.
>
>
> *****  The 2.5 project work itself
>
> - Note: Python scripts for menus or buttons should strictly use the
> Operator names themselves. In case the menu then becomes ugly, like
> with 10 items starting with Select, we'll either solve that in code, or
> with an additional Operator feature.
> This is important to keep it all fit for future interface translation
> work.
>
> - Primitives; Tom Musgrove did a proposal for gathering custom
> materials, meshes and rigs in Blender. He will work on this with Jason
> van Gumster. Idea is to first collect good examples, and then work with
> a developer on the best integration code.
> http://blenderartists.org/forum/showthread.php?t=168911
>
> *****  Other Blender projects
>
> - Nicholas Bishop mentions Sculpt speedup progress, testing VBO support.
>
> - Arystan proposed to add his first test with rigid body support (via
> Bullet) in svn. Meeting preferred him to use his own branch first, and
> also make a nice doc describing proposal of how Bullet will work with
> our physics and animation system. Very promising!
>
> - Damien reported (via email) that a Blender Cocoa 32 bits version is
> nearly done. Port work to 64 bits has more issues still, but mostly
> related to getting the right libraries compiled.
> Test build is available already on http://www.graphicall.org
>
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list