CalendarEventColorScheme.ktCalendarEventColorScheme is a minimal two-value enum that controls how calendar events are coloured in the calendar UI. STANDARD renders events with the ProjectForge default palette and opacity, while CLASSIC removes opacity effects for users who need higher contrast — particularly those with visual impairments or when using projectors in meeting rooms.
| Enum Constant | Key | i18n Property | Behaviour |
|---|---|---|---|
STANDARD |
standard |
calendar.settings.colors.scheme.standard |
Default colour rendering with opacity/transparency effects as defined by the theme. |
CLASSIC |
classic |
calendar.settings.colors.scheme.classic |
Solid, fully opaque colours without transparency — better for users needing higher contrast or for low-quality display devices. |
This enum is referenced from user-specific calendar settings (likely the PFUserDO preferences or a dedicated calendar-settings entity). The selected value is persisted as a string ("standard" or "classic") and used by the front-end rendering layer (Wicket components or JavaScript) to determine the CSS class or inline style applied to calendar event cells. The I18nEnum implementation provides localised labels for the settings UI where users pick their preferred scheme.
Because it has only two values, the enum is intentionally simple. Extending it with more schemes (e.g. a high-contrast mode, a colour-blind-friendly palette) would require only adding new constants — the pattern already supports expansion.
| Commit | Description |
|---|---|
868d6abb7 | Copyright year bump: 2025 → 2026 |
63081666f | Source file headers: 2024 → 2025 |
9ebb88522 | Initial commit — introduced alongside the calendar module |
The CLASSIC scheme was added specifically to address an accessibility concern — partially transparent event rectangles can be difficult to distinguish for users with low vision or on projectors with poor contrast. Rather than building a full theme engine, the team chose a simple binary toggle. This keeps the settings UI simple and the rendering code straightforward: a single conditional branch in the front-end instead of a complex colour-mapping pipeline.
isHighContrast: Boolean?An enum is forward-compatible. If future requirements demand a third scheme (e.g. a dark-mode palette, or a deuteranopia-friendly colour set), adding a new constant is a non-breaking change. A boolean would require a migration to an enum later, touching the database schema, the settings UI, and all consumers. Starting with an enum — even a two-valued one — avoids this future refactoring cost at no meaningful overhead.
I18nEnum for such a small set?Consistency. Every user-visible enumeration in ProjectForge implements I18nEnum so that the settings UI can render drop-downs generically: given any I18nEnum subclass, the framework can iterate its values and look up localised labels. This uniformity means the calendar-settings page doesn't need special-case code to handle the colour-scheme picker — it uses the same component as every other enum-backed setting.