[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

[LordIdra]

Thinking of doing something like this (mocked up with an llm) for the guidance/display/command/action panels, instead of having dialog boxes?

I would do this in a subsequent PR as it's quite a big change in itself.

Also, I am not really sure at this point if I should just use the editor panel code directly instead of essentially copying its appearance. I'm just wary of doing that as it might be a big refactor

[LordIdra]

Have merged enabled and enabled date together

2026-11-06.10-20-08.mp4

[LordIdra]

Ok have thought about this some more and have just removed 'enabled' from the properties panel entirely. It duplicates the context menu option and it's more state than configuration so this doesn't make too much sense from the user perspective - I think the better option is to keep the context menu options only. Especially since I plan to extend the disabling functionality in ways which wouldn't neatly fit into the properties panel (see #3995 / Alarm disable improvements)

[sonarqubecloud]

Quality Gate failed

Failed conditions
4.3% 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