Replies: 6 comments 1 reply
-
|
I've used O and other applications for long and never missed any pop-ups or similar for connection troubles. If I some time have experienced lack of data NMEA Debug Window has been good enough.
Some kind of pop-up icon can be a good solution. But I think it is important that if a message is posted there, it should also be removed automatically if the cause of the "error" is no longer active. If the user sees the icon and opens the dialog and there is a note that is no longer relevant, the trust in this feature disappears very quickly. |
Beta Was this translation helpful? Give feedback.
-
|
One solution might be a warning icon in the status bar up right like that one - small, visible and not intrusive: |
Beta Was this translation helpful? Give feedback.
-
|
This is more or less my thinking as well. Compare to for example the Android notification system. |
Beta Was this translation helpful? Give feedback.
-
|
My $0.02 worth, Two elements here, logging and alerts. I would like to see a central logging mechanism, for logging both internal OpenCPN events (lost GPS fix, communications failure, etc.) as well as external events such as DSC Distress Alerts, AIS Safety Messages, AIS SART/EPIRB/MOB transmissions. Such a log should also allow plugins to log events, , perhaps Chart Downloader detecting a server failure, Douwe's autopilot receiving autopilot errors, engine dashboard logging engine faults etc. In some respects think of something like the Windows event log, or the myriad of Linux event logs. Not forgetting that there is also OpenCPN's own log, I don't think it lends itself to this kind of role. And whilst this is perhaps not a discussion regarding implementation, given that SQL Lite libraries are bundled with OpenCPN, why not make use of a proper database as the store? Then it is easy to create simple views of the data, Eg. select date, time, description, position from log where log-type = DSC-Distress The second element is displaying alerts. Agreed that OpenCPN's screen real estate is limited but I'm in two minds here. Displaying an icon on the OpenCPN Status bar as noted above is one mechanism, takes little space and is unobtrusive but may go unnoticed. On the other hand, all of the operating systems that OpenCPN runs on, have a notification system. Why reinvent the wheel, when you can simply take advantage of underlying operating system features. Not familiar with notifications on other platforms, but Windows notifications disappear automatically after a specified period of time. And finally there may be notifications that do need a modal dialog and do need to be acknowledged by the user, for example DSC Distress Alert. Therefore there must be some categories to distinguish between informational and important alerts. |
Beta Was this translation helpful? Give feedback.
-
Worth much, much more actually.
Agreed
Indeed, why not. Still, a bit early...
I doubt this is a good idea.
It seems that this somehow unifies my initial thoughts with @transmitterdan 's idea with a log. The underpinnings would be an event log. Depending on categories event log entries are either just available, displays a "something happened" icon in the statusbar or, in some really serious cases, unconditionally displays a dialog. Such a dialog should BTW not be modal since we cannot know the state of the system when it fires up. |
Beta Was this translation helpful? Give feedback.
-
|
Re Full Screen Mode, I'm pretty certain that Windows Toaster events pop up over apps running in full screen mode. I would be quite surprised (but then again perhaps not) if other platforms behaved differently. On Android, I think the app can ensure the status bar is always shown even if in full screen mode (or at least make the status bar transparent). But I guess given the cross platform requirements, you have to go with the lowest common denominator that wxWidgets provides. BTW, wxWidgets does have wxNotifications, but a quick little test revealed that they don't pop up when O is in full screen, although I didn't test the platform specific MSW platform specific toast feature.
Understand that that modality of dialogs can be a problem, especially in headless scenarios (to wit I recall the early days of headless Windows servers !). Perhaps wxNotifications with an infinite timeout, and an action can address this? Might be worth further investigation? I'll reiterate the need for an event log. Today we have no historical record of events such as MOB, DSC Distress alerts and AIS Messages and MOB/SART/EPIRB messages. That being said, O does not parse NMEA 2000 DSC messages (PGN 129808), nor does it parse the gazillion other proprietary NMEA 2000 event/alarm PGN's. That's why I've made the suggestion that plugins should be able to insert entries into the log as some of my plugins do parse these proprietary PGN's and I'm sure other plugin developers may find this useful. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
As of #4251 it seems like we would benefit from a new way to present asynchronous user messages. That is, something between the too invasive dialog boxes and just logging a message (which normally isn't noticed).
I have been thinking about something like the notification system in for example Android or Gnome: a small icon in the statusbar which changes when there are new messages. When user clicks in it the messages are displayed; user can clear them one by one or all of them
@transmitterdan has proposed kind a rolling log which user can place, resize, etc.
The common denominator is that user should be able to control these messages so they not cause the problems described in #4251. And it's probably some work...
Beta Was this translation helpful? Give feedback.
All reactions