Change modal number input to press key before activating expressions #38662

New Issue

Brecht Van Lommel · 2014-02-16T17:03:19+01:00

Brecht Van Lommel commented

2014-02-16 17:03:19 +01:00

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.

Regarding [D61: Support units in modal numinput](https://archive.blender.org/developer/D61). 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.

Brecht Van Lommel commented

2014-02-16 17:03:19 +01:00

Changed status to: 'Open'

Brecht Van Lommel commented

2014-02-16 17:03:19 +01:00

Added subscribers: @brecht, @JonathanWilliamson, @ideasman42, @mont29

Brecht Van Lommel commented

2014-02-16 17:05:52 +01:00

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

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

JT Nelson commented

2014-02-16 18:35:29 +01:00

Added subscriber: @jta

JT Nelson commented

2014-02-16 18:35:29 +01:00

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

Yousef Harfoush commented

2014-02-16 19:41:01 +01:00

Added subscriber: @bat3a

Yousef Harfoush commented

2014-02-16 19:41:01 +01:00

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.

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.

Paolo Sourvinos commented

2014-02-16 21:02:12 +01:00

Added subscriber: @sourvinos

Paolo Sourvinos commented

2014-02-16 21:02:12 +01:00

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.

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 commented

2014-02-16 22:52:14 +01:00

Added subscriber: @CodeManX

CodeManX commented

2014-02-16 22:52:14 +01:00

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 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?

Yousef Harfoush commented

2014-02-17 00:30:04 +01:00

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.

``` 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.

Campbell Barton commented

2014-02-17 02:09:03 +01:00

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

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

Sv. Lockal commented

2014-02-17 05:58:46 +01:00

Added subscriber: @Lockal

LY commented

2014-02-17 09:57:52 +01:00

(Migrated from localhost:3001)

Added subscriber: @LY

LY commented

2014-02-17 09:57:52 +01:00

(Migrated from localhost:3001)

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.

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.

Adrian Rutkowski commented

2014-02-17 11:41:26 +01:00

Added subscriber: @niewinny

Adrian Rutkowski commented

2014-02-17 11:41:26 +01:00

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.

Campbell Barton commented

2014-02-17 11:46:27 +01:00

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

@LY - as has been stated, **Tab** is already used to switch transform axis.

Jonathan Williamson commented

2014-02-17 15:56:37 +01:00

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.

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.

Brecht Van Lommel commented

2014-02-17 16:09:21 +01:00

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.

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.

Jonathan Williamson commented

2014-02-17 16:14:11 +01:00

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

Paolo Sourvinos commented

2014-02-17 16:19:44 +01:00

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

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

Yousef Harfoush commented

2014-02-18 01:15:16 +01:00

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.

``` 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 Barton commented

2014-02-18 04:47:57 +01:00

@bat3a - http://wiki.blender.org/index.php/User:Fade/Doc:2.6/Manual/3D_interaction/Transform_Control/Numeric_Input

Yousef Harfoush commented

2014-02-18 06:16:51 +01:00

@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.

@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.

Yousef Harfoush commented

2014-02-18 06:20:42 +01:00

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

Campbell Barton commented

2014-02-18 06:56:39 +01:00

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

Yousef Harfoush commented

2014-02-18 07:04:16 +01:00

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

Campbell Barton commented

2014-02-18 08:33:44 +01:00

@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.

Matjaž Lamut commented

2014-02-18 14:45:52 +01:00

Added subscriber: @lamoot

Matjaž Lamut commented

2014-02-18 14:45:52 +01:00

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 http://en.wikipedia.org/wiki/Keyboard_layout and there are a lot of layouts that directly access = symbol, for example Arabic, Chinese layouts, Korean, Russian, Hebrew, Greek, AZERTY, Dvorak.

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 http://en.wikipedia.org/wiki/Keyboard_layout and there are a lot of layouts that directly access = symbol, for example Arabic, Chinese layouts, Korean, Russian, Hebrew, Greek, AZERTY, Dvorak.

Matjaž Lamut commented

2014-02-18 14:52:41 +01:00

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.

Yousef Harfoush commented

2014-02-19 01:18:39 +01:00

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.

``` 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.

Bastien Montagne commented

2014-02-19 15:43:57 +01:00

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.

Bastien Montagne commented

2014-02-19 17:54:22 +01:00

See D332...

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

See [D332](https://archive.blender.org/developer/D332)... Please note I have to leave now, online again next saturday hopefully.

Campbell Barton commented

2014-02-20 06:17:16 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-02-20 06:17:16 +01:00

Campbell Barton self-assigned this 2014-02-20 06:17:16 +01:00

Campbell Barton commented

2014-02-20 06:17:16 +01:00

Committed D332 Bastien 32d6f853f3

closing.

Committed [D332](https://archive.blender.org/developer/D332) Bastien 32d6f853f3 closing.

Henrik Aarnio commented

2014-02-21 10:35:44 +01:00

Added subscriber: @hjaarnio

Henrik Aarnio commented

2014-02-21 10:35:44 +01:00

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.

Bastien Montagne commented

2014-02-22 12:25:09 +01:00

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

Paolo Sourvinos commented

2014-02-22 16:19:54 +01:00

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
paolo

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 paolo

Matjaž Lamut commented

2014-02-26 12:33:39 +01:00

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 blender.org 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?

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 blender.org 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?

CodeManX commented

2014-02-26 12:42:24 +01:00

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 +

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 `+`

Campbell Barton commented

2014-02-26 12:59:46 +01:00

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.

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.

Campbell Barton commented

2014-02-26 13:05:40 +01:00

Changed status from 'Resolved' to: 'Open'

Campbell Barton reopened this issue

2014-02-26 13:05:40 +01:00

Sebastian Röthlisberger commented

2014-02-26 13:14:32 +01:00

Added subscriber: @SebastianRothlisberger

CodeManX commented

2014-02-26 14:55:28 +01:00

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.

Drawbacks:
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:

http://www.pasteall.org/49847/python

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)

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. Drawbacks: 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: http://www.pasteall.org/49847/python 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)

Sebastian Röthlisberger commented

2014-02-26 15:48:38 +01:00

'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?

'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?

CodeManX commented

2014-02-26 16:56:26 +01:00

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).

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).

Paolo Sourvinos commented

2014-02-26 17:05:46 +01:00

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

Thank you

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 was unassigned by Bastien Montagne

2014-02-26 22:51:00 +01:00

Bastien Montagne self-assigned this 2014-02-26 22:51:00 +01:00

Bastien Montagne commented

2014-02-26 22:51:00 +01:00

@ideasman42: 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.

@ideasman42: 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.

Campbell Barton commented

2014-02-27 00:19:07 +01:00

@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.

@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 commented

2014-02-27 09:53:11 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2014-02-27 09:53:11 +01:00

Bastien Montagne commented

2014-02-27 09:53:11 +01:00

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

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

Sebastian Röthlisberger commented

2014-02-27 14:57:03 +01:00

Works great, thank you Bastien.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Change modal number input to press key before activating expressions #38662