View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017179 | MMW 5 | Install/Config | public | 2020-12-07 02:51 | 2020-12-12 16:26 |
| Reporter | rusty | Assigned To | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.1 | ||||
| Summary | 0017179: Some users can't read toast messages quickly enough | ||||
| Description | It seems that toast messages sometimes disappear too quickly for users to be able to read them. Perhaps in the short term: have them display for 2 extra seconds In the long term: give the user the ability to extend the time for which they display | ||||
| Additional Information | https://www.mediamonkey.com/support/?support_page=open_ticket&ticket_id=323 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2282 | ||||
|
|
The ToastMessage class could be written with an optional user override where disableClose is always false. However, this probably isn't necessary. Note their suggestion for mousing over the notification, where they expected it to not fade out when it was moused over. The TrackInfo popup already behaves like this, where the fadeout timer is disabled when moused over. Here's my suggestion: - Register when the user mouses over a ToastMessage - When the "finish" function is called via a timeout: If the user is still moused over the ToastMessage, cancel its disappear animation, and show the X button. - If the user clicks on a ToastMessage, cancel the timeout and immediately show the X button to allow them to manually clear it. That way, if the user is still reading the toastmessage whlie it was supposed to go away, it'll just politely enable the X button instead of disappearing. I think this would be quite intuitive. No extra user settings necessary. But also, increasing the timeout for notifications that have a lot of text is still a good idea. In film/animation, the rule for timing on-screen text is the time it takes you to read it 3 times over. |
|
|
OK, I added two extra seconds, but seeing that the default timeout already was 10 seconds , so adding two extra seconds probably does not solve much. It sounds to me that the user rather had an issue when updating tags for many files (I tested in the Files to edit > Deadlinks node). In that case the next tagging file overwrites the previous file in the toast message. Anyhow, this seems a minor issue atm, lowered the priority and assigned to drakinite (if he wants to improve it per his suggestions above) |
|
|
Added. Only downside is that it now doesn't propagate mouse events through the toast message, so if you are moused over the toast and scroll the mouse wheel, your music listing won't scroll. It's more of a snackbar than toast now, but tbh it was already like that. (Toast messages, by definition, can't take user input and cannot be shown indefinitely; snackbars, on the other hand, can.) If we want it to be user-configurable, I also added a boolean switch that disables it. And the .toast { pointer-events: auto; }, which I added, could be changed by JS. |
|
|
I think that it works fine after the drakinite's changes now ;-) So resolving. |
|
|
Verified 2283 I also have no issues with current change and no regressions found. I do not have issue if mouse is over Tooltip while shown to not scroll list. It can be usefull if we decide to show more info in tooltips where we can then use it to scroll tooltip. |
