Expressions during Grab don't work as expected #74163

New Issue

Denis Russkih · 2020-02-24T13:48:26+01:00

Denis Russkih commented

2020-02-24 13:48:26 +01:00

System Information
Operating system: Linux-4.15.0-39-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 690/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 435.21

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: blender/blender@77d23b0bd7

Short description of error
Blender supports expressions during transform operations (for example, I can enter (15+7)/2instead of calculating it manually), but this feature have realized in a very strange way. I had problems with just entering proper expression during Grab. I found the solution, but it is really strange and counterintuitive.Exact steps for others to reproduce the error
Excuse me for my English, it isn't my mother tongue.
Start Blender, select the default Cube, press G, press Y, then try to enter 15/2
You will see 1/152 instead. This happens because /key switches betweenxand1/xmode. If you press**/again, you will see152**. If you press /again, you will see 1/152. And so on.
Press Esc, then press G and Y again. Try to enter 15+7. You will see 157. This is really confusing.
If you a newbie, you can think that Blender just doesn't support expressions, and you must come to terms with inevitable.
Keep trying. Press Esc, then press G and Y again. Try to enter 15*3. You will see 153. The last ray of hope has gone and darkness has surrounded you. But don't give up. Enter /2and you will see153/2. What? It is a miracle! Now you can enter expressions as you wish. Press and hold Backspace, then enter 15/3 and you will see 15/3, as you expected.
But if you now press Esc, G, Y, and then try to enter 15/3, you will see 153 again.
So, it dawned on you that the hotkey switches betweenno expressionandexpression* mode.

**System Information** Operating system: Linux-4.15.0-39-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GTX 690/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 435.21 **Blender Version** Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `blender/blender@77d23b0bd7` **Short description of error** Blender supports expressions during transform operations (*for example, I can enter **(15+7)/2**instead of calculating it manually*), but this feature have realized in a very strange way. I had problems with just entering proper expression during Grab. I found the solution, but it is really strange and counterintuitive.**Exact steps for others to reproduce the error** Excuse me for my English, it isn't my mother tongue. Start Blender, select the default Cube, press **G**, press **Y**, then try to enter **15/2** You will see **1/152** instead. This happens because **/**key switches between**x**and**1/x**mode. If you press**/**again, you will see**152**. If you press **/**again, you will see** 1/152**. And so on. Press **Esc**, then press **G** and **Y** again. Try to enter **15+7**. You will see **157**. This is really confusing. If you a newbie, you can think that Blender just doesn't support expressions, and you must come to terms with inevitable. Keep trying. Press **Esc**, then press **G** and **Y** again. Try to enter **15*3**. You will see **153**. The last ray of hope has gone and darkness has surrounded you. But don't give up. Enter **/2**and you will see**153/2**. What? It is a miracle! Now you can enter expressions as you wish. Press and hold **Backspace**, then enter **15/3** and you will see **15/3**, as you expected. But if you now press Esc, G, Y, and then try to enter **15/3**, you will see **153** again. So, it dawned on you that the *****hotkey switches between**no expression**and**expression** mode.

Denis Russkih commented

2020-02-24 13:48:26 +01:00

Added subscriber: @denis_russkih

Demeter Dzadik commented

2020-02-25 12:29:57 +01:00

Added subscriber: @Mets

Germano Cavalcante commented

2020-02-26 11:59:49 +01:00

Added subscribers: @WilliamReynish, @mano-wii

Germano Cavalcante commented

2020-02-26 11:59:49 +01:00

In fact, with nothing indicating on the interface that the hotkey {key*} changes between no expression and expression mode, it is very difficult for the user to find out.
Changing the behavior to use with expression by default would not be the best solution since users are used to, for example, changing the signal just by pressing {key-}
And I'm also not sure if the {key *} hotkey is the best choice.

This is something that needs to be studied.

@WilliamReynish, would this be a reasonable task for the User Interface Module?

In fact, with nothing indicating on the interface that the hotkey {key*} changes between **no expression** and **expression** mode, it is very difficult for the user to find out. Changing the behavior to use **with expression** by default would not be the best solution since users are used to, for example, changing the signal just by pressing {key-} And I'm also not sure if the {key *} hotkey is the best choice. This is something that needs to be studied. @WilliamReynish, would this be a reasonable task for the `User Interface Module`?

Denis Russkih commented

2020-02-27 09:24:36 +01:00

In #74163#880609, @mano-wii wrote:
Changing the behavior to use with expression by default would not be the best solution since users are used to, for example, changing the signal just by pressing {key-}

How about this solution:

Expressions turned on by default.
The Space key changes between x and *(-1)x mode.
The Alt or Ctrl key changes between x and 1/x mode.
(x is an expression)

By the way, today you can't switch back to no expression mode when you pressed once. The solution that I propose can solve this problem. We just don't needno expressionmode anymore, just by assign another hotkeys tono expression* features.

