Red Hat Bugzilla – Bug 157271
(gaim) IM window attract attention on new incoming message
Last modified: 2007-11-30 17:11:05 EST
Windows IM clients make minimized chat windows blink in the task bar when there
is incoming chat activity. This is beneficial because it is obvious at a glance
that there was new activity in minimized chat windows.
According to email@example.com, if you set _NET_DEMANDS_ATTENTION in xlib, our
panel should bold that window title in the taskbar.  gaim could also use
gtk_window_set_urgent() instead, but this is not yet upstream. 
_NET_DEMANDS_ATTENTION would probably work for older versions of GNOME too so
might be desirable.
Note that this is different from Bug #157270 which is new window focus behavior.
This is an enhancement request for *existing* windows.
 Future versions may flash the text instead, making it more noticiable and
similar to Windows.
This is correct, if you just set DEMANDS_ATTENTION on any window its taskbar
item should flash, on focusing that window the DEMANDS_ATTENTION flag will be
removed and the flashing will end. (The flashing is only with a new patch, GNOME
2.10 originally just did bold)
Created attachment 114281 [details]
Sample program that demands user attention
Here's a little example program that shows how to use _NET_DEMANDS_ATTENTION to
make the tasklist blink (or bolden depending on the version of libwnck
Upstream, would gaim_gtk_flash be the place to do this?
There should _be_ no gaim_gtk_flash(). We (Gaim) already set the Urgency hint,
which (if I understand correctly) will be supported in Gnome Real Soon Now, for
anything Gaim thinks is urgent. For any bizarreness Metacity causes on its own
(e.g. pop-unders) it will set the _NET_DEMANDS_ATTENTION property, likewise
leading to a flash (or whatever).
would gaim_gtk_flash be the place to do what? implement DEMANDS_ATTENTION? I'm
being told in wm-spec, 157270 in this tracker, and 120439 in the gnome tracker
that gaim should not be touching DEMANDS_ATTENTION directly *at all*.
This is for something entirely different. This is so the taskbar flashes when a
new incoming message comes in, just like it does in Windows.
In Bug #157270 Elijah Newren had no objection to this proposal.
As I understand the existing state of the various threads, setting urgency from
the existing message notification plugin should cause DEMANDS_ATTENTION to be
set automatically. Further, bug 120439 in the gnome tracker is about adding
urgency to GNOME, which would make this redundant.
If we are going to add support for setting DEMANDS_ATTENTION directly from gaim,
I would do so in a manner identical to the existing urgency support.
re: comment 7
In bug #157270 Elijah Newren actually said:
> I think that means that bug #2 is that Metacity should be setting
> DEMANDS_ATTENTION in those cases--then you don't even have to worry about
> setting any urgency hint or anything.
So if that is resolved, we don't need to worry about this bug at all, as
everything will sort itself out.
We shouldn't wait for urgency to be added to GNOME. If we add DEMANDS_ATTENTION
setting to gaim now, then it'll happen in the next FC update. If we wait until
GNOME does urgency, then we will wait until FC5. And it isn't guaranteed that
they will even add it upstream.
So this would go into the Message Notification plugin?
it wouldn't help. reference
http://mail.gnome.org/archives/wm-spec-list/2005-May/msg00046.html and its replies.
You've already added the flashing taskbar patch to Gnome, why not simply add
Urgency at the same time? Gaim does _not_ need or want to be messing with
DEMANDS_ATTENTION in the general case (we have Urgency, which is the right
solution), so I don't understand why we would want to put in a temporary hack
when we know the right fix is coming in Gnome sooner or later. This seems like
an appropriate area for a distro patch, to me...
Is it clear that GNOME will support urgency? I don't see urgency to support
But you see urgency to support some spec that Gnome made up real fast?
It is my understanding from the COUNTLESS bug reports, mailing list threads, and
IRC discussions that I have been dragged into that the Gnome people recognize
that they really should support ICCCM, what with it having been around for a
decade and a half or so, now. In that light, they intend to support Urgency
with the same notification as DEMANDS_ATTENTION. The only question on the table
seems to be exactly what form this notification will ultimately take (for both).
Since we already support Urgency, and its intended use is _exactly_ what we are
using it for, I see no reason to clutter things up with yet another protocol.
We should pick one, or the other, and use it. Since Urgency is a) a real
standard, b) much older, c) already supported, and d) designed exactly for this,
it seems to win this battle.
that is what gnome bug 120439 (mmm. bugzilla apparently makes that a link to the
rh bug of the same number. bah) is all about, getting urgency support in gnome.
there are currently two patches provides to add such support, one labeled
"needs work" and the other not yet evaluated.
It is also quite clear to me that adding DEMANDS_ATTENTION support would not
help rh/fc users here. See the previous information I have linked to in this
report, esp. the wm-spec thread and bug 157270 here. Dealing with
DEMANDS_ATTENTION here pretty much ignores 2/3rds or 3/4ths of the discussion on
this topic, it is impossible to gain an accurate understanding of where things
stand without moving beyond this report.
specifically, Havoc Pennington seems to be stating fairly clearly that metacity
will ignore a DEMANDS_ATTENTION set by an application, and Billy Biggs responds
that looking at the patch mentioned here, windows will go bold, but never go
unbold. That's clearly not more usable than the existing situation: a
notification that only works once per window will quickly be triggered and might
as well never exist afterwards.
Oops, I should have added myself to the cc list sooner. I had only read the
initial bug report and first two comments (and mistakenly assumed there weren't
any extra it seems?) when commenting in bug 157270. I definitely had not seen
comment 3. Anyway:
1) Warren: I believe (one of) the correct fix(es) for FC4 for this bug is to
apply the patch in http://bugzilla.gnome.org/show_bug.cgi?id=305882. That patch
makes it so that metacity sets the DEMANDS_ATTENTION hint when an app calls
gdk_window_raise() on itself (which gaim apparently does for existing windows
that received additional IMs). Honestly, I really consider this patch to
actually only be a bandaid, because I think gdk_window_raise() is stupid: apps
that need attention shouldn't specify how they get that attention--that should
be policy left up to the WM. So, I think Urgency/DemandsAttention is a better
method for the long run but this patch definitely won't hurt.
2) Yes, Urgency support WILL be supported upstream. It probably should have
been supported long ago. I'll cook up a libwnck patch. Would you like me to
also adapt it to the current FC4 SRPM for libwnck? If so, how soon do you
want/need it? And is
I get the up-to-date SRPM?
3) Ethan: actually, it was a KDE maintainer that made up DEMANDS_ATTENTION.
(Yes, I'm just nitpicking, and think your general sentiment is valid...)
4) Luke: No, Havoc was stating that the way in which Billy set the
DEMANDS_ATTENTION hint was inherently buggy, not that metacity would ignore apps
setting the hint when set correctly. (Note that I also pointed out that Billy's
method violated the spec.) Metacity will honor it if you set it by the method
required in the spec (sending a _NET_WM_STATE client message to the root window).
5) Luke: My previous comments about DEMANDS_ATTENTION vs URGENCY (my claim that
apps would only ever set the latter) seems to have been wrong, as pointed out by
Lubos on wm-spec list. (It appears that setting DEMANDS_ATTENTION by the app if
the app wants the window manager to be able to unset it, for example when the
app receives focus, is perfectly valid. If I now understand correctly, it
appears Lubos added this because he didn't like the idea that the Window manager
had to wait for apps to unset the hint as well as the fact that he wanted the
Window Manager to be able to set it.)
Thanks Elijah! Yes patches against the latest development SRPM would be
desired. It is too late for FC4 final, but we will push it into updates after
Created attachment 114977 [details]
Patch for libwnck.spec
This patch needs a new file, libwnck-2.10.0-urgent-support.patch, which I will
attach in a minute. See also http://bugzilla.gnome.org/show_bug.cgi?id=120439
since I have attached the urgent-support patch there (as well as provided a
Created attachment 114978 [details]
Created attachment 114979 [details]
Patch for metacity.spec
This patch needs a new file, metacity-2.10.0-raise-demands-attention.patch,
which I will attach in a minute. See also
http://bugzilla.gnome.org/show_bug.cgi?id=305882 for the upstream bug tracking
this particular patch.
Created attachment 114980 [details]
Okay, there's all the patches to fedora cvs versions of libwnck and metacity
needed to implement options (1) and (2) that I mentioned in comment 16.
Great! It seems to work after enabling gaim's "Message Notification" plugin and
all four "Notification Removal" options. I will make this the default in all
future gaim packages.
I will put test packages of libwnck and metacity on my people.redhat.com page so
more people can test it, then after a while plus other fixes to both metacity
and libwnck we'll push a FC4 update.
This has been pushed to FC4 updates a while ago.