Ticket #72 (defect)

Opened 2 years ago

Last modified 2 years ago

notify_notification_attach_to_widget mode positions notifications awkwardly

Status: new

Reported by: atrus Assigned to: chipx86
Priority: normal Milestone:
Component: notification-daemon Version: 0.3.4
Severity: normal Keywords:
Cc: D-BUS Version:
Patch Included: 0 OS/Distro Version:

Two related problems with regards to the position of notifications when attached to the notification icon:

1. The "tip" of the notification bubble can obscure the notification icon itself. This makes interacting with the icon difficult. It can also make it quite difficult to access the panel it resides on if it implements an "auto-hide" feature, as gnome-panel does.

2. When notifications occur near simultaneously, they overlap. Even if they appear at the same time and are attached to the icon, it would seem that they should stack themselves progressively further away from the starting point, as they do when unattached.

I'm using notification-daemon 0.3.4 (debian sid), chiefly with gossip as the app generating the notifications.

Change History

07/07/06 00:07:31: Modified by atrus

Also, when the panel it's on un-hides, the notification doesn't move. It still seems to be centered on the notification icon's old position off-screen, so it covers a large part of the panel.

12/26/06 14:20:33: Modified by jwendell

  • patch_included changed.

About item #2:

I guess it should have the same behavior like if it isn't attached to any widget. Its position should be automatically calculated so that one does not overlap other.

Any news about its solution?

Thanks,

Wendell.

12/26/06 14:40:45: Modified by chipx86

I think we probably should automatically calculate the position based on whether there are other popups there, and I would welcome a patch for that. I don't believe I'll have time for a while to implement it.

There's a couple of issues to take into consideration. If we're talking about two separate notifications for the same icon, a stacking solution is simple.

What's not so simple is two icons side-by-side, each with a notification. I'm not entirely sure what we could do there, because if you have a scenario with, say, 10 icons side-by-side, each with a notification, there won't be much you can do.

So the first case we can take care of easily enough. The second is a larger problem.

03/24/07 10:30:05: Modified by M.S.

Novell has done several usability tests with notifications. The effect of this was that openSUSE's notification-daemon packages patch it to only use the stack.

This makes sense for most of the current applications!

Take the Liferea RSS Reader for example which displays a notification on it's status icon when feed updates are available. However it clearly does it wrong, since most of the time you got multiple of feeds updating at once, thus the notification popups overlap itself. It is clear that this application should use the stack instead.

I can't imagine a way to correctly draw three notifications that point to three icons in the tray and would not like to imagine the code required to arrange them correctly in such a scenario. If anyone has a good idea or a mockup though...

Only allowing notification stacks or at least adding a gconf option to trigger this would solve both issues in a usability conformant way.

Still, 1) can be solved for now.

03/24/07 11:34:33: Modified by atrus

More than a few times I've been flooded from various notification sources. For example, coming online on a large network gives me TONNES of avahi notifications, in which it's very easy to lose my RSS headlines. Perhaps (especially in the case of flooding), there should be some form of notification log-browser, so that users could go back and peruse what's happened recently. A flood of notifications from a particular source could then be grouped as a single notification ("12 headlines from Slashdot" it could say, with a clickable link to open them in the log-browser.) It would also be potentially very valuable to go back and recall what happened 5 minutes ago.