If you care about numpad users, you can also assign Page Up key as alternative for Space key, and assign Page Down as alternative for Alt.

> In #74163#880609, @mano-wii wrote: > Changing the behavior to use **with expression** by default would not be the best solution since users are used to, for example, changing the signal just by pressing {key-} How about this solution: 1. Expressions turned on by default. 2. The **Space** key changes between **x** and **(-1)*x** mode. 3. The **Alt** or **Ctrl** key changes between **x** and **1/x** mode. (**x** is an expression) By the way, today you can't switch back to **no expression** mode when you pressed *****once. The solution that I propose can solve this problem. We just don't need**no expression**mode anymore, just by assign another hotkeys to**no expression** features. If you care about numpad users, you can also assign **Page Up** key as alternative for **Space** key, and assign **Page Down** as alternative for **Alt**.

Ankit Meel commented

2020-04-05 10:39:37 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2020-04-05 10:39:37 +02:00

https://docs.blender.org/manual/en/latest/interface/controls/buttons/fields.html
It either needs to be documented or hinted about, somewhere in the UI.
Can't say that it's a bug. Code is working as it was ~~written~~ intended.

https://docs.blender.org/manual/en/latest/interface/controls/buttons/fields.html It either needs to be documented or hinted about, somewhere in the UI. Can't say that it's a bug. Code is working as it was ~~written~~ intended.

Denis Russkih commented

2020-04-15 12:24:21 +02:00

In #74163#903754, @ankitm wrote:
Can't say that it's a bug. Code is working as it was written.

But you can't switch back to no expression mode if you switched to expression mode. Also, this way is extremely counterintuitive, and not so many users read all manuals. Looks like a small font paragraph in a contract.
IMHO, this is not a code bug, but this is an architecture and interface bug. Imagine that you wrote a simple Calc application, but there is no Plus button, only Minus. (You forgot to add Plus.) The code is working as it was written, all code is correct. But there is a bug.

> In #74163#903754, @ankitm wrote: > Can't say that it's a bug. Code is working as it was written. But you can't switch back to **no expression** mode if you switched to **expression** mode. Also, this way is extremely counterintuitive, and not so many users read all manuals. Looks like a small font paragraph in a contract. IMHO, this is not a code bug, but this is an architecture and interface bug. Imagine that you wrote a simple Calc application, but there is no Plus button, only Minus. (You forgot to add Plus.) The code is working as it was written, all code is correct. But there is a bug.

Denis Russkih commented

2020-04-25 12:55:36 +02:00

In #74163#903754, @ankitm wrote:
Can't say that it's a bug. Code is working as it was ~~written~~ intended.

In fact, this is an absolutely usability nighmare. This part of UI is not intuitive, it was designed for aliens.
Maybe we need to create a vote, to find out opinions of users. I am sure that many will agree with me.

> In #74163#903754, @ankitm wrote: > Can't say that it's a bug. Code is working as it was ~~written~~ intended. In fact, this is an absolutely usability nighmare. This part of UI is not intuitive, it was designed for aliens. Maybe we need to create a vote, to find out opinions of users. I am sure that many will agree with me.

Ankit Meel commented

2020-04-25 13:23:45 +02:00

https://docs.blender.org/manual/en/2.82/scene_layout/object/editing/transform/control/numeric_input.html

Ankit Meel commented

2020-04-25 14:05:28 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Ankit Meel closed this issue

2020-04-25 14:05:28 +02:00

Ankit Meel self-assigned this 2020-04-25 14:05:28 +02:00

Ankit Meel commented

2020-04-25 14:05:28 +02:00

Also, there's Preferences > Input > default to advanced Numeric input.
The current behaviour is documented and working as it was designed. For further Design discussions, Bug tracker isn't the right place.

Also, there's Preferences > Input > default to advanced Numeric input. The current behaviour is documented and working as it was designed. For further Design discussions, Bug tracker isn't the right place.

Denis Russkih commented

2020-04-29 20:02:41 +02:00

In #74163#917497, @ankitm wrote:
https://docs.blender.org/manual/en/2.82/scene_layout/object/editing/transform/control/numeric_input.html

In #74163#917516, @ankitm wrote:
Also, there's Preferences > Input > default to advanced Numeric input.

Thanks! I didn't know that Ctrl+= allows to switch back to Simple mode. Also, I didn't know about the checkbox in Preferences. That's good, I like it.
Sorry to wasted your time for this thread. In fact, Blender already has all that I was need.

> In #74163#917497, @ankitm wrote: > https://docs.blender.org/manual/en/2.82/scene_layout/object/editing/transform/control/numeric_input.html > In #74163#917516, @ankitm wrote: > Also, there's Preferences > Input > default to advanced Numeric input. Thanks! I didn't know that **Ctrl+=** allows to switch back to Simple mode. Also, I didn't know about the checkbox in Preferences. That's good, I like it. Sorry to wasted your time for this thread. In fact, Blender already has all that I was need.

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

Expressions during Grab don't work as expected #74163