Writing guideline for the status bar text #117546

New Issue

Damien Picard · 2024-01-26T14:58:28+01:00

Damien Picard commented

2024-01-26 14:58:28 +01:00

The status bar is used to display information on the current state. Mostly, it shows the available keys for the active tool.

Keys can be shown using multiple systems. The first one adds buttons with icons for each key, and is the default when no tool is active.

The other simply prints text to the status bar:

There doesn’t seem to be a consensus as to how these texts are formatted, resulting in inconsistency across tools. I’d like to make a proposition for a format, the goal being to add it to the writing guidelines afterwards.

Proposed format

<Tool name or short description>: <Key1>: <Action 1>, <Key2/Key3>: <Action 2>

The active tool name should be visible, if the user isn’t sure which key they pressed or what tool they invoked.
The text should contain simple key bindings instead of sentences.
Settings should be title case.
Some messages delimitate bindings using commas “,”, others pipes “|”. I propose using commas everywhere.
Similarly, the option name and key are separated using colons “:”, dashes “-”, or simple spaces. I propose using colons.
Keys should use the same abbreviations as the keymap items, such as LMB instead of left click.
Some texts use brackets to mean a togglable value is on, such as [E] - Disable overshoot and [E] - Enable overshoot. Others use parentheses such as midpoint snap (ON) and midpoint snap (OFF). The latter has the advantage that it can express values with more than two possible states, e.g. OFF/X/Y/Z, so I think it’s preferable. If the brackets solution is used, it should read [E]: Overshoot / E: Overshoot because it makes the UI less jumpy.

Examples

Before	After
`Fill: ESC/RMB cancel, LMB Fill, Shift Draw on Back, MMB Adjust Extend`	`Fill: Esc/RMB: Cancel, LMB: Fill, Shift: Draw on Back, MMB: Adjust Extend`
`%s: confirm, %s: cancel, %s: undo, %s: start/define cut, %s: close cut, %s: new cut`	`Knife Cut: %s: Confirm, %s: Cancel, %s: Undo, %s: Start/Define Cut, %s: Close Cut, %s: New Cut`
`Select a ring to be cut, use mouse-wheel or page-up/down for number of cuts, hold Alt for smooth`	`Loop Cut: Esc/RMB: Cancel, LMB: Confirm, WhUp/WhDown/PgUp/PgDown: Number of Cuts, Alt: Smooth`
`Annotation Create Poly: LMB click to place next stroke vertex \| ESC/Enter to end (or click outside this area)`	`Annotation Create Poly: LMB: Place Next Stroke Vertex, Esc/Enter/RMB/LMB outside this area: End`
`Breakdown: [E] - Disable overshoot, [Shift] - Precision active \| [Ctrl] - Increments active`	`Breakdown: E: Overshoot (ON), Shift: Precision Mode (ON), Ctrl: 10% Increments (ON)`
`Breakdown: [E] - Enable overshoot, Shift - Hold for precision \| Ctrl - Hold for 10% increments`	`Breakdown: E: Overshoot (OFF), Shift: Precision Mode (OFF), Ctrl: 10% Increments (OFF)`

This issue was raised by @mont29 in #117234 while looking at which translation settings should be used for the status bar.

The status bar is used to display information on the current state. Mostly, it shows the available keys for the active tool. Keys can be shown using multiple systems. The first one adds buttons with icons for each key, and is the default when no tool is active. ![image](/attachments/c001b180-be0e-4616-9e9a-0b45d2f11f90) The other simply prints text to the status bar: ![image](/attachments/a57c4bf4-b76d-4869-b56b-06c22a6ee140) ![image](/attachments/c1218113-3ece-4ff3-91d7-f003ff0d83e4) ![image](/attachments/c88550c4-18a3-4f0c-ad83-0df4ac6d7bfe) There doesn’t seem to be a consensus as to how these texts are formatted, resulting in inconsistency across tools. I’d like to make a proposition for a format, the goal being to add it to the writing guidelines afterwards. ## Proposed format `<Tool name or short description>: <Key1>: <Action 1>, <Key2/Key3>: <Action 2>` - The active tool name should be visible, if the user isn’t sure which key they pressed or what tool they invoked. - The text should contain simple key bindings instead of sentences. - Settings should be title case. - Some messages delimitate bindings using commas “,”, others pipes “|”. I propose using commas everywhere. - Similarly, the option name and key are separated using colons “:”, dashes “-”, or simple spaces. I propose using colons. - Keys should use the same abbreviations as the keymap items, such as LMB instead of left click. - Some texts use brackets to mean a togglable value is on, such as `[E] - Disable overshoot` and `[E] - Enable overshoot`. Others use parentheses such as `midpoint snap (ON)` and `midpoint snap (OFF)`. The latter has the advantage that it can express values with more than two possible states, e.g. `OFF/X/Y/Z`, so I think it’s preferable. If the brackets solution is used, it should read `[E]: Overshoot` / `E: Overshoot` because it makes the UI less jumpy. ## Examples | Before | After | | -------- | -------- | | `Fill: ESC/RMB cancel, LMB Fill, Shift Draw on Back, MMB Adjust Extend` | `Fill: Esc/RMB: Cancel, LMB: Fill, Shift: Draw on Back, MMB: Adjust Extend` | | `%s: confirm, %s: cancel, %s: undo, %s: start/define cut, %s: close cut, %s: new cut` | `Knife Cut: %s: Confirm, %s: Cancel, %s: Undo, %s: Start/Define Cut, %s: Close Cut, %s: New Cut` | | `Select a ring to be cut, use mouse-wheel or page-up/down for number of cuts, hold Alt for smooth` | `Loop Cut: Esc/RMB: Cancel, LMB: Confirm, WhUp/WhDown/PgUp/PgDown: Number of Cuts, Alt: Smooth` | | `Annotation Create Poly: LMB click to place next stroke vertex \| ESC/Enter to end (or click outside this area)` | `Annotation Create Poly: LMB: Place Next Stroke Vertex, Esc/Enter/RMB/LMB outside this area: End` | | `Breakdown: [E] - Disable overshoot, [Shift] - Precision active \| [Ctrl] - Increments active` | `Breakdown: E: Overshoot (ON), Shift: Precision Mode (ON), Ctrl: 10% Increments (ON)` | | `Breakdown: [E] - Enable overshoot, Shift - Hold for precision \| Ctrl - Hold for 10% increments` | `Breakdown: E: Overshoot (OFF), Shift: Precision Mode (OFF), Ctrl: 10% Increments (OFF)` | ----- This issue was raised by @mont29 in #117234 while looking at which translation settings should be used for the status bar.

image.png

6.1 KiB

image.png

6.1 KiB

image.png

7.4 KiB

image.png

8.8 KiB

👍 1

Damien Picard added the

labels 2024-01-26 14:58:29 +01:00

Nika Kutsniashvili commented

2024-01-26 18:41:46 +01:00

Modifier keys for some operators are really long line and sometimes hardly fit in the status bar. Especially on laptops or with high scaling UI.

Having operator names in there will make it unusable and will hide most of the keys. Some sculpt operators already cant fully display keys and need shortening

Modifier keys for some operators are really long line and sometimes hardly fit in the status bar. Especially on laptops or with high scaling UI. Having operator names in there will make it unusable and will hide most of the keys. Some sculpt operators already cant fully display keys and need shortening

Bastien Montagne commented

2024-02-05 12:55:23 +01:00

@JulianEisel @pablovazquez think this makes sense?

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

Writing guideline for the status bar text #117546

Proposed format

Examples