Hi Werner,
Werner Dittmann wrote:
Yana,
please have a look at the screen shot. ZRTP messages tend to be long
and consumer more than 3 lines. It seems that systray pop up just displays
3 lines. In general the security warning messages are quite long.
Exactly. However I'll be working on systray popups next week and the idea at the end is to adapt systray popups for error/warning messages (i.e. be able to show the whole message and remove the popup only on user close).
Also I'm about to check-in the modifications I made to security message
event handling. The following mods were done:
class CallParticipantSecurityMessageEvent:
- remove the String "message": this was not used anywhere, just set.
This also saves some hard coded text in class SecurityManager.
Actually this was meant to be used for logging purposes. The idea was the same as in java.lang.Throwable with getMessage() and getLocalizedMessage().
- string messageType now holds the i18n string of the messages type,
i.e. if it is a warning, a severe, or a ZRTP error. The event listener
function in CallPanel now uses it to set the pop up header line
correctly (see screen shot). If you agree we can remove the predefined
type strings from class CallParticipantSecurityMessageEvent, they are
not longer used
Agree and have removed all predefined event types. Actually I have also removed the messageType. We already have the severityType and IMHO it's sufficient in order to determine the title in the gui.
- added a severity field. The CallPanel event listener uses this field
to determine if it shall play the alert sound or not.
Agree!
The SecurityManager class was modified also to setup the event fields
correctly. Also small mods to CallPanel security message event listener.
Ok. I have just renamed all zrtp specific constants going to the gui (e.g. CallParticipantSecurityMessageEvent.ZRTP, NotificationManager.ZRTP_ERROR, SoundProperties.CALL_SECURITY_ERROR etc.) with more generic names like ERROR and CALL_SECURITY_ERROR. We're really trying to make the gui as independent as possible.
Some other things included in my commit:
- added an else clause at the end of SecurityEventManager.showMessage() method. There was a null message for all zrtp codes that we were not considering.
- changed the way I was previously calling setSecurityOn/setSecurityOff directly on the AbstractCallParticipant. I have now added a SessionCreatorCallback, which is implemented by CallParticipants interested in security events.
Regards,
Yana
···
Regards,
Werner
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
).
)