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 120439 - adding "URGENT" flashing to tasklist
adding "URGENT" flashing to tasklist
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: tasklist
2.7.x
Other Linux
: Urgent enhancement
: ---
Assigned To: libwnck maintainers
libwnck maintainers
: 99679 114039 120441 129107 156955 164167 301908 305499 (view as bug list)
Depends on: 150594
Blocks: 88060 155905
 
 
Reported: 2003-08-22 02:21 UTC by Matthew Eaton
Modified: 2005-08-12 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
WM_HINT Urgency patch (flashing button) (8.08 KB, patch)
2003-08-22 02:21 UTC, Matthew Eaton
needs-work Details | Review
WM_HINT Urgency patch (flashing button) v2 (modify_style + prelight) (9.55 KB, patch)
2003-08-22 19:30 UTC, Matthew Eaton
needs-work Details | Review
WM_HINT Urgency patch (flashing button) v3 (final, no more crashing) (10.49 KB, patch)
2003-08-22 21:40 UTC, Matthew Eaton
none Details | Review
Revised patch of original to libwnck-2.6.0.1 (8.57 KB, patch)
2004-11-09 04:14 UTC, Brent Smith
none Details | Review
WM_HINT Urgency patch (set_state) for 2.8.0.1 (8.44 KB, patch)
2004-11-09 19:37 UTC, Matthew Eaton
none Details | Review
updated for version 2.8.1 (7.60 KB, patch)
2005-01-06 18:06 UTC, Brent Smith
none Details | Review
libwnck 2.8.1 patch (7.56 KB, patch)
2005-01-06 20:04 UTC, Matthew Eaton
needs-work Details | Review
test program showing button flash technique (4.16 KB, text/plain)
2005-04-05 17:02 UTC, Havoc Pennington
  Details
patch to libwnck using havoc's screenshoting technique (12.69 KB, patch)
2005-05-10 19:08 UTC, Ray Strode [halfline]
committed Details | Review
Updated version of Matthew Eaton's patch which depends on Ray's patch (12.84 KB, patch)
2005-05-30 23:02 UTC, Elijah Newren
committed Details | Review
Simple program to test the Urgency hint handling from the previous patch (1.95 KB, text/plain)
2005-05-30 23:04 UTC, Elijah Newren
  Details

Description Matthew Eaton 2003-08-22 02:21:06 UTC
This adds "flashing" to the task list to windows with the XUrgency WM_HINT
set. It is most useful in instant messenging applications. (I'm using this
with the gaim 0.67 notify.c(plugin)+bugfixes.)

This patch allows reading of the WM_HINTS "XUrgencyFlag", but could be
expanded to use the other WM_HINTS.

1> Application sets XUrgencyFlag
2> Button in task list flashes
3> Application unsets XUrgencyFlag
Comment 1 Matthew Eaton 2003-08-22 02:21:47 UTC
Created attachment 19435 [details] [review]
WM_HINT Urgency patch (flashing button)
Comment 2 Matthew Eaton 2003-08-22 02:24:52 UTC
Patch for cvs 2.3 is at:
http://bugzilla.gnome.org/show_bug.cgi?id=120441
Comment 3 Matthew Eaton 2003-08-22 19:30:12 UTC
Created attachment 19454 [details] [review]
WM_HINT Urgency patch (flashing button) v2 (modify_style + prelight)
Comment 4 Matthew Eaton 2003-08-22 21:40:35 UTC
Created attachment 19461 [details] [review]
WM_HINT Urgency patch (flashing button) v3 (final, no more crashing)
Comment 5 Matthew Eaton 2003-08-23 21:48:25 UTC
*** Bug 120441 has been marked as a duplicate of this bug. ***
Comment 6 Matthew Eaton 2003-08-23 21:51:12 UTC
In order to reduce clutter to bugzilla, the patches are at:

http://www.people.virginia.edu/~mse5q/blink/

- which includes a version of the patch that uses gtk_set_widget_state()
Comment 7 Havoc Pennington 2003-08-23 22:06:35 UTC
I'm traveling at the moment, marking PATCH keyword. Don't be afraid to
remind me about this patch in about a week.
Thanks
Comment 8 Havoc Pennington 2003-08-29 14:58:25 UTC
General comment - I would also patch GTK to add 
gtk_window_set_urgent() to encourage the use of this feature.

