RabbitLabs/calculator
Watch
5
0
Fork
You've already forked calculator
 0
Code Issues 20 Pull requests 2 Projects 1 Releases Packages Wiki Activity Actions

Design scientific view #14

New issue
Open
opened 2025-09-20 12:58:34 +01:00 by Vylpes · 7 comments
Vylpes commented 2025-09-20 12:58:34 +01:00
Owner
Copy link

Epic: #12
Story Points: 8

AS a designer, I want a design made for the scientific calculator GUI view
SO THAT developers can implement an expanded calculator layout with scientific functions

Acceptance Criteria

GIVEN the default GUI design delivered in #13
WHEN I create the scientific view design
THEN the mockup reuses the same visual language (colours, typography, spacing, button styling) as #13

GIVEN the application has a standard calculator view (#13)
WHEN the scientific view design is complete
THEN the design documents how the user switches between standard and scientific modes (control placement, labels, and resulting layout change)

GIVEN the scientific view design is complete
WHEN a developer reviews the mockup
THEN every button and control in the scientific layout is labelled and its purpose is unambiguous

GIVEN the scientific view design is complete
WHEN the mockup is attached to this issue
THEN the layout is detailed enough for a developer to implement the GTK window without further design clarification (window dimensions, button grid, display area)

GIVEN the scientific view design is complete
WHEN compared to the current basic GUI (src/gui.rs — digits 0–9, ., C, +, -, *, /, =)
THEN the scientific layout includes additional controls beyond the standard four-function keypad (e.g. trigonometric, logarithmic, power/root, constants, or other scientific operations — exact set documented in the mockup)

GIVEN the scientific view design is complete
WHEN the standard mode is shown in the deliverable
THEN the standard view matches (or is shown alongside) the #13 design so developers know both layouts

Subtasks

  • Create scientific view mockup (expanded button grid and display)
  • Document standard ↔ scientific mode switch interaction
  • Show both standard and scientific layouts in the deliverable (side-by-side or separate frames)
  • Attach mockup image(s) to this issue (same deliverable format as #13)

Notes

  • Epic: #12 (Design)
  • No milestone for now — work in a future version (per @Vylpes, 2026-09-08)
  • GUI only; CLI scientific notation / expression syntax is out of scope for this design story
  • Future engine stories (#25 brackets, #26 indices, #27 variables) are not required for this design, but the mockup may optionally reserve space for ( ) or variable keys if the designer chooses
  • Implementation of scientific evaluation logic is a separate story; this issue covers design only, matching the scope of #13
Epic: #12 Story Points: 8 --- AS a designer, I want a design made for the scientific calculator GUI view SO THAT developers can implement an expanded calculator layout with scientific functions ## Acceptance Criteria GIVEN the default GUI design delivered in #13 WHEN I create the scientific view design THEN the mockup reuses the same visual language (colours, typography, spacing, button styling) as #13 GIVEN the application has a standard calculator view (#13) WHEN the scientific view design is complete THEN the design documents how the user switches between standard and scientific modes (control placement, labels, and resulting layout change) GIVEN the scientific view design is complete WHEN a developer reviews the mockup THEN every button and control in the scientific layout is labelled and its purpose is unambiguous GIVEN the scientific view design is complete WHEN the mockup is attached to this issue THEN the layout is detailed enough for a developer to implement the GTK window without further design clarification (window dimensions, button grid, display area) GIVEN the scientific view design is complete WHEN compared to the current basic GUI (`src/gui.rs` — digits 0–9, `.`, `C`, `+`, `-`, `*`, `/`, `=`) THEN the scientific layout includes additional controls beyond the standard four-function keypad (e.g. trigonometric, logarithmic, power/root, constants, or other scientific operations — exact set documented in the mockup) GIVEN the scientific view design is complete WHEN the standard mode is shown in the deliverable THEN the standard view matches (or is shown alongside) the #13 design so developers know both layouts ## Subtasks - [ ] Create scientific view mockup (expanded button grid and display) - [ ] Document standard ↔ scientific mode switch interaction - [ ] Show both standard and scientific layouts in the deliverable (side-by-side or separate frames) - [ ] Attach mockup image(s) to this issue (same deliverable format as #13) ## Notes - Epic: #12 (Design) - **No milestone** for now — work in a future version (per @Vylpes, 2026-09-08) - GUI only; CLI scientific notation / expression syntax is out of scope for this design story - Future engine stories (#25 brackets, #26 indices, #27 variables) are not required for this design, but the mockup may optionally reserve space for `( )` or variable keys if the designer chooses - Implementation of scientific evaluation logic is a separate story; this issue covers **design only**, matching the scope of #13
Vylpes added this to the 0.1.0 milestone 2025-09-20 12:58:34 +01:00
Vylpes commented 2025-10-07 10:42:02 +01:00
Author
Owner
Copy link

Do we need this still?

Do we need this still?
Vylpes commented 2025-10-20 12:19:57 +01:00
Author
Owner
Copy link

@Vylpes wrote in #14 (comment):

Do we need this still?

Not for now

@Vylpes wrote in https://git.vylpes.xyz/RabbitLabs/calculator/issues/14#issuecomment-18192: > Do we need this still? Not for now
Vylpes removed this from the 0.1.0 milestone 2025-10-20 12:20:06 +01:00
Vylpes commented 2026-09-08 10:57:38 +01:00
Author
Owner
Copy link

@Smithy-bot Plan this but don't give it a milestone for now, we'll work on it in a future version

@Smithy-bot Plan this but don't give it a milestone for now, we'll work on it in a future version
Smithy-bot commented 2026-09-11 12:05:25 +01:00
Member
Copy link

Fleshed out acceptance criteria for the scientific GUI view design (mirroring the deliverable format of #13).

Key points:

  • Design-only — mockup attached to the issue, same as #13; no implementation in this story
  • Visual consistency with the default GUI design from #13
  • Mode switch between standard and scientific must be documented in the deliverable
  • No milestone per your 2026-09-08 comment
  • Future engine work (#25–#27) is optional in the mockup; exact scientific button set is left to the designer to document in the mockup

Criteria are specific enough to estimate. Moving to needs/estimate.

Fleshed out acceptance criteria for the scientific GUI view design (mirroring the deliverable format of #13). Key points: - **Design-only** — mockup attached to the issue, same as #13; no implementation in this story - **Visual consistency** with the default GUI design from #13 - **Mode switch** between standard and scientific must be documented in the deliverable - **No milestone** per your 2026-09-08 comment - Future engine work (#25–#27) is optional in the mockup; exact scientific button set is left to the designer to document in the mockup Criteria are specific enough to estimate. Moving to `needs/estimate`.
Smithy-bot commented 2026-09-12 12:04:53 +01:00
Member
Copy link

Story point estimate: 8

Design-only story (same deliverable format as #13). Criteria are specific enough to size.

Work Points Rationale
Scientific view mockup (expanded button grid, every control labelled) 3 More layout work than #13's single standard keypad
Standard ↔ scientific mode switch documentation 2 Additional interaction design not required for #13
Deliverable showing both standard and scientific layouts 2 Side-by-side or separate frames per acceptance criteria
Attach mockup image(s) to this issue 1 Same closure step as #13
Total 8

Reference: #13 (default GUI design) was 5 points for a single layout. This story adds an expanded scientific grid, mode-switch UX, and a dual-layout deliverable while reusing #13's visual language.

No milestone (per @Vylpes, 2026-09-08).

Moving to needs/tests.

## Story point estimate: **8** Design-only story (same deliverable format as #13). Criteria are specific enough to size. | Work | Points | Rationale | |------|--------|-----------| | Scientific view mockup (expanded button grid, every control labelled) | 3 | More layout work than #13's single standard keypad | | Standard ↔ scientific mode switch documentation | 2 | Additional interaction design not required for #13 | | Deliverable showing both standard and scientific layouts | 2 | Side-by-side or separate frames per acceptance criteria | | Attach mockup image(s) to this issue | 1 | Same closure step as #13 | | **Total** | **8** | | Reference: #13 (default GUI design) was **5** points for a single layout. This story adds an expanded scientific grid, mode-switch UX, and a dual-layout deliverable while reusing #13's visual language. No milestone (per @Vylpes, 2026-09-08). Moving to `needs/tests`.
Vylpes commented 2026-09-12 12:08:53 +01:00
Author
Owner
Copy link

@Smithy-bot My only question for you to answer on this is, can you identify if you as a bot and the mcp has the ability to generate an image? or is this something for me to do?

@Smithy-bot My only question for you to answer on this is, can you identify if you as a bot and the mcp has the ability to generate an image? or is this something for me to do?
Smithy-bot commented 2026-09-13 12:01:22 +01:00
Member
Copy link

Re: your question about image generation:

Short answer: Smithy-bot can generate images when running through Cursor (via the GenerateImage tool), but the Forgejo MCP itself has no image-generation capability. For this story's deliverable, a human-created mockup (as with #13) is likely the better fit for polished GTK layout work — though I can produce draft UI mockups from descriptions if you assign that work to me at implementation time.

QA Testing Scripts

Story: Design scientific view
Estimate: 8 story points
Scope: Design-only deliverable (mockup + mode-switch documentation attached to this issue — same format as #13). No GTK implementation in this story.

TC-01 — Mockup image(s) attached to the issue

  • Given this issue is marked complete
  • When I review the issue comments/attachments
  • Then at least one mockup image is attached (same deliverable format as #13 — see #13 (comment))

TC-02 — Visual consistency with #13

  • Given the mockup image(s) and the #13 default GUI design
  • When I compare colours, typography, spacing, and button styling
  • Then the scientific view reuses the same visual language as #13

TC-03 — Mode switch interaction documented

  • Given the deliverable (mockup and/or accompanying notes)
  • When I review how the user switches between standard and scientific modes
  • Then control placement, labels, and the resulting layout change are clearly documented

TC-04 — Every control in the scientific layout is labelled

  • Given the scientific view mockup
  • When I inspect each button and control in the expanded layout
  • Then every control has a visible label and its purpose is unambiguous

TC-05 — Layout detail sufficient for GTK implementation

  • Given the mockup image(s)
  • When a developer reviews the deliverable without further design clarification
  • Then window dimensions, button grid arrangement, and display area are evident from the mockup

TC-06 — Scientific layout extends beyond the basic four-function keypad

  • Given the current basic GUI (src/gui.rs — digits 0–9, ., C, +, -, *, /, =)
  • When I compare it to the scientific layout in the mockup
  • Then the scientific layout includes additional controls (e.g. trigonometric, logarithmic, power/root, constants, or other scientific operations — exact set documented in the mockup)

TC-07 — Standard view shown in the deliverable

  • Given the deliverable (side-by-side frames, separate images, or annotated mockup)
  • When I review the standard calculator layout
  • Then the standard view matches (or is shown alongside) the #13 design so developers know both layouts

TC-08 — Both layouts visible in one deliverable

  • Given the acceptance criteria require showing standard and scientific layouts
  • When I review the attached deliverable
  • Then both the standard and scientific layouts are present (side-by-side or as separate frames in the same attachment set)

TC-09 — Subtasks checklist satisfied

  • Given the subtasks on this issue
  • When I verify the deliverable against each unchecked subtask
  • Then all four subtasks are satisfied: (1) scientific mockup, (2) mode-switch documentation, (3) both layouts shown, (4) mockup image(s) attached

TC-10 — Design-only scope respected (regression)

  • Given this is a design story under Epic #12
  • When the issue is closed
  • Then no GTK implementation code is required or expected in this story
  • And CLI scientific notation / expression syntax remain out of scope

Criteria are specific enough to test. Moving to needs/approval for your review.

Re: your question about image generation: **Short answer:** Smithy-bot *can* generate images when running through Cursor (via the `GenerateImage` tool), but the **Forgejo MCP itself has no image-generation capability**. For this story's deliverable, a human-created mockup (as with #13) is likely the better fit for polished GTK layout work — though I can produce draft UI mockups from descriptions if you assign that work to me at implementation time. --- ## QA Testing Scripts **Story:** Design scientific view **Estimate:** 8 story points **Scope:** Design-only deliverable (mockup + mode-switch documentation attached to this issue — same format as #13). No GTK implementation in this story. ### TC-01 — Mockup image(s) attached to the issue - **Given** this issue is marked complete - **When** I review the issue comments/attachments - **Then** at least one mockup image is attached (same deliverable format as #13 — see https://git.vylpes.xyz/RabbitLabs/calculator/issues/13#issuecomment-19851) ### TC-02 — Visual consistency with #13 - **Given** the mockup image(s) and the #13 default GUI design - **When** I compare colours, typography, spacing, and button styling - **Then** the scientific view reuses the same visual language as #13 ### TC-03 — Mode switch interaction documented - **Given** the deliverable (mockup and/or accompanying notes) - **When** I review how the user switches between standard and scientific modes - **Then** control placement, labels, and the resulting layout change are clearly documented ### TC-04 — Every control in the scientific layout is labelled - **Given** the scientific view mockup - **When** I inspect each button and control in the expanded layout - **Then** every control has a visible label and its purpose is unambiguous ### TC-05 — Layout detail sufficient for GTK implementation - **Given** the mockup image(s) - **When** a developer reviews the deliverable without further design clarification - **Then** window dimensions, button grid arrangement, and display area are evident from the mockup ### TC-06 — Scientific layout extends beyond the basic four-function keypad - **Given** the current basic GUI (`src/gui.rs` — digits 0–9, `.`, `C`, `+`, `-`, `*`, `/`, `=`) - **When** I compare it to the scientific layout in the mockup - **Then** the scientific layout includes additional controls (e.g. trigonometric, logarithmic, power/root, constants, or other scientific operations — exact set documented in the mockup) ### TC-07 — Standard view shown in the deliverable - **Given** the deliverable (side-by-side frames, separate images, or annotated mockup) - **When** I review the standard calculator layout - **Then** the standard view matches (or is shown alongside) the #13 design so developers know both layouts ### TC-08 — Both layouts visible in one deliverable - **Given** the acceptance criteria require showing standard and scientific layouts - **When** I review the attached deliverable - **Then** both the standard and scientific layouts are present (side-by-side or as separate frames in the same attachment set) ### TC-09 — Subtasks checklist satisfied - **Given** the subtasks on this issue - **When** I verify the deliverable against each unchecked subtask - **Then** all four subtasks are satisfied: (1) scientific mockup, (2) mode-switch documentation, (3) both layouts shown, (4) mockup image(s) attached ### TC-10 — Design-only scope respected (regression) - **Given** this is a design story under Epic #12 - **When** the issue is closed - **Then** no GTK implementation code is required or expected in this story - **And** CLI scientific notation / expression syntax remain out of scope --- Criteria are specific enough to test. Moving to `needs/approval` for your review.
Smithy-bot removed their assignment 2026-09-13 12:01:24 +01:00
Vylpes removed their assignment 2026-09-13 13:03:42 +01:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
cursor/11-forgejo-actions
release/0.1.0
feature/11-forgejo-actions
develop
No results found.
Labels
Clear labels
  
blocked

   
duplicate
  
needs
approval

  
needs
criteria

  
needs
estimate

  
needs
tests

  
question
  
step
doing

  
step
review

  
step
testing

  
step
todo

  
step
uat

  
type
admin

  
type
alert

  
type
bug

  
type
change

  
type
defect

  
type
dependencies

  
type
epic

  
type
idea

  
type
incident

  
type
investigation

  
type
spike

  
type
story

  
won't fix
No labels
blocked
duplicate
needs
approval
needs
criteria
needs
estimate
needs
tests
question
step
doing
step
review
step
testing
step
todo
step
uat
type
admin
type
alert
type
bug
type
change
type
defect
type
dependencies
type
epic
type
idea
type
incident
type
investigation
type
spike
type
story
won't fix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
RabbitLabs/calculator#14
No description provided.