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 rstrode, if you set _NET_DEMANDS_ATTENTION in xlib, our panel should bold that window title in the taskbar. [1] gaim could also use gtk_window_set_urgent() instead, but this is not yet upstream. [2] _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. [1] Future versions may flash the text instead, making it more noticiable and similar to Windows. [2] http://bugzilla.gnome.org/show_bug.cgi?id=120439
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 installed)
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). Ethan
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.
Warren - 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... Ethan
Is it clear that GNOME will support urgency? I don't see urgency to support urgency.
But you see urgency to support some spec that Gnome made up real fast? Interesting... 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. Ethan
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 http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ where 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 some testing.
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 simple testcase).
Created attachment 114978 [details] libwnck-2.10.0-urgent-support.patch file
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] metacity-2.10.0-raise-demands-attention.patch file
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.