Message box "Communication Error" bugs and security issue. #4251
Comments
|
As a minimum it needs an auto timeout (like 5 seconds). Plus it should go away immediately as soon as communications are restored. And it should not pop up until comms have been lost for a "significant" amount of time. As it is, it pops up far too easily. Maybe devote some space on the status bar? We used to have the rotating ticking symbol for this info but now it "ticks" all the time even if no position data is incoming. |
Yes, something like this would be much better, agreed. I understand your opinion that the message box is too invasive. OTOH, there should probably be some kind of feedback for what could be bad cables, failing devices or what not. |
|
Thinking about this I wonder if we need some new user feedback infrastructure. Currently we have three options:
None of these are that attractive in my eyes. Thinking about some notification system similar to what all modern GUIs have. Basically just a small icon the status bar which is changed when something happens. User can then click on the icon, see the messages and clear them. The point is that these messages are then displayed when user wants it rather than ad-hoc. However, lot's of code. |
|
Or, we could create a “notification instrument” in DB PI which contains a
scrolled list of notifications from wherever. Then the user could put this
instrument anywhere they like. If we were sufficiently cleaver it could be
somewhat transparent. In fact, all instruments could be somewhat
transparent to good advantage.
…On Sun, Dec 8, 2024 at 4:42 AM leamas ***@***.***> wrote:
Thinking about this I wonder if we need some new user feedback
infrastructure. Currently we have three options:
1. A modal dialog. Easy to code, but *very* invasive basically
hijacking the whole application until user dismisses it.
2. A non-modal dialog. Less invasive, but trickier to code. We could
perhaps making this easier with examples and some infrastructure, dunno.
3. A message in the log.
None of these are that attractive in my eyes. Thinking about some
notification system similar to what all modern GUIs have. Basically just a
small icon the status bar which is changed when something happens. User can
then click on the icon, see the messages and clear them. The point is that
these messages are then displayed when user wants it rather than ad-hoc.
However, lot's of code.
'
—
Reply to this email directly, view it on GitHub
<#4251 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQJYAZLSW5ZJYP4BYHPSM32EQO7VAVCNFSM6AAAAABTGRH6U2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRVGU4DGNBXGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Or, we could create a “notification instrument” in DB PI which contains a scrolled list of notifications from wherever. Then the user could put this instrument anywhere they like. If we were sufficiently cleaver it could be somewhat transparent. In fact, all instruments could be somewhat transparent to good advantage. |
|
Another or.. |
|
Here is actually two ongoing discussions. One is about the general problem about notifying users in a less invasive way than dialogs, especially modal ones which is the default solution. The other is about this specific problem. Some background to this is that in 5.10 the driver dutifully reports the error in an EventVar, but nothing was listening and the error condition was basically lost. The NMEA log is actually more or less broken by design. The backend cannot handle N2000, and the UI is a mess. As a debug tool it has it's role, but it is certainly not the general answer. Note that the error condition reported by the drivers and other parts carries much more information than "there is no data". Which brings us back to the more general discussion.... |
The connection error is just an example. Over time, there will be all sorts of conditions reported by drivers. |
|
I have started #4253. Let's try to keep the general ideas there, keeping this one more focused. |
|
Yes, good. Let's take a step back and discuss if this feature is needed and if so in what way. |
|
For info: |
|
How about adding a small AIS indicator next to the GPS. |
This issue is about the new "Communication Error" pop-up message implemented by commit 745333d
On the one hand, there are pure bugs, and on the other hand, I see the function as a security risk when navigating. I suggest either reworking the graphics or removing the feature.
Security issue.
The "Communication Error" message appears in the middle of the screen where the boat symbol is often positioned when sailing. If the weather isn't the best and a narrow passage is being navigated, I really don't have time to let go of the steering wheel and sails to find the mouse and try to click, and hit, on the screen to turn off, one or more, the message that now covers the boat with surrounding marks and maybe an oncoming boat on the radar overlay.
But I'm actually forced to do something to see the entire chart on the screen because the message has no built in time out but stays "forever".
Bugs
Irrelevant Display of "Communication Error"
For example, even though location data is received, the "Communication Error" is displayed for that data source.
This may involve a temporary interruption, for example after hibernation. The message is posted on the screen and remains even though the data source is working properly after a few seconds.
When using the "Send to GPS" function, the "Communication Error" alarms even though data has been sent.
See picture 1 where I have just sent a route to "GPS @ COM6". The successful transfer is visible in the Debug Window.
OCPN hangs when "Communication Error" appears over e.g. the Canvas menu.
If a right-click menu appears when "Communication Error" is activated, nothing can be done. "Communication Error - OK" does not work. Menu selection does not work. OCPN cannot be turned off with the upper right cross. The mouse is, so to speak, locked to the underlying Canvas, which can be moved! Curiously, a new right-click can open another menu, but a possible selection is not activated. See Figures 2 and 3.
In this locked state, OCPN can only be closed using the Task Manager. Curiously, an "Alt-Tab" maneuver to another app can close the locked menu in OCPN and the "Communication Error" can be extinguished with "OK". This last method is not obvious and OCPN is perceived as hanged.
Expected behavior and general reflection.
The "Communication Error" message is basically redundant information. OCPN has clear, non-disruptive, features to detect loss of important data. Loss of position, COG and SOG is obvious as the boat symbol changes appearance and the satellite indication in the "Compass Window" disappears.
If data signals used in the Dashboard disappear, there is a built-in time-out that clearly indicates that the value is not available.
If the data source for AIS disappears after being active, it is not as obvious on the high seas with no targets nearby. An indication of this data loss may possibly be justified. But not in the middle of the screen, which can be a security risk, as discussed above.
Desktop (please complete the following information if applicable):
Additional context
O-crash:
I've tried to make the "Communication Error message box" to close after a time-out. It works for one box, but when several boxes appear above each other, O crashes when the first box's time has expired. Some kind of thread mismatch?
Other connected issue: See #4204
Screenshots
Shot 1
Shot 2 and 3
The text was updated successfully, but these errors were encountered: