A native menu enhancement for AmigaOS 3.2.3.
AmiMenu is built around a simple idea:
Less magic. More AmigaOS.
It does not try to impress with shadows, truecolor effects or decorative rendering tricks.
Instead, it focuses on what matters most on a classic Amiga:
- presence
- responsiveness
- clarity
- system integrity
AmiMenu aims to make menus feel more immediate, more natural and more firmly rooted in the operating system.
Project definition / architecture stage
AmiMenu is currently being defined as a native-first AmigaOS 3.2.3 project with a deliberately conservative scope.
The current focus is on:
- product identity
- architecture
- runtime boundaries
- dependency policy
- interaction and performance principles
This project is intended as a reference-quality AmigaOS 3.2.3 menu enhancement, not as a feature clone of historical tools.
AmiMenu is a menu enhancement for users who want:
- native AmigaOS behaviour
- immediate feedback
- lower overhead
- tighter system integration
- a stronger AmigaOS 3.2.3 identity
It is a project about reaction, not decoration.
AmiMenu is not:
- a MagicMenu clone
- a truecolor or shadow effects showcase
- a Workbench skinning system
- a launcher environment
- a general GUI enhancement suite
- a third-party graphics framework wrapper
If you want menus that are louder, flashier or more decorative, other tools may suit you better.
If you want menus that feel faster, cleaner and more native, AmiMenu is built for that purpose.
AmiMenu starts from a different question:
How good can menus feel when AmigaOS 3.2.3 is taken seriously?
That means:
- native system integration over visual gimmicks
- responsiveness over effects
- clarity over feature drift
- low overhead over decorative complexity
- AmigaOS 3.2.3 as the architectural baseline
- ReAction where it belongs: in preferences and configuration UI, not in the runtime core
AmiMenu should feel as if it belongs to the system — not as if it was imposed on it.
AmiMenu is designed to be:
Built for AmigaOS 3.2.3 as the primary platform, not shaped by legacy compromise first.
The first mouse click should already create a clear sense of reaction.
Smaller footprint, fewer dependencies, less runtime ballast, fewer moving parts.
No feature bloat. No decorative overload. No second architecture hidden behind the system.
AmiMenu should cooperate with AmigaOS, not compete with it.
AmiMenu deliberately does not aim to provide:
- visual spectacle as a primary feature
- shadow-heavy or truecolor-centric menu identity
- a broad decoration system
- launcher-style scope creep
- a compatibility circus driven by old edge cases
- foreign-stack drift
AmiMenu is intentionally narrow.
Its purpose is to improve menu presence and responsiveness on AmigaOS 3.2.3.
- AmigaOS 3.2.3
- ReAction / BOOPSI for preferences and editor UI where appropriate
- native Intuition / graphics / utility centred design
- short hotpath from input to visible reaction
- strict ownership and cleanup rules
- no dependency-heavy visual subsystems in the core
Prefer what the operating system already provides.
Do not import alternative universes unless there is a compelling reason.
Before inventing a custom mechanism, AmiMenu asks whether AmigaOS already provides the correct building block.
Anything that can be prepared ahead of time should not happen during interaction.
Rendering exists to support clarity and immediacy, not to become the product.
Resources must have clear owners, predictable lifetimes and clean shutdown paths.
Less state, fewer branches, fewer side effects, fewer surprises.
ReAction is part of the native UI story for preferences and editor work.
It is not the runtime identity of AmiMenu.
AmiMenu should not define itself through third-party graphics or UI technologies.
AmiMenu is not about benchmark theatre.
It is about perceived immediacy:
- shorter path from click to visible result
- fewer unnecessary allocations
- less runtime churn
- lower state complexity
- fewer optional rendering branches
- more predictable behaviour on real hardware
The goal is simple:
menus should feel present immediately.
AmiMenu is for users who:
- value native AmigaOS behaviour
- prefer responsiveness over visual effects
- want a low-overhead solution
- appreciate system-conform design
- see AmigaOS 3.2.3 as a platform worth designing for properly
- AmigaOS 3.2.3
- native-first
- minimal dependency footprint
- conservative scope
- system-conform behaviour
- define runtime core
- define preferences boundary
- define configuration storage
- define dependency set
- establish behaviour and latency goals
- open and track menus with minimal overhead
- establish clear selection behaviour
- verify immediate visual response
- test on realistic 68k systems
- provide native preferences UI
- expose only meaningful settings
- keep configuration out of the runtime hotpath
- harden cleanup and shutdown behaviour
- reduce edge-case fragility
- improve predictability in real-world setups
- improve clarity
- improve consistency
- improve responsiveness
- resist unnecessary expansion
Every change should answer one question:
Does this make AmiMenu feel more immediate, more native, more stable or more coherent on AmigaOS 3.2.3?
If not, it probably does not belong here.
A good change:
- reduces complexity
- shortens the runtime path
- improves response
- clarifies ownership
- strengthens native system integration
- preserves project focus
The name AmiMenu reflects a deliberate shift in emphasis.
This project is not about preserving menu “magic” at any cost.
It is about building a menu enhancement that feels unmistakably at home on AmigaOS 3.2.3.
The emphasis is not on spectacle.
It is on presence.
AmiMenu enhances menus on AmigaOS 3.2.3 through native presence, responsiveness and restraint — not through effects.
AmiMenu is not trying to compete through spectacle.
It aims to show that classic Amiga software can still be improved by going deeper into the operating system, not farther away from it.
Less magic. More AmigaOS.