[LordIdra]

Part of #3995
Depends on #3987 - has changes from 3987 mixed into it as I can't create a branch on this repo to base the changes off of, so I have marked this as a draft

Next PR will likely be improvements to the guidance/displays/commands/actions menus, building on this one

I am holding off documenting any of this right now as subsequent PRs will change alarm configuration further

Also found some bugs while doing this which I fixed. Just to flag, I have realised during this that the 'automated actions' dialog box buttons are pretty much non-functional as only the 'add' button handler has been overridden - this is an issue in 6.0.0 too, I have not bothered to fix this here as I plan to overhaul those dialog boxes next (or embed them into the properties panel).

Demo

2026-11-03.16-23-21.mp4

2026-11-03.16-25-20.mp4

Changes

• Created a panel for configuring alarms and components, modelled after the display editor property panel
• Obliterated alarm configuration dialog boxes
• Added AlarmClientNode#createDetachedCopy
• Added AlarmTreeItem#configsEqual
• Added DateTimePicker#dateTimeProperty
• Fixed itemUpdated being called for tombstone messages
• Fixed AlarmClientLeaf#setEnabledDate throwing NPE if provided with null
• Fixed a typo in JsonModelReader#updateAlarmLeafConfig which meant that the function would sometimes not count a node's enabled state as being changed even though it has been changed
• Fixed the edit buttons in the title details tables throwing an error due to missing id in fxml

Some things I'm not sure on

• Is the grouping (info/enabled/behaviour) sensible?
• Given there's so much space it would be nice to inline the guidance/displays/commands/actions into the properties panel instead of as dialog boxes, is there any reason to not do this?
• Is there any nicer way to write AlarmTreeItem#configEquals? Sealed interface would be nice but wary of creating new interfaces for a small thing like this
• I can see some stuff uses FXML and some doesn't, is this just various people's personal preferences or is there some kind of convention I should be following? I have done everything in code here as that seems more sensible for this kind of interface.

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • If not, explain how you tested your changes - Manually tested by configuring alarms in as many different ways as I could think of, including with two clients at the same time

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[sonarqubecloud]

Quality Gate failed

Failed conditions
4.1% Duplication on New Code (required ≤ 3%)
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE