[Bf-funboard] Features for testing and critics / Num-Entry

[Thorsten Wilms]

> > Now to the testing:
> > 
> > - select an object, hit R-Key
> > - move mouse just a little bit
> > - start entering Numbers
> > Now you will not get the numbers as entered. When I
> > move the mouse
> > to a value of 10.95 and than enter 1 the value
> > becomes 11.95. That 
> > doesn't make alot of sense on first sight.
> 
> This is why I said not to move the mouse when using
> numerical entry. The numbers you type gets combined
> with the input from the mouse (in an intelligent way:
> additionned for grab, rotate and warp, multiplied for
> scale, shear and shrink/fatten).
> 
> What happened in your case was this:
> 
> - move the mouse to a value of 10.95
> - type 1
> - results: 10.95 + 1 = 11.95

That was already clear to me. But this behaviour conflicts 
with the model of numerical input i was expecting (and I think
many people will be expecting). With numerical input I think of
editing a value field the clasical way, with a cursor, meaning a 
clear point of entry and the possibility to clear the complete 
entry with backspaces.

My main point is, I think one would use num-input only for entering 
exact values. Therefore the mouse should'nt have effect after starting 
num-input. Think of two different ways of editing: free, visualy controled 
and exact entry of definitive values.
 
Somebody mentioned the use of N-key for num-input with grab / scaling / 
rotating. I'm happy if I can have one way of entering values per keys 
without the mouse having any effect. But every new mode makes the app 
more complex.

If you want to keep the additive behaviour, it could be made more obvious 
if you show something like "10.95 + 1" in the field until one hits enter.
 
> > And you can't set the value to 0 with Backspace. 
> 
> That's because backspace only clears the value you
> typed, not the mouse value. That could be done easily
> though, but since you can already reset the mouse
> value by pressing the R, G or S key again, I thought
> that it was better that way.

O.K., that makes sense. But I didn't know about this use of 
R, G and S. Clearing the value with backspaces is, in comparison,
intuitive.

> > With scaling, there are two states showing a scaling
> > value of 1.
> > 1 as entry and 1 as default. Entering 1 will then
> > get you to a value 
> > of 1 or 11. After deleting the whole entry with
> > backspace I would 
> > prefer to see just a blinking cursor or something.
> 
> 
> I don't think that would be a good idea, since it
> wouldn't reflect the current resizing of the object
> (which is 1, for none).

But I don't think anybody would have a problem with no value 
meaning no scaling.
 
> > I would like to suggest showing of an blinking
> > cursor in the value-
> > field as soon as the first number is entered. The
> > user could more 
> > easily understand the effect of keyboard-entry after
> > an initial mouse
> > move and there would be need for an value of "1" for
> > an empty entry
> > in scaling.
> 
> Actually, I don't think a blinking cursor is even
> possible (I bet you can't locate a single blinking
> thing in the whole Blender interface).

Than forget about the blinking part.

> However, what could be done is putting the value you
> are editing in parenthesis next to the total motion.
> 
> For example, the output when typing value for a grab
> motion on the X axis could look like this:
> 
> Dx: 1.200 (1.2) Dy: 0.000 Dx: 0.000
> 
> And then if you move the mouse, if could en up like
> this:
> 
> Dx: 3.245 (1.2) Dy: 1.342 Dx: 0.000

Could be confusing, I fear. After completion of keyboard 
entry there should be only the one true value left. But see 
earlier in this post for my idea on this.

> ...
> 
> > Axis constraining: I would love to see some kind of
> > a hint right in 
> > the 3d-view of which constraint is active. I find
> > myself to often 
> > clicking middle-mouse button and wiggling the mouse
> > until I get it 
> > right. Maybe some simple arrows would do.
> 
> It's much clearer if you use the feature I
> implemented. Pressing X, Y or Z once to constraint to
> a global axis, twice for a local axis (just like
> rotate works).
>
> ...

Great! I realy like this. But could'nt test it with the linux 
binary.



Thank you very much for taking the time for discussion!


---
Thorsten