GNOME Bugzilla – Bug 120439
adding "URGENT" flashing to tasklist
Last modified: 2005-08-12 19:57:00 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
Created attachment 19435 [details] [review] WM_HINT Urgency patch (flashing button)
Patch for cvs 2.3 is at: http://bugzilla.gnome.org/show_bug.cgi?id=120441
Created attachment 19454 [details] [review] WM_HINT Urgency patch (flashing button) v2 (modify_style + prelight)
Created attachment 19461 [details] [review] WM_HINT Urgency patch (flashing button) v3 (final, no more crashing)
*** Bug 120441 has been marked as a duplicate of this bug. ***
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()
I'm traveling at the moment, marking PATCH keyword. Don't be afraid to remind me about this patch in about a week. Thanks
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()
Oh, also: - I think changing the color is right, rather than set_state() - to change the color, you could just use modify_bg() probably
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.
Maybe Owen has some suggestions on set_state, etc.
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.
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
*** Bug 114039 has been marked as a duplicate of this bug. ***
*** Bug 99679 has been marked as a duplicate of this bug. ***
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...
*** Bug 129107 has been marked as a duplicate of this bug. ***
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.
Maybe this could be looked at for 2.7.x again?
2.7 ? :( so late? Will it break things or something? That it can't be in gnome 2.6.2
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.
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.
will this make it into gnome 2.8 or not??? I really would like this feature.
Urgent flashing--no. Having the window title be made bold--probably. It all depends on whether bug 149028 can be fixed in time.
shouldn't this dependency be add then?
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.
*** Bug 156955 has been marked as a duplicate of this bug. ***
Posted a revised patch that applies to libwnck-2.6.0.1
Created attachment 33577 [details] [review] Revised patch of original to libwnck-2.6.0.1
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.
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...
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.
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.
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 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.
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 ;-)
*** Bug 164167 has been marked as a duplicate of this bug. ***
Moving to the right component. Sorry for the spam.
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.
I think the Gaim community would also benefit from this change.
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.
Created attachment 39717 [details] test program showing button flash technique
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
*** Bug 301908 has been marked as a duplicate of this bug. ***
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).
The gaim developers would really like this resolved ;-) http://sourceforge.net/mailarchive/forum.php?thread_id=7237159&forum_id=9587
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.
*** Bug 305499 has been marked as a duplicate of this bug. ***
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.
that link should have been https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157270#c9
Is there an updated patch for gnome 2.10?
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).
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).
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.
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.
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?
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?)
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 :) )
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
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.
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).