[Bf-committers] Custom Transform Alignment

[GSR]

Hi,
theeth at yahoo.com (2007-12-28 at 1158.01 -0800):
[...]
> Aside from this, there was a couple of redraw issues
> and stuff like that which I've fixed (locally).

The video driver seems to be pretty stuffed latelly, so I started to
blame any drawing issue to it. :]

[...]
> > Sorry, but these new align options are not very
> > useful with the widget off
> 
> Why do you think so?

Cos you have to act blindly, key constraints (and mb2, to a lesser
extent) become try and error.

[...]
> > I would keep all buttons in one side, or separate
> > using "the safe way"
> > with delete away from others, for example "X Name ?
> > >". Also I would
> > use letters like, S and A for select and activate
> > instead of abusing
> > cryptic "icons" ("open something" and "help"? or
> > maybe "move right"
> > and "unable to find icon image"?). As the panel is
> > used in single
> > column mode, they could be "Sel" and "Act" text
> > anyway.
> 
> I've put the X on the right side because that's where
> it usually is for datablocks (selector - name - users
> - fake - delete).

But they also have all the buttons in the right. OTOH, looking at the
screenshot and new patch, having all the radio button as a inverted L
does not look too bad, and places the name near the activity button.
 
> You're absolutely correct though, there's enough space
> for words instead of cryptic icons.
> 
> I've used "?" for "Select" because it's sort of what
> the "?" button does in the material assignation panel.

Now that you mention it, that one could go with Assign (in the group
of 5 buttons below) and a text like Activate or Pick, they seem to be
3 pairs of related actions.

[...] 
> > * I still keep on thinking panels is pushing issues
> > into user hands
> > instead of solving them... the "Blender is no
> > overlap" motto is pretty
> > much invalid by now.
> 
> The problem with having it as a non-overlapping panel
> in this case is that it's per view settings, so it
> can't be stuffed down in the buttons window.
> Ideally, I think making a side bar with the floating
> panels' content (except preview, obviously) would be a
> good compromise. If I understood correctly, that's
> something that might be possible with the new
> windowing system in the branch.

It would be nice to have a docking area for panels, yep (also multiple
headers, multi row headers, etc).

[...]
> > BTW what rules are used for vertex, edges and faces?
> > Not too clear. At
> > most I can see vertices have a normal by themselves,
> > but not so clear
> > in all cases what to do for the undefined axis
> > (edge: interpolation of
> > the two vertex normals and edge as second axis?
> > highly deformed quads
> > and future ngons cases sound even trickier). Think
> > how you would write
> > the book section covering this to figure what I mean
> > about being
> > clear.
> 
> Easy. It's the same behavior as Normal orientation.
> That is: Z axis is defined as the normal (or edge),
> other axis are perpendicular but not strictly defined.

I was talking about that lack of strictness. ;]
 
[...]
> > A conditional interface, more things to remember,
> > longer manuals to
> > write and read. :[ No way to track them at all so
> > there are no special cases?
> 
> Not completely. Unlike objects, it's harder to track
> addition and removal of vert/edge/face, so it would
> end up like Vertex Parent (messing up from time to
> time).

I guessed so.

> > OTOH people can "freeze" by adding an empty, copying
> > rotation, and
> > then hiding it (which manual workflow and can become
> > tiresome).
> > Keeping on with the brainstorm, having a button to
> > convert from object
> > to named type or adding fixed kinds based in objects
> > (button and menu)
> > could be interesting too.
> 
> That would be possible, yes. Not quite sure on the
> usefulness though.

It freezes, quickly and without recurring to an empty that has to
remain untouched.

Well, I see the commit just took the other path, make all static. So
now if things have to be aligned to a given object at different
moments of animation, user has to recreate multiple align settings,
and if the animation changes, he has to manually update them. Simpler
code, stiffer workflow.

> > Well, that is what I can think at first glance based
> > in current
> > system, plan after instead of before, and without
> > getting into
> > radically changing other things.
> 
> Thanks for the comments and analysis.

Thanks for reading it.

GSR