GNOME Bugzilla – Bug 756094
Notifications block navigation of tabbed windows
Last modified: 2021-04-25 20:10:46 UTC
Created attachment 312690 [details] exampe of notifications getting in the way File operations notifications block navigation of tabs in nautilus. The user must either needlessly wait for the notification to disappear on its own, or go click the close button to navigate to a new tab, or to close a tab. This is very unproductive for managing files in the file manager, since copying/moving/deleting is constantly bringing up this notification. The notification also makes the tab labels beneath incredibly difficult to read. The current implementation poses major usability issues. Overall, the need for a popup *in window* seems questionable. I realize that some GNOMErs are concerned about accidental deletions, but when the concern about accidents causes constant obnoxious notifications for deliberate actions, this is not a good balance.
We are looking into a new design for it given this issues: https://wiki.gnome.org/Design/OS/InAppNotifications very early work tho.
-> 3.20
Carlos, you switched to NEEDINFO but there's no actual question here. If that was supposed to mean that you're awaiting input from the design team, maybe you should consider leaving it as NEW and adding the ui-review keyword instead?
(In reply to Alexandre Franke from comment #3) > Carlos, you switched to NEEDINFO but there's no actual question here. If > that was supposed to mean that you're awaiting input from the design team, > maybe you should consider leaving it as NEW and adding the ui-review keyword > instead? Whoops, no idea how I did it. Switched to NEW.
Same problem.
No clear design yet, moving milestone to 3.22
This is annoying me in 3.18 when doing a lot of delete actions while in list mode (which already is pretty broken in functionality on its own) where it covers up the top two files (a use case which now seems to be a bit better due to this bug). I think it is not a good solution to just live with it covering useful stuff all the time when it can be alleviated by making it just occasionally cover useful stuff (e.g, move it to the bottom, although that would probably require a redesign) or make it easier to live with (make it more transparent and click through, and make it so that hovering over it in an erratic way will also close it). If it is not getting fixed then please make it at least possible to disable the notifications (an obtrusive notification for every delete action is not that useful to begin with). This whole notification redesign is a big regression in Gnome as a whole (notifications in Gnome Shell < 3.16 were much better because now it covers up useful stuff and there are less actions, but in Nautilus it is now especially infuriating to work with).
No decided design yet, moving to 3.24
It would be nice to see a global/central implementation of operations in progress in gnome-shell. How in-app notifications of Nautilus could benefit from it: - the user could opt between in-app notifications or global (for global the progress-wheel could be moved to the shells top panel with a label like copying files and the in-app notifications would become regular notifications) or - when a fie operation is in progress and the user closes the nautilus window, the progress wheel could automatically move to the shells top panel so the user doesn't loose overview about the operation in progress or - when the application loses focus/is covered with another window while an operation is in progress, a labeled progress-wheel would appear on the shells top panel to indicate progress - when a user click-away the in-app notification, it could also move to the shells top panel; this way, any operation in progress would always have a visible indicator/progress wheel/bar
*** Bug 749334 has been marked as a duplicate of this bug. ***
*** Bug 777136 has been marked as a duplicate of this bug. ***
*** Bug 761732 has been marked as a duplicate of this bug. ***
This is my main gripe with Nautilus right now so I created some mockups for the design. Here's the directories before removal https://www.cs.helsinki.fi/u/oottela/nautilus/0_initial.png Here's the current version https://www.cs.helsinki.fi/u/oottela/nautilus/1_current.png which is a) problematic because it covers the icons (the point of this ticket) and b) it's different in design compared to what appears at the top edge of Trash when the directory is not empty. So to unify design, minimize the need to reinvent the wheel, and to perhaps use pre-existing code to save time, it should IMO look like this: https://www.cs.helsinki.fi/u/oottela/nautilus/2_proposal.png The font text was copy-pasted so it's not perfectly polished but the idea should be clear from it.
(In reply to Markus Ottela from comment #13) > This is my main gripe with Nautilus right now so I created some mockups for > the design. > > Here's the directories before removal > > https://www.cs.helsinki.fi/u/oottela/nautilus/0_initial.png > > Here's the current version > > https://www.cs.helsinki.fi/u/oottela/nautilus/1_current.png > > which is a) problematic because it covers the icons (the point of this > ticket) and b) it's different in design compared to what appears at the top > edge of Trash when the directory is not empty. > > So to unify design, minimize the need to reinvent the wheel, and to perhaps > use pre-existing code to save time, it should IMO look like this: > > https://www.cs.helsinki.fi/u/oottela/nautilus/2_proposal.png > > The font text was copy-pasted so it's not perfectly polished but the idea > should be clear from it. Hi, you have to post your comment on GNOME GitLab (bugzilla.gnome.org have been dropped). Thanks !
Comments here is fine. We still follow bugzilla for tickets which haven't been marked as RESOLVED. However, this issue is not specific to this application: it's a GNOME-wide design patterns, and designers are looking into it, as this work-in-progress shows: https://gitlab.gnome.org/Teams/Design/os-mockups/-/raw/master/in-app-notifications/in-app-notifications.png So, we can close this application-specific ticket