Notification Area - Non-Intrusive notifications #8120
Conversation
=================================================== Extend Console and Ilogger interface to include a string to identify the notifier, which may be the fullname Document#DocumentObject when available.
====================== New NotificationArea class to show non-intrusive notifications.
======================================================= The former system of autoclosing messageboxes is removed in favour of notification via the Notification Area.
====================================================
A new widget heavily based on QToolTip, to have a similar look and feel
and interface, while avoiding early closing on user action.
QToolTip is not intended for notifications, but to provide contextual help.
However, QToolTip is an example of non-modal non-intrusive contextual information
widget. It cannot reasonably be used for notification, as there is no control by
the user code about the several Events that cause it to close early (which are
appropriate for contextual help, but not make it unsuitable for notification).
QToolTip implementation is internally based on an implementation only class QTipLabel,
deriving from QLabel, which uses an event filter to react to several events to early
hide the label ("early" meaning: before enough time has lapsed for the user to read it,
sometimes insufficient even to notice it). This makes the unsuitable behaviour difficult
or even impossible to override (e.g. by inheritance).
Gui::NotificationBox is a reimplementation intended to provide user notifications. It
relies on the proven code of QToolTip for the wanted behaviour, but the notification box
can only be hidden earlier than the provided time (or the time calculated internally if none
is provided), if the left mouse button is clicked.
In short, a "tooltip" alike notification appears. The user can continue working without having
to interact with the notification. If the user is interested in the notification, he or she can
stop to read it. If not interested, the user can ignore it and continue working. The notification
will automatically disappear when the timer lapses or when the user clicks the LMB (showing no
interest in the message or actively deciding to do away with it), whatever happens first.
github-actions
bot
added
Core
|
This is amazing work! Auto-closing/dissolving messages are what I've been waiting for a long time! |
|
This looks excellent. +1 from me for sure. |
| @@ -489,7 +489,7 @@ class BaseExport ILogger | |||
|
|
|||
| /** Used to send a Log message at the given level. | |||
| */ | |||
| virtual void SendLog(const std::string& msg, LogStyle level) = 0; | |||
| virtual void SendLog(const std::string& notifiername, const std::string& msg, LogStyle level) = 0; | |||
There was a problem hiding this comment.
Notes:
ILogger interface is extended to include a new string "notifiername". This would ultimately enable Console messaging to offer notifier identification, which is specially useful to discern between Documents and Document Objects where an notification may originate, while still allowing other, client defined, identification where the object is neither a Document or a DocumentObject (such as sketch.cpp). In part, this is done to separate the actual error messages and notifier (which could be treated differently by different observers, and may lead to reusing the same message for different observers despite how the handle notifier information) and, in part, to support multi-document projects.
This implies a change in the API. The majority of the rest of the changes in this commit are to deal with this change of API. If there is client code that links against FreeCAD and uses this interface, that client code would need to be adapted too. In those changes, I have not made a decision yet on how to best convey the notifier information.
| public: | ||
| static const unsigned int BufferSize = 4024; | ||
| // exported functions goes here +++++++++++++++++++++++++++++++++++++++ | ||
| /// Prints a Message | ||
| virtual void Message ( const char * pMsg, ... ); | ||
| void Message ( const char * pMsg, ... ); |
There was a problem hiding this comment.
Note:
Legacy Message/Warning/Error/Log functions stop being virtual. New MessageS/WarningS/ErrorS/LogS counterparts are created, which take an additional notifier parameter (also non-virtual). Both this are then handled via a virtual private interface (NVI pattern) for extension (see MessageV/WarningV/ErrorV/LogV).
The Console client user has then the option to emit regular legacy message (not identifying the notifier), or use the new versions identifying the notifier.
|
Thanks. It would be great if somebody could check how it runs on Windows, as the auto-closing notification has some windows specific code, and I have no Windows. This file will trigger parabola migration, and partially redundant constraint warnings: |
ghost
closed this by deleting the head repository
DRAFT PR! DO NOT MERGE! Not intended for code review!
The intention of this PR is to be a kind of proof of concept and provide a basis for discussion of whether we need something like this or not.
Problems:
Solution:
(a) FreeCAD has a error/warning/message mechanism in place (Console based).
(b) FreeCAD has a user Message signaling mechanism which can be used to require confirmation from a user for (1).
The solution here seeks to implement a Notification Area in the statusbar at Application level, so that it can gather notifications from different documents [to solve (4)]. It extends (a) and (b), so that both can provide a "notifier" field. This notifier field can be the fullname of a Document or DocumentObject, or any string usable for identifying the notifier within the Application [to solve (4)]. Both (a) and (b) feed the Notification Area. The notification Area is a single button in the tool bar which makes accessible all notifications upon clicking on it [in order to address the space issue in (2)]. New notifications (error/warning/messages) are briefly shown, in a look similar to a tooltip, via a non-intrusive non-modal auto-closing widget over the Notification Area [addressing (2) and (3)]. The idea is to also integrate user messages into this system and do away with blocking modal dialogs (the Sketcher is full of them) [addressing (3)]. Well, "do away" may mean "provide the user with a preference to choose between non-intrusive non-blocking and intrusive blocking".
The solution described is an early basic implementation for discussion.
NotificationArea.webm
Tooltip alike non-intrusive auto-closing notification:
Notifications widget:
