All of which leaves me with the following comments:
- The behaviour makes me wonder how Roar can seemingly override the registry parameter, as it is always brought to foreground regardless of recent user activity, and whether this can be applied to the chat window Bring to Front functionality.
- In looking more closely at the Roar settings, it is nicely configurable and will basically meet the requirement I outlined in my previous post, by putting say a 30 minutes (= 1800000 ms) in Spark -> Preferences -> ROAR -> Duration in ms). Now the notification will persist for 30 minutes providing ample opportunity for our specialist to glance at the screen and action the request (generally it is just to temporarily release a patient record so the front desk can update client details in preparation for invoicing). Of course I may have to revisit this if it drives everyone nuts, but I think we can avoid that with usage tips/policies.
- It would be nice if ROAR could be configured to leave the popup on-screen indefinitely, perhaps by configuring Duration in ms = 0. In other words, the window would persist until the user clicks the popup. How it works right now: if you configure Duration = 0, save and re-enter preferences, the parm has been reset to 3000 ms. While this is not a terribly important option in my context, I can see how it would be very useful for others and it seems like it would be fairly easy to implement (famous last words).
- More important, however, would be the ability for the message sender to mark only particular messages as requiring user acknowledgement or a long notification period. Alternatively, the admin or the recipient could set notifications from a particular room or user(s) to be different to others. An example might help, following on from the scenario I mentioned above: notifications from the front desk would receive priority notifications, i.e. ROAR for 30 minutes. However a chat room message would just do a normal toast popup as it would be chat, not an action-is-required scenario. Right now I plan to limit our use of Openfire/Spark to the urgent notification paradigm, as that is our greater business need, but ideally I would also be able to also use chat in a more collaborative way. Yes, I want to have my cake and eat it too.
Anyway those are my thoughts. Happy to post suggestions elsewhere if there is a more appropriate place.
Openfire/Spark is a FOSS at its best - I am impressed and grateful to the dev and wider community.