Implementation comments:
 - indentation and brace alignment need to match the 
   rest of the file (see GNU coding guidelines, with 
   some GTK extensions/changes)
 - when adding a timeout, you have to be sure it gets 
   removed when the object in user data is destroyed; 
   you can do this by saving the timeout ID 
   returned by g_timeout_add() and removing it 
   with g_source_remove()
Comment 9 Havoc Pennington 2003-08-29 15:17:50 UTC
Oh, also:

 - I think changing the color is right, rather than set_state()
 - to change the color, you could just use modify_bg() probably
Comment 10 Matthew Eaton 2003-08-29 17:29:02 UTC
Just using modify_bg is useful for the plain engines, but I noticed it
does not always work for all engines. (The engines that use two colors
for a background to do a gradient). Is there a way to modify a style
for an engine through the API? This shouldn't be engine dependent
should it? :-\

Set_state is a much more functional solution since, in my mind, it
tells a widget to change its appearance according to the state passed
as a parameter. But I am unfamiliar with the internals of it so I
don't know if this breaks anything.

Your other comments are noted and I will work on those items.
Comment 11 Havoc Pennington 2003-08-29 18:21:34 UTC
Maybe Owen has some suggestions on set_state, etc.
Comment 12 Owen Taylor 2003-08-29 18:33:48 UTC
Not really sure what to say here:

 - There is no guarantee that buttons will draw correctly
   if you set their state to selected:

   A) Calling set_state() on any widget that you haven't 
      implemented yourself is not legal GTK+ code, and
      the state will get overwritten, say, if the 
      mouse goes over the button and it gets set to prelight.

   B) Themes may simply not implement drawing buttons in
      the selected state.

But, on the other hand, yes, gtk_widget_modify_bg() will
typically not be honored by themes that use pixmaps.

The only reliable way to get a differently colored button
is to create a style for the default theme with 
gtk_style_new() and use gtk_widget_set_style(). But then
your button won't be themed.
Comment 13 Fabio Gomes 2003-09-15 01:15:07 UTC
One nice feature of M$ Windows that could be implemented here is the
one illustrated in their TweakUI:
------------------------------------------------------
[x] Prevent applications from stealing focus
    <o> Flash taskbar button until I click on it
    < > Flash taskbar button [number] times
------------------------------------------------------
When new windows are open, M$ Windows first looks if any key has been
pressed within the last second (or so). If so, then it creates the new
window minimized and makes its taskbar button flash. Otherwise, it
opens the window normally. 

This is great, because protects the multitasking feature of an
operating system. Some badly written apps forget that the user is
running multiple applications at once. Sometimes these apps hurt the
users privacy by making him/her type things in the wrong window.

To name a few apps:
- Gaim opens "disconnected!" and "logging in" and chat windows all the
time
- Mozilla pops up "conection error" dialogs all the time
And so on...

Is this possible to be implemented?

Fabio Gomes de Souza
fabio@gs2.SPAM.com.br
Comment 14 Vincent Untz 2003-10-16 14:04:40 UTC
*** Bug 114039 has been marked as a duplicate of this bug. ***
Comment 15 Vincent Untz 2003-10-16 14:24:08 UTC
*** Bug 99679 has been marked as a duplicate of this bug. ***
Comment 16 Elijah Newren 2004-03-08 17:14:20 UTC
Fabio: See bug 118372 and bug 115650.  This bug is also related, of
course, as far as the taskbar flashing is concerned.

