[Bf-committers] Functionality board

[Charles Wardlaw]

> -- Right-mouse select, replace with context driven menus?
> We can think over a new organization of default mousebutton
> behaviour.  Contextual menus can be a great aid in learning 
> and using Blender.

I'm not so sure about this.  It might be best to add a "Context" menu
to the toolbox.  It's just that the right-click selecting in Blender
has become second nature to me and to a number of other users; changing
this might cause the wrong kind of stir in the community.

Another option is to morph the toolbox into something more like what's
found in 3DS Max -- it tends to let different actions fall into
quadrants.  IE, on a cartesian plane the current toolbox would render
in quadrant I, while context menues would render in quadrants II, III,
and IV, depending on the current editing mode.  This would allow for
multiple context menues, for things like mesh editing, texture
assignment, and so on.
 
> -- General make-over of interface
> I won't support real 'skinning', but the general looks of the
> interface  can be easily upgraded to a more contemporary looks.
> It's a real designer's thing to do! If multiple great make-overs
> are proposed, we can implement a user-preset for them.

Are you thinking of completely programmatic skins, or skins loadable
from, say, PNG files in the ~/.blendrc/ folder or 
Blender.app/Contents/Resources/Skins?

If it's simple images, I can see a lot of non-programmers jumping on
the band wagon to create skins.  There'd be a lot of bad ones, but also
a lot of really good ones that could be distributed with Blender, with
author's permission.

> -- Wireframe colors
> We can review how it currently works in Blender, and come with a  
> proposal how it gives a bit more control and visual feedback.
> This should also include thinking over how 'solid drawing' will
> be handled.

Yeah, I've always thought that the wireframe colors should reflect
object colors, as solid drawing mode does.  The selected object would
then need some other way to distinugish itself from the rest, however. 
I forget how Max does this; it might have been with some kind of
handles or a little selection widget.  Or maybe it's as simple as
displaying the object's axes when an object's selcted; this could tie
into the manipulator handles you mentioned in "MEDIUM COMPLEX."

> -- Manipulator (handles) for transform
> As an aid to vizualize selection status and rotation/scale
> values, a manipator can be drawn which of course allows 
> scaling/rotating as well.

This would be a wonderful addition.  The current system for locking
movement and scaling/rotation to an axis is a little hodge-podge. 
Adding in manipulator handles / axes would be greatly appreciated.

> -- External Render integration
> With the impressive improvements in Yafray, we should start with
> them a project how a good collaboration (interface) with their
> render system can be achieved. Same applies for 3Delight or
> Renderman of course.

As those projects mature, would the current blender render system be
maintained/updated?  (Especially with Cessen's new additions?)  Also,
if any of the renderers provide a linkable library, what about
including the functionality directly inside Blender?
 
> --- Buttons & headers, better user configurable organisation
> Like some menus that pop up now (NKEY) we can make them become  
> persistant and movable. This will allow users to add 
> menus/buttons to each window in Blender. Think for exampe of 
> Ipo settings, View3d settings, NLA window buttons, etc. The 
> same structure can be appplied to the ButtonsWindow itself, 
> grouping them in 'blocks' and let the user arrange or collapse
> them. Additional to that, the headers system can be extended 
> to a verticial user-configurable one. The horizontal then 
> remains 'standard'.

The one problem I have with this idea is interface clutter.  My
personal experience with systems using such an interface is that it
leads to a lot of wasted space on-screen (with the extra handles and
titlebars that are required per dockable box).  Take Flash, for
example.  It does not run happily in 1024x768; you have to continually
swap between multiple boxes, minimizing some to access others.  The way
blender works currently, such swapping is mostly non-existent, and the
FKeys allow the access of the important function buttons.

> -- Constraints: replacing parenting and tracking

I don't know anything about constraints.  What I'd like to see is an
arrowhead on parenting lines that indicates the relationship between
two objects.  In complex scenes with lots of parents, it sometimes gets
confusing.
 
On Python: the trick with adding it to the main program loop is speed. 
In comparisons I've done with other scripting languages it's a bit
pokey, and if a large number of python commands are getting run every
frame or every other frame, it could lead to a severely slow interface.

Now, since python would make having undo functionality a snap (the
code's already done, as I recall), and since the python code and the
blender code already both access the same underlying structures, it
might be nice to have a queue of python commands, where during the
update phase of the main loop (and before drawing) python checks to see
if it has anything to do, does it, and empties its instruction queue.

Or maybe I'm over thinking things.

- Charles