After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 596431 - Indicate demands-attention windows
Indicate demands-attention windows
Status: RESOLVED DUPLICATE of bug 610594
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks: gnome-shell-2-28
 
 
Reported: 2009-09-26 15:05 UTC by Owen Taylor
Modified: 2010-02-21 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2009-09-26 15:05:36 UTC
Right now there is no indication at when a window as the demands-attention state set (typically it tried to focus itself but was prevented by focus-stealing-prevention)

Often this happens for "messaging windows" - xchat, Pidgin, Empathy, etc; and these eventually will be handled by the message tray design. It can happen for slow-starting windows, where you go back and work on something else - we likely will have special design for that in the future. It can also happen because an obscured window pops up a dialog.

A quick design targetted at a 2.28.0 quick-fix:

  If a window is demands attention, show a small icon for the 
  application as if it was in the notification area (to the left of all the
  system icons), and make it glow and/or pulse. The same glow/pulse should
  be used for the icon in the Applications Well.

  We should try to detect when that application already has a status
  icon in the notification area, and omit the extra icon in this case
  (just assume that the application is blinking its icon.)
Comment 1 Dan Winship 2009-11-12 22:41:24 UTC
Someone was working on this... jnettlet?
Comment 2 Dan Winship 2010-02-21 13:38:31 UTC

*** This bug has been marked as a duplicate of bug 610594 ***