Page MenuHome

Change modal number input to press key before activating expressions
Closed, ResolvedPublic


Regarding D61: Support units in modal numinput.

The feature in is getting a lot feedback with people confused about it, or finding that it makes their workflow slower due to have to use ctrl - or ctrl x after typing the number, which is not as efficient. We've had a bunch of people reporting this as a bug, and discussion on the forums and mailing lists.

We should consider making it something that you activate, by pressing e.g. the = key so that existing workflows stay the same.

We should make a decision here before the 2.70 release.

Event Timeline

I personally think we should make it activate with the = key.

using the "=" to activated it sounds good to me off of the top of my head.

there is a change to the workflow too, committing to know what axis you are going to choose before hand does strip the speed of modeling workflow

also giving a bigger shortcut to intense use operations is bad, and will exhaust the modeler.

The '=' has very different keys assigned depending on the keyboard layout, so it can be difficult to reach on some configurations, on my keyboard for instance it is Shift+0.

I would suggest the Tab key.

codemanx added a subscriber: codemanx.EditedFeb 16 2014, 10:52 PM

I wonder if = will check for this character to be typed on any keyboard, or if it rather reacts on the key which is = on an english keyboard?

In Dopesheet editor, Select Before Current Frame is mapped to [, but that would be Alt Gr + 9 on a german keyboard and doesn't work. It reacts on ß key however (the keyborad key to the right of 1234567890).

Tab is used to toggle modes, and this is about mode switching too. Seems good to me.

A behavior question we should discuss:
What should happen if you hit Tab again? Should it use the calculated values and let users tweak them further, or should it start from scratch?

I would suggest the Tab key.

i think that's good, tab key isn't used while in tool mode.

What should happen if you hit Tab again? Should it use the calculated values and let users tweak them further, or should it start from scratch?

start from scratch is better, or i should say gets you out of the mode.

+1 for the original proposal, = key to enable this behavior.

I think tab is better choice.

Tab key is better for laptop users of non-us type, is also common in other software of switching mode like this. It works equally well for full sized keyboards.
It is also already used for mode switches.

Is it possible to keep modal number input, but restrict it to numbers only '1234567890' and '.' by default and enable rest by pressing '='. This way we will get the old '-xyz' and a backspace which doesn't work in old mode.

@Linus Yng (LY) - as has been stated, Tab is already used to switch transform axis.

I don't understand how "=" would work to activate the behavior?

If I understand it correctly, then the suggestion is simply to change how and when Blender interprets the input as an expression? Is that correct? If so, then I think it'd be far more straight forward to require expressions be inputted within parentheses.

This then allows the user to do this:

  • Activate grab
  • Input 5
  • Press X to activate the axis
  • Input expression to evaluate against within parentheses. For example: 5 x (x3) would move object along the X axis 15 units.

One of the keys is to allow the user to designate the axis lock before or after the numerical input. By using parentheses for expressions, the user has fine tuned control.

Parentheses seems a bit strange to me, you'd have to type the closing ) before you see the result then instead of seeing it update as you type?

The way I imagined it is that you could type 5 x = * 3 (or x = 5 * 3) in your example to move 15 units along the X axis. So pressing = would create an expression with whatever value was typed in already.

Ah that makes more sense now. I'm good with that. Thanks for clarifying.

That's how I figure it (that agrees on what Brecht tells above):
You press G and start to digit the old way, axes,' -', '+' etc, whether you feel the need for entering a computation, you press the proper key ('=') and you continue to type from what you have eventually already typed.

Hitting the '=' key once again should, maybe, toggle to manual free mode, untill you hit the key again or start to type again.

Thank you

as has been stated, Tab is already used to switch transform axis.

can you please verify that (or explain how it is used), i searched for the functionality and couldn't find it! i also searched the shortcuts with "tab" and didn't find it.

@campbell: awesome, i didn't see that there, but it's awesome, however it is hidden and i doubt that many use it.

but it's awesome.

also it is not consistent with rotate and scale!, i think that should raise a consistency task for it, no?

@Yousef Harfoush (bat3a) - the purpose is not to break existing workflows, changing axis is very common operation for anyone who uses numeric input a lot.

yes i'm totally with you, i meant to add this feature to rotation and scaling too.

@Yousef Harfoush (bat3a) - tab to select axis works for rotation and scale, please take some time to investigate how features work when getting involved with design discussions.

I'm in favor of using = to start expressions as input. I like it because it reminds me of spreadsheet editors, where you also start equations in fields with = symbol and it offers familiarity. I have a QWERTZ layout (rather than QWERTY) and access = symbol by pressing shit+0. Speaking for myself I'm fine with that, I've been using it since ever and am used to it.

Shift+0 seems to be more of an exception than a rule. Out of interest I checked and there are a lot of layouts that directly access = symbol, for example Arabic, Chinese layouts, Korean, Russian, Hebrew, Greek, AZERTY, Dvorak.

Forgot to ask a question. Should = be used only to activate expressions or do you think it could also be used to deactivate expression? This way it would work as a toggle.

tab to select axis works for rotation and scale, please take some time to investigate how features work when getting involved with design discussions.

which i already did, and i didn't find it either in the wiki or through search or by trial!
and i'm getting my self involved with design discussions because of the lake we have, and sorry if i bothered you.

all i want is model in blender as fast as i was.

Ok, will prepare a patch for next time I’m online (should be next saturday), using '=' to enable/disable complete mode (and start by default in "simple" mode), should not be hard.

See D332...

Please note I have to leave now, online again next saturday hopefully.

Right now it does not work at all on keyboard layouts that don't have a physical "=" key. For example on mine, and on many of the previous commenters' keyboards, it's accessed with shift-0, which does not activate the expression mode.

@Henrik Aarnio (hjaarnio): Fixed by using also 'pad *' in addition to '=' (so both enable advanced mode now, and disable it when used with ctrl).

As stated by hjaarnio, "=" desn't work if keyboard doesn't have the "=" key, nor works the Shift+0.

Moreover, on keyboards without the numpad, such as the Apple wireless keyboard, the 'pad*' doesn't work too.

You should choose at least a shortcut that works for everybody.
Specifically, at the moment I have no way to activate advanced mode.

Thank you

The shortcut doesn't work here as well. I tried using shift+0 and even if I change my keyboard layout, the = key doesn't activate expression mode. I tested this using the official 2.7 test build from on Elementary OS (Ubuntu derivative). Some users report the same problem on osx.

Is this the right place to post this or would a separate bug report be better?

At least on Windows, you need to change keyboard layout to English AND press the key where = is on an English keyboard.

It is ´ key on German keyboard, the key between ß and Backspace, above Ü and +

Since the key assignments seem to be a problem still,
I wonder if we could remove '=' and '*' and use some key which is more often available.

other options...

  • Insert (insert and expression? - nice its a single key though not the most obvious choice)
  • Ctrl+Space (used as autocomplete for console, toggle manipulator in the 3d view - not really the same use here but not conflicting)
  • Shift+Enter (rather not since enter implies you would execute the transform, but seems its not taken)

overall insert seems best option to me.

codemanx added a comment.EditedFeb 26 2014, 2:55 PM

I suggest to bind two keys:

  • accent grave (´ key)
  • circumflex accent (^)

Accent grave is the key on the lefthand-side of 1 and above Tab, so is the circumflex accent on german keyboard for instance. These keys are often used in games for the ingame console, so make a bit of sense to use here.

Circumflex accent gives an instant keydown event, but the OS (at least Windows) doesn't insert a ^ character. Instead, it waits for another keystroke, and if applicable, turns a A into Â. This might be problematic in our scenario, as you would hit ^ and enter an expression - it might insert ^ + the character you types or a special char like Â. I'm not sure if Blender could consume the key stroke, so that there's no buffered ^ on OS side...

Another problem is that ^ is a valid character in a python expression (xor and used with sets). But it should be acceptable, as no one will seriously use sets in num modal expressions, and binary operations don't seem much useful either. The user could change keybindings if neccessary.

Here's a little python script that waits for ´ and ^ key strokes:

As you can see, event.unicode / event.ascii is empty on the first ^, but ^ if you hit it twice. If you hit ^ once, click with RMB to quit modal operator and type into PyConsole, it will insert the buffered ^! Can C code handle this differently? (suppress OS from buffering it, only read the direct keystroke events)

'Insert' Key does not exist on osx.

I still would find = the best and most logical solution. What speaks against make = work no matter if it's a dedicated key or Key-combo like shift+0? Can't we handle those eventualities?

You can check the actual character in Python (and surely in C as well) of the event (event.ascii, event.unicode), but there is no such options for key mappings.

If you try to bind = on german keyboard, it will bind Shift+0. That combo could be used as a second binding (= as first).

Why not simply bind it to 'F' key or similar, it would be very handy and it will avoid keyboard conflicts.

Thank you

@Campbell Barton (campbellbarton): I would rather use ctrl-space... At least I can be 99,99% sure *this* combo is available and working with all keyboards on the planet… INSERT is often hidden behind the 'Fn' key on laptops e.g. (and Apple might also decide some day it’s not a useful key, and drop it as it seems they did with the numpad).

But to really fix this ugly issue, we should simply drop all those hard-coded shortcuts and use a nice modal keymap. Not for 2.70, though.

@Bastien Montagne (mont29)

even though I suggested it. ctrl+space has the problem that tapping control enables snap (until the mouse moves), which is a bit of a glitch in transform, even if ctrl release worked pressing ctrl would still flicker snapping on/off.

Think codemanx's suggestion is a good choice, we already use accent grave key for displaying all layers.

Bastien Montagne (mont29) closed this task as Resolved.Feb 27 2014, 9:53 AM

Fixed by checking agains ascii code instead of pre-defined events (so still using = or *)... rB17d2e6422cfa

Works great, thank you Bastien.