# [UI Bug] Missing Underscore and Inconsistent Button Backgrounds in Navigation Bar at SpikerSoft Stacker #1141

New Issue

2026-09-14T02:12:25Z

enjin2310 commented

2026-09-14 02:12:25 +00:00

Summary

In SpikerSoft Stacker, several buttons in the top navigation bar are missing underscores and display inconsistent background colors. This creates visual inconsistency and may mislead users into thinking that certain buttons are inactive or disabled, even though they remain fully functional.

Issue Description

Buttons such as Crop, Touch Up, and Finish lack the underscore character used for keyboard shortcuts or visual uniformity. Additionally, their background color differs slightly from other active buttons, giving the impression that interaction is blocked. Despite this, the buttons work correctly when clicked, indicating a purely visual issue.

Environment

Property	Value
Application	SpikerSoft Stacker
Module	Navigation Bar
Environment	Production
Operating System	Windows 11
Version	v2026.09.13
Device	Desktop

Preconditions

User must have the application open and visible navigation bar.

Steps to Reproduce

Open SpikerSoft Stacker.
Observe the top navigation bar.
Compare the visual appearance of buttons such as Crop, Touch Up, and Finish with others like Align or Stack.
Note the missing underscores and slightly different background color.

Expected Result

All navigation buttons should:

Display consistent background colors.
Include underscores for keyboard shortcut indicators.
Clearly communicate active and interactive states.

Actual Result

Crop, Touch Up, and Finish buttons lack underscores.
Their background color appears slightly faded compared to other buttons.
The visual design suggests they are inactive, though they remain functional.

Evidence

The screenshot shows the navigation bar with inconsistent button styling and missing underscores.

Impact

Reduces visual consistency and professional polish.
May confuse users about button functionality.
Minor accessibility and usability degradation.

Frequency

Always

Reproducibility

100%

Severity

Low

## Summary In **SpikerSoft Stacker**, several buttons in the top navigation bar are missing underscores and display inconsistent background colors. This creates visual inconsistency and may mislead users into thinking that certain buttons are inactive or disabled, even though they remain fully functional. ## Issue Description Buttons such as **Crop**, **Touch Up**, and **Finish** lack the underscore character used for keyboard shortcuts or visual uniformity. Additionally, their background color differs slightly from other active buttons, giving the impression that interaction is blocked. Despite this, the buttons work correctly when clicked, indicating a purely visual issue. ## Environment | Property | Value | |-----------|--------| | Application | SpikerSoft Stacker | | Module | Navigation Bar | | Environment | Production | | Operating System | Windows 11 | | Version | v2026.09.13 | | Device | Desktop | ## Preconditions User must have the application open and visible navigation bar. ## Steps to Reproduce 1. Open **SpikerSoft Stacker**. 2. Observe the top navigation bar. 3. Compare the visual appearance of buttons such as **Crop**, **Touch Up**, and **Finish** with others like **Align** or **Stack**. 4. Note the missing underscores and slightly different background color. ## Expected Result All navigation buttons should: - Display consistent background colors. - Include underscores for keyboard shortcut indicators. - Clearly communicate active and interactive states. ## Actual Result - **Crop**, **Touch Up**, and **Finish** buttons lack underscores. - Their background color appears slightly faded compared to other buttons. - The visual design suggests they are inactive, though they remain functional. ## Evidence - The screenshot shows the navigation bar with inconsistent button styling and missing underscores. ## Impact - Reduces visual consistency and professional polish. - May confuse users about button functionality. - Minor accessibility and usability degradation. ## Frequency Always ## Reproducibility 100% ## Severity Low

WhatsApp 9_13_2026 10_06_23 PM.png

2.7 MiB

enjin2310 changed title from ~~# [UI Bug] Missing Underscore and Inconsistent Button Backgrounds in Navigation Bar~~ to # [UI Bug] Missing Underscore and Inconsistent Button Backgrounds in Navigation Bar at SpikerSoft Stacker

2026-09-14 02:25:39 +00:00

spikerj commented

2026-09-21 04:18:35 +00:00

Working as designed — both things you noticed are deliberate state indicators on the step ribbon, not styling defects. Closing, but there is a real legibility point in here worth separating out (bottom).