I don't know anything about gtk themes, but could they be extended to
specify some type of widget color/style/something to handle this
special case?  I use such a gtk theme, but would really like the
urgency hint.  [Also, I am aware of another case where the lack of
color-changing ability in a gtk-theme caused problems; an application
called PartitionMorpher wanted to color widgets for partitions
according to their type, but I of course didn't see any change]

I'm adding myself to the cc...
Comment 17 Vincent Untz 2004-03-14 16:21:53 UTC
*** Bug 129107 has been marked as a duplicate of this bug. ***
Comment 18 Olivier Crête 2004-03-15 15:21:10 UTC
Can we just change/flash the text color for now? Or have the button
pressed/depressed? Or flash the content as underlined/bold? Or all of
the above? Or just fix the way gtk themes work in time for gtk+ 2.4.
Btw has setting the urgency hint been put into gtk+ yet? GnomeICU has
been waiting for the urgency hint to be properly implemented for years.
Comment 19 Kjartan Maraas 2004-04-18 20:26:43 UTC
Maybe this could be looked at for 2.7.x again?
Comment 20 Kristof Vansant 2004-05-09 11:19:41 UTC
2.7 ? :( so late? 
Will it break things or something? That it can't be in gnome 2.6.2
Comment 21 Rob Adams 2004-06-24 22:11:49 UTC
This bug takes on new urgency thanks to Bug 118372.  A version of this patch
needs to go in that will also flash when NET_DEMANDS_ATTENTION is set.  I don't
remember if the panel or metacity is supposed to unset DEMANDS_ATTENTION. 
Probably the WM.
Comment 22 Daniel Brodie 2004-06-25 14:12:30 UTC
I would just like to make a small suggestion that blinking is not necceserally
the right solution. The problem with blinking is that it is very distracting! If
I noticed whatever the NET_DEMANDS_ATTENTION or WM_HINT was supposed to make me
notice, but I want to continue doing what I am doing and ignore it for now, it
is very difficult. When I was using windows this was very annoying and kept
bugging me.

I suggest, instead, to have a solid highlight that dosn't blink repeatidly so as
to try and lower the amount of involuntary spasms caused by fast flashing lights.
Comment 23 Kristof Vansant 2004-08-13 09:20:02 UTC
will this make it into gnome 2.8 or not???
I really would like this feature.
Comment 24 Elijah Newren 2004-08-13 14:11:58 UTC
Urgent flashing--no.  Having the window title be made bold--probably.  It all
depends on whether bug 149028 can be fixed in time.
Comment 25 Kristof Vansant 2004-08-19 22:17:01 UTC
shouldn't this dependency be add then?
Comment 26 Elijah Newren 2004-08-19 22:46:41 UTC
The title being made bold was moved to bug 148370 and has already been
implemented.  So although there might be a dependency there, I don't see there
being much use in marking it as such since one bug is already fixed.  This bug
seems to have dropped back to just being used for the Urgency hint which is
separate from the other two bugs, even if semantically very similar.

This bug appears to be blocking on an extended gtk theme system that
specifically accounts for slashing so that it can work for all themes (see what
Owen said in comment 12).  So, perhaps the best thing as far as dependencies are
concerened would be to file a bug against gtk themes and mark it as blocking
this one.  I'll do that now.
Comment 27 Elijah Newren 2004-10-31 14:38:18 UTC
*** Bug 156955 has been marked as a duplicate of this bug. ***
Comment 28 Brent Smith 2004-11-09 04:12:38 UTC
Posted a revised patch that applies to libwnck-2.6.0.1
Comment 29 Brent Smith 2004-11-09 04:14:29 UTC
Created attachment 33577 [details] [review]
Revised patch of original to libwnck-2.6.0.1
Comment 30 Matthew Eaton 2004-11-09 18:13:33 UTC
As Havoc said in #8, the part that's holding this back is making an API for the
application developer (e.g. gtk_window_set_urgent()). Setting the XUrgency bit
by hand is a bit complicated. 

I'll try to do it over winter break if it hasn't been done by then... guess
that's better than never :)

Also, regarding the set_state discussion, I'd go with set_state for now since
being the most consistently reliable solution for now.

Comment 31 Elijah Newren 2004-11-09 18:30:53 UTC
I don't think making such a gtk patch would be real difficult.  The thing that
looks difficult to me is resolving the issue(s) brought up by Owen in comment 12
(and for which bug 150594 was filed).  Attempting to just change colors won't
work for some themes (for example, the H2O-gtk2 theme I have used for years). 
Also, there's an accessibility component to it in that flashing can be very bad
for certain users, so we would probably need to special case that...
Comment 32 Matthew Eaton 2004-11-09 19:37:50 UTC
Created attachment 33595 [details] [review]
WM_HINT Urgency patch (set_state) for 2.8.0.1

This patch uses set_state, which works for all themes I've tried.
Comment 33 Brent Smith 2005-01-06 18:06:05 UTC
Created attachment 35568 [details] [review]
updated for version 2.8.1

updated this patch in hopes that this (or something similar) will appear in the

next version of gnome.	I wrote some instructions for applying the patch
on gentoo here (http://forums.gentoo.org/viewtopic.php?t=250764) and I've only
received positive feedback.  Doesn't seem to break any of the themes I've
tried.
Comment 34 Matthew Eaton 2005-01-06 20:04:51 UTC
Created attachment 35576 [details] [review]
libwnck 2.8.1 patch

Looking back on the patch, I can see it needed some work.

Fixed up the patch for 2.8.1 and coding style as per #8.
Comment 35 Havoc Pennington 2005-01-15 03:38:30 UTC
Comment on attachment 35576 [details] [review]
libwnck 2.8.1 patch

As Owen says, set_state() is protected; can only be used in widget
implementations. I have a new thought maybe; what if we implemented a container
widget that screenshotted its child (maybe even using the GDK double buffer as
the screenshot, so no flicker, i.e. expose the child then grab the paint
buffer?) and then we could alpha-blend a color over the screenshot maybe, do a
"pulsing" effect. That would be fun.

Let's see if this makes Owen say "ok you can call set_state() after all" ;-)

You need to remove the flashing timeout if the tasklist is destroyed.

You seem to have broken calling the icon_cache_property_changed() when WM_HINTS
changes.

wnck_read_hints() should be called wnck_read_wm_hints() and we should read
WM_HINTS only once to get both urgency and icon and other information.

On the nitpicks side, you need a space before parens after function name foo()
vs. foo () in a few places.
Comment 36 Havoc Pennington 2005-01-15 03:41:40 UTC
Re: the scary alpha blended button idea, see Federico's recent "how gtk draws
stuff" document for help on how to do it:
http://primates.ximian.com/~federico/misc/gtk-drawing-model/index.html

It will be fun to be sure Federico's work is used as a force for evil ;-)

Comment 37 Vincent Untz 2005-01-15 17:29:20 UTC
*** Bug 164167 has been marked as a duplicate of this bug. ***
Comment 38 Vincent Noel 2005-01-28 14:49:21 UTC
Moving to the right component. Sorry for the spam.
Comment 39 Ben Davis 2005-03-01 23:05:22 UTC
Hmm... When I switch to another workspace, and a window icon is flashing in the
window list, I am not notified in any way.  My windowlist is set up to only show
the current workspace. Ideally, The workspace switcher applet should flash if
I'm getting notification from a another workspace, and then when I switch to
that workspace, it should be flashing the window button.  This may require a new
bug (maybe for seomthing else like gnome-panel), but I'm not sure.
Comment 40 Mark Doliner 2005-03-06 00:37:11 UTC
I think the Gaim community would also benefit from this change.
Comment 41 Havoc Pennington 2005-04-05 17:01:03 UTC
Here is an example of how to implement the flashing. It needs one small
enhancement, which is to ignore expose events that do not cover the entire area
of the button (this will fix most of the cases where the hack breaks)

If someone wants to port this into libwnck then we could close this bug.
Comment 42 Havoc Pennington 2005-04-05 17:02:23 UTC
Created attachment 39717 [details]
test program showing button flash technique
Comment 43 Olaf Conradi 2005-04-06 00:44:06 UTC
Hi,

Noticed this bug from Havoc's blog (http://log.ometer.com/2005-04.html#5) about
the notification area and the urgency hint. Just a usability comment from my
perspective.

Why all the fancy flashing?

Bug 129107 describes a method of using the panel notification area with an
optional message balloon describing the urgency (on initial showing or mouse
hoovering).

This would eliminate the flashing of the tasklist when switched to another
workspace. And would help against the annoying blinking mentioned in comment
#22. And maybe even better for disabled people as it groups all notifications
together regardless of their type? Without adding extra functionality in the
tasklist applet.

Cheers
 -Olaf

Comment 44 Olav Vitters 2005-04-30 00:38:42 UTC
*** Bug 301908 has been marked as a duplicate of this bug. ***
Comment 45 Ray Strode [halfline] 2005-05-10 19:08:05 UTC
Created attachment 46302 [details] [review]
patch to libwnck using havoc's screenshoting technique

This patch adds havoc's leet glowing button feature to libwnck for windows that
demand attention (the patch doesn't address XUrgencyHint).  There are a few
changes:

Instead of maintaining a delta value that adjusts the factor every timeout, the
difference between current time and the start time is used to figure out what
frame should be displayed (using a sine function).  This should make the
animation less dependent on when the timeout gets called.

I used a different function to change the pixel intensities because the other
one was crashing randomly (not sure why).
Comment 46 Michael R Head 2005-05-12 22:51:04 UTC
The gaim developers would really like this resolved ;-)

http://sourceforge.net/mailarchive/forum.php?thread_id=7237159&forum_id=9587
Comment 47 Jason LeBrun 2005-05-13 08:40:40 UTC
Ray Strode's patch is pretty neat. I got it to work with the XUrgencyHint by
combining it with the XUrgency patch further up. You can apply the patches
sequentially, then make a few more changes in tasklist.c

I haven't perfected it yet, but I'll post a combined patch here later on.
Comment 48 Elijah Newren 2005-05-26 15:53:21 UTC
*** Bug 305499 has been marked as a duplicate of this bug. ***
Comment 49 Luke Schierer 2005-05-26 17:41:17 UTC
https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c9 emphasizes well the
importance of finding a *good* fix for this bug.  for anyone that mazimizes
windows, it is not just gaim that will appear broken by the current behavior.
Comment 50 Luke Schierer 2005-05-26 18:27:32 UTC
that link should have been
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157270#c9
Comment 51 James Gao 2005-05-27 14:19:07 UTC
Is there an updated patch for gnome 2.10?
Comment 52 Elijah Newren 2005-05-30 01:34:41 UTC
Sorry for the long lag.  Ray: I've tested it and it seems to work nicely; please
go ahead and commit.

Vincent/Mark/Havoc: Since this patch is important to get in and we've sorely
needed a more obvious demands_attention hint for some time, I'm sort of cheating
and counting Havoc's writing of the test program as 1 of 2 approvals, so it may
be good if one of you could still look the patch over.  ;-)

Note that those interested in this bug may also be interested in bug 305882
(which I mention mainly because there's so many people watching this bug).
Comment 53 Elijah Newren 2005-05-30 23:02:02 UTC
Created attachment 47053 [details] [review]
Updated version of Matthew Eaton's patch which depends on Ray's patch

This patch adds Urgency support to libwnck.  It makes libwnck handle both the
Urgent hint and the Demands Attention hint in the same way (which currently is
to use the button-screenshot-flashing implemented in Ray's patch).
Comment 54 Elijah Newren 2005-05-30 23:04:47 UTC
Created attachment 47054 [details]
Simple program to test the Urgency hint handling from the previous patch

Hopefully this will assist others in testing/review.  Simply compile with
  gcc testcase.c -o testcase `pkg-config --cflags --libs gtk+-2.0`
then run testcase, click on the button, and watch the tasklist start flashing. 
Click the button again to turn the Urgent hint back off.
Comment 55 Ray Strode [halfline] 2005-05-31 15:49:42 UTC
Hi Elijah (from comment 52), 

I've committed the patch (with a few small changes):

2005-05-31  Ray Strode  <rstrode@redhat.com>

        Make windows that demand attention more noticeable by
        glowing their tasklist buttons (bug 120439).

        * libwnck/tasklist.c (struct _WnckTask): add some new
        fields to track glowing start time, screenshot,
        (wnck_task_init): initialize new fields
        (glow_pixbuf): new function to uniformly luminate a
        pixbuf by some factor (with 1.0 meaning don't change)
        (wnck_task_button_glow): new function to glow tasklist
        button by some factor dependent on how long the button
        has been glowing.
        (wnck_task_clear_glow_start_timeout_id): function to
        clear the glow timeout id when it becomes stale
        (wnck_task_queue_glow): new function to start glowing a
        tasklist button.
        (wnck_task_stop_glow): new function to stop glowing a
        tasklist butotn.
        (wnck_task_finalize): stop glowing any buttons that
        are glowing.
        (wnck_tasklist_size_allocate): when a button gets hidden
        be sure to invalidate its screenshot.
        (wnck_task_popup_menu): when a window in a tasklist group
        demands attention then make it's menu item bold.
        (wnck_task_update_visible_state),
        (wnck_task_create_widgets): when a window demands
        attention start glowing its tasklist button.
        (wnck_task_expose): rename wnck_task_class_group_expose
        to wnck_task_expose, handle taking a screenshot of the
        button right after it's drawn.
Comment 56 Michaël Arnauts 2005-06-08 17:45:59 UTC
I just updated to libwnck 2.11.3 where this patch should be included, but the
testprogram attached by Elijah in #54 doesn't work. Clicking the button has no
effect on the way the button is displayed in the window list. Am I missing
someting important?
Comment 57 Elijah Newren 2005-06-08 17:52:01 UTC
Did you manually apply the patch in attachment 47053 [details] [review]?  It hasn't been committed
yet because I'm waiting for Havoc, Mark, or Vincent to comment (in particular,
I'm curious about the update_wmhints() function--should it check for changes to
the group leader (since we haven't done so previously)?  Should we check for
other things that we're not checking for now?  Does it seem to be a sane way to
handle WMHints stuff?)
Comment 58 Michaël Arnauts 2005-06-08 18:05:06 UTC
Ow, no, i just used the official 2.11.3 package that got released today... But I
noticed now that debian already patched that flashing of new windows in, so
actually, nothing has changed (except for those two other fixes).
I will be waiting for the URGENT-flashing-one then, but it looks like it will be
there soon (at least, I hope :) )
Comment 59 Elijah Newren 2005-06-16 17:37:05 UTC
I'd still like comments from Havoc, Mark, or Vincent on this, but as they're
pretty busy right now and this really needs to be fixed, I'll go ahead and
commit; if anything needs to be fixed in this patch it won't be a very big
change anyway...   :)

2005-06-16  Elijah Newren  <newren@gmail.com>

	Add support for the Urgent hint; fixes the remainder of #120439.

	* libwnck/selector.c (wnck_selector_get_window_name): 
	* libwnck/tasklist.c (wnck_task_popup_menu,
	  wnck_task_get_demands_attention, wnck_task_update_visibile_state,
	  wnck_task_create_widgets):
	* libwnck/window.[ch] (wnck_window_demands_attention,
	  transient_demands_attention,
	  wnck_window_or_transient_demands_attention):

	function renames from *_demands_attention() to *_needs_attention()

	* libwnck/selector.c (wnck_selector_window_state_changed):
	* libwnck/tasklist.c (wnck_task_state_changed):
	* libwnck/window.h (enum WnckWindowState):

	add WNCK_WINDOW_STATE_URGENT and checks for it

	* libwnck/window.c (COMPRESS_STATE macro): add
	(window)->priv->is_urgent, (struct _WnckWindowPrivate): add
	is_urgent_field and need_update_wmhints field),
	(_wnck_window_create): provide default group leader but have
	update_wmhints() do the actual setting if there is a different one
	specified, (_wnck_window_process_property_notify): add need for
	updating from WM_HINTS separate from icon_cache_property updating,
	(update_state): looks like there's a bug here so throw in a FIXME
	though I don't have time to check into it right now,
	(update_wmclass): new function to get updates related to WM_HINTS
	atom, (force_update_now): call update_wmhints()

	* libwnck/xutils.h (_wnck_get_group_leader): remove this function
	as it has been replaced by the more comprehensive update_wmhints()
	in window.c
Comment 60 mark krischer 2005-06-27 05:24:42 UTC
i think there's something here breaking the gconfig make option for the 2.6.12
kernel.  i can live with menuconfig myself, but thought i'd note it for the bug.
Comment 61 Filip Miletic 2005-08-12 19:57:00 UTC
Please consider making this flashing thing an option that can be turned off.
There are many situations when windows flash without an apparent need (for
instance, when the OpenOffice opens a detached toolbar).