The "missing underscore" is the done marker

It is not a keyboard-shortcut mnemonic. theme.rs::step_tab paints a line under the label only for a completed stage:

if state == StepState::Done {
    ui.painter().line_segment([...], Stroke::new(2.0, ACCENT));
}

Crop, Touch Up and Finish had no underline because their output does not exist yet. Capture and Frames had one because theirs did.

The background difference is the locked state

The ribbon has four states, each with its own fill (step_colors):

state	fill	meaning
Current	`ACCENT`	the stage on screen
Done	`rgb(40,44,52)`	its output exists
Ready	`rgb(30,33,39)`	reachable, not current
Locked	none — flat, frameless	prerequisites missing

So "background color differs slightly… giving the impression that interaction is blocked" is exactly right: interaction is blocked. Locked tabs go through ui.add_enabled(false, …) and carry a hover explaining what unlocks them, e.g. for Crop:

Align the frames first — the crop is defined in reference space

One correction

Despite this, the buttons work correctly when clicked, indicating a purely visual issue.

A locked tab is genuinely disabled — add_enabled(false, …) means egui never reports a click, so it cannot have been acting on those presses. Two likely explanations: the stages were actually Ready rather than Locked in that session (Ready is also dimmer than Current, which would match "differs slightly" without being blocked), or the clicks that appeared to work were on a different tab. Either way there is nothing here that is visual-only.

The part worth keeping

A QA tester reading the ribbon as "broken buttons" rather than "steps I have not unlocked yet" is a legitimate signal — if the affordance did not read to you, it may not read to users either. The information is all present (dimmed fill, no underline, hover text) but it is discoverable only on hover, and hover does not exist on touch.

That is a UX question rather than a defect, so I have not changed anything. Happy to open a separate ticket for making locked steps self-explanatory without hover — a lock glyph, or the reason shown inline in the panel — if you think it is worth it.

Working as designed — both things you noticed are deliberate state indicators on the step ribbon, not styling defects. Closing, but there is a real legibility point in here worth separating out (bottom). ## The "missing underscore" is the *done* marker It is not a keyboard-shortcut mnemonic. `theme.rs::step_tab` paints a line under the label **only** for a completed stage: ```rust if state == StepState::Done { ui.painter().line_segment([...], Stroke::new(2.0, ACCENT)); } ``` Crop, Touch Up and Finish had no underline because their output does not exist yet. Capture and Frames had one because theirs did. ## The background difference is the *locked* state The ribbon has four states, each with its own fill (`step_colors`): | state | fill | meaning | | --- | --- | --- | | Current | `ACCENT` | the stage on screen | | Done | `rgb(40,44,52)` | its output exists | | Ready | `rgb(30,33,39)` | reachable, not current | | **Locked** | *none — flat, frameless* | prerequisites missing | So "background color differs slightly… giving the impression that interaction is blocked" is exactly right: interaction **is** blocked. Locked tabs go through `ui.add_enabled(false, …)` and carry a hover explaining what unlocks them, e.g. for Crop: > Align the frames first — the crop is defined in reference space ## One correction > Despite this, the buttons work correctly when clicked, indicating a purely visual issue. A locked tab is genuinely disabled — `add_enabled(false, …)` means egui never reports a click, so it cannot have been acting on those presses. Two likely explanations: the stages were actually **Ready** rather than Locked in that session (Ready is also dimmer than Current, which would match "differs slightly" without being blocked), or the clicks that appeared to work were on a different tab. Either way there is nothing here that is visual-only. ## The part worth keeping A QA tester reading the ribbon as "broken buttons" rather than "steps I have not unlocked yet" is a legitimate signal — if the affordance did not read to you, it may not read to users either. The information is all present (dimmed fill, no underline, hover text) but it is discoverable only on hover, and hover does not exist on touch. That is a UX question rather than a defect, so I have not changed anything. Happy to open a separate ticket for making locked steps self-explanatory without hover — a lock glyph, or the reason shown inline in the panel — if you think it is worth it.

spikerj closed this issue

2026-09-21 04:18:35 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